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

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

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

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#ga64fa40b55...

Regards, Clemens

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#ga64fa40b55...

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