No dmix/dsnoop on Intel ICH4/5 by default?

No dmix/dsnoop on Intel ICH4/5 by default?

[Rene Herman]

Good day.

I'm out of touch of with alsa -- but should dmix/dsnoop still be enabled 
by default on hardware that doesn't do hardware mixing?

It seems it isn't on my Intel ICH4:

$ cat /proc/asound/cards
  0 [ICH5           ]: ICH4 - Intel ICH5
                       Intel ICH5 with AD1980 at irq 17
  1 [SAA7134        ]: SAA7134 - SAA7134
                       saa7134[0] at 0xe8200000 irq 22

I believe that it should be from /usr/share/alsa/cards/ICH4.conf, but I 
don't get mixing on this setup when using the "default" pcm...

(which I may not mind at that much, but I was looking at some other 
sound-related problem and this has me rather confused)

This is arch linux, with alsa-lib, -plugins and -utils 1.0.26 installed, 
using kernel 3.6.11-1-ARCH (ie, standard).

Regards,
Rene

Re: No dmix/dsnoop on Intel ICH4/5 by default?

[Clemens Ladisch]

Rene Herman wrote:
> I'm out of touch of with alsa -- but should dmix/dsnoop still be enabled by default on hardware that doesn't do hardware mixing?

Yes.

> I believe that it should be from /usr/share/alsa/cards/ICH4.conf, but I don't get mixing on this setup when using the "default" pcm...

What's the output of "aplay -v something.wav"?


Regards,
Clemens

libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[Rene Herman]

On 16-01-13 21:52, Clemens Ladisch wrote:

> Rene Herman wrote:

>> I'm out of touch of with alsa -- but should dmix/dsnoop still be
>> enabled by default on hardware that doesn't do hardware mixing?
>
> Yes.
>
>> I believe that it should be from /usr/share/alsa/cards/ICH4.conf,
>> but I don't get mixing on this setup when using the "default"
>> pcm...
>
> What's the output of "aplay -v something.wav"?

I won't bother you with that, since things do in fact work with aplay. 
It seems I'm looking at a libao problem.

Specifically: I can mix as many streams as I want using just "aplay" but 
if I start by playing one track with "ogg123" (which uses a default, 
unconfigured libao as its backend), I can't start a second ogg123, which 
then says:

===
ao_alsa WARNING: Unable to open surround playback.  Trying default device...
ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave
ao_alsa ERROR: Unable to open ALSA device 'default' for playback => 
Device or resource busy
ERROR: Cannot open device alsa.
===

I CAN still start an "aplay" at this point though. Moreover, things get 
weirder when I start with aplay. With one aplay running, I CAN start two 
additional ogg123 instances.

... so, err, ehm, err, what? :-)

This now seems at best related to ALSA in a secondary manner, and I'm 
CCing this to vorbis-dev (which I believe is the right email contact for 
libao?) but if you know of something of interest...

For vorbis-dev: this is on arch linux, (standard) kernel 3.6.11-1-ARCH, 
alsa-{lib,plugins,utils}-1.0.26-1, libao-1.1.0-2 and vorbis-tools-1.4.0-3.

Regards,
Rene

Re: libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[Clemens Ladisch]

Rene Herman wrote:
> I can mix as many streams as I want using just "aplay" but if I start
> by playing one track with "ogg123" (which uses a default, unconfigured
> libao as its backend), I can't start a second ogg123, which then says:
>
> ao_alsa WARNING: Unable to open surround playback.  Trying default device...

The default dmix is for stereo only.  For a surround dmix device, you'd
have to write your own definition.


Regards,
Clemens

Re: libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[Rene Herman]

On 17-01-13 13:12, Clemens Ladisch wrote:

> Rene Herman wrote:

>> I can mix as many streams as I want using just "aplay" but if I start
>> by playing one track with "ogg123" (which uses a default, unconfigured
>> libao as its backend), I can't start a second ogg123, which then says:
>>
>> ao_alsa WARNING: Unable to open surround playback.  Trying default device...
>
> The default dmix is for stereo only.  For a surround dmix device, you'd
> have to write your own definition.

Thank you. I didn't notice it was related due to the "trying default 
device" which I thought should've worked but the issue is that libao 
1.1.0 doesn't use the alsa "default" device by default. The first ogg123 
instance therefore keeps things busy.

There's a matching bug-rapport here, I see:

https://trac.xiph.org/ticket/1776

I can, now, set it to dev=default manually but what this means is that 
libao-1.1.0 by default kills alsa default software mixing. These days 
everybody seems to have regressed to using a soundserver again anyway 
and as such not many may notice, but this izz no good, I feel... :-/

In any case, hope this was useful to alsa-devel in the sense that this 
libao behavior is now known here, but this is otherwise libao related 
only, then.

Regards,
Rene

Re: [Vorbis-dev] libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[xiphmont]

> I can, now, set it to dev=default manually but what this means is that
> libao-1.1.0 by default kills alsa default software mixing.

The only alternative is to have any attempt at playing surround always
fail to play more than stereo on a default setup.  The bug reports
about _that_ prompted the change to the current behavior.

> These days
> everybody seems to have regressed to using a soundserver again anyway

Part of the reason for that is that ALSA provides so precious little
in the way of programmatic configuration discovery.  So far as I can
tell, each and every user gets to script/configure his own setup, and
then also explicitly configure the applications what to do.
Applications can't even tell if a default setup is in use.  It's all
plug-n-pray.

If that's not the case, I'd love to hear about it. I agree the current
behavior sucks.

Monty

Re: [Vorbis-dev] libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[Rene Herman]

On 07-03-13 09:20, xiphmont@xiph.org wrote:

>> I can, now, set it to dev=default manually but what this means is
>> that libao-1.1.0 by default kills alsa default software mixing.
>
> The only alternative is to have any attempt at playing surround
> always fail to play more than stereo on a default setup.

Correct me if I'm wrong, but currently I believe the libao setup is to 
try, depending on the number of channels of the input:

channels : device
=================

7, 8     : surround71
6, 5     : surround51
4, 3     : surround40
2        : front
1        : default

The only thing I personally had an actual issue with is using "front" 
for stereo rather than "default". I don't seem able to come up with a 
compelling reason why it should be "front" myself, so one tweak could 
perhaps be to only change the stereo device back to "default"?

Frankly, on my system libao is (actively) used only by ogg123 and even 
for me, your average back-in-the-day, technology-obsoletist, any even 
halfway involved audio needs are these days met not by anything that 
involves libao. As such, I just need the most basic setup to be, well, 
basic.

Currently arch linux is by the way shipping with an /etc/libao.conf that 
contains dev=default due to this issue. Trying to look at it from your 
side, I suppose the most consistent solution might be to introduce 
dev1=, dev2=, dev34=, dev56= and dev78= settings into the libao 
configuration (with for the ALSA plugin by default dev1=dev2=default 
still) -- but I'll butt out of that.

If the stereo device can be "default" by default rather than "front" 
then I guess that goes a long way towards this issue being a non-issue.

Remainder left in for possible comments from the ALSA side:

> The bug reports about _that_ prompted the change to the current
> behavior.
>
>> These days everybody seems to have regressed to using a soundserver
>> again anyway
>
> Part of the reason for that is that ALSA provides so precious little
> in the way of programmatic configuration discovery.  So far as I can
> tell, each and every user gets to script/configure his own setup, and
> then also explicitly configure the applications what to do.
> Applications can't even tell if a default setup is in use.  It's all
> plug-n-pray.
>
> If that's not the case, I'd love to hear about it. I agree the
> current behavior sucks.
>
> Monty

Re: [alsa-devel] libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[xiphmont]

> The only thing I personally had an actual issue with is using "front" for
> stereo rather than "default". I don't seem able to come up with a compelling
> reason why it should be "front" myself, so one tweak could perhaps be to
> only change the stereo device back to "default"?

Because then you can't guarantee or even discover what the playback
rate and bitdepth are. There's no way to ensure bit-exact playback in
a plug device, where 'front' is usually a non-plug alias.

Like I said, I agree the current situation sucks, and I don't mean to
discourage suggestions :-)

Monty

Re: [Vorbis-dev] libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[Clemens Ladisch]

xiphmont@xiph.org wrote:
>> The only thing I personally had an actual issue with is using "front" for
>> stereo rather than "default". I don't seem able to come up with a compelling
>> reason why it should be "front" myself, so one tweak could perhaps be to
>> only change the stereo device back to "default"?
>
> Because then you can't guarantee or even discover what the playback
> rate and bitdepth are. There's no way to ensure bit-exact playback in
> a plug device, where 'front' is usually a non-plug alias.

The SND_PCM_NO_AUTO_* flags are there for exactly this reason:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga64fa40b556374dabe40d4874242fee19


Regards,
Clemens

Re: [alsa-devel] libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[xiphmont]

> The SND_PCM_NO_AUTO_* flags are there for exactly this reason:
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga64fa40b556374dabe40d4874242fee19

Ahhh, very good. Yes, I can improve the situation given these flags.

Monty

Re: [Vorbis-dev] libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[Rene Herman]

On 24-03-13 20:43, xiphmont@xiph.org wrote:

>> The SND_PCM_NO_AUTO_* flags are there for exactly this reason:
>> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga64fa40b556374dabe40d4874242fee19
>
> Ahhh, very good. Yes, I can improve the situation given these flags.

Great. If you keep me in the loop, I'll get dev=default removed in arch 
linux again once it has.

Regards,
Rene

Re: [Vorbis-dev] libao problem (Re: No dmix/dsnoop on Intel ICH4/5 by default?)

[Alan Horstmann]

On Sunday 24 March 2013 18:50, Clemens Ladisch wrote:
> xiphmont@xiph.org wrote:
> >> The only thing I personally had an actual issue with is using "front"
> >> for stereo rather than "default". I don't seem able to come up with a
> >> compelling reason why it should be "front" myself, so one tweak could
> >> perhaps be to only change the stereo device back to "default"?
> >
> > Because then you can't guarantee or even discover what the playback
> > rate and bitdepth are. There's no way to ensure bit-exact playback in
> > a plug device, where 'front' is usually a non-plug alias.
>
> The SND_PCM_NO_AUTO_* flags are there for exactly this reason:
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga64fa40b5
>56374dabe40d4874242fee19

Where would those flags be used, and how is that different from calling

    snd_pcm_hw_params_set_rate_resample()

(with '0' to disable) on the pcm/configuration space?

Thanks

Alan