dmix not supported with ALSA

[rossb]

PortAudio/ALSA doesn't support dmix so you can't share the audio device between a PortAudio application and any other -- of course sometimes this is what you want, but sometimes it isn't.

[rossb]

I've attached the most recent patch from Phuah Yee Keat for this (PortAudio mailing list 3rd November). An earlier patch used snd_pcm_drain but this was found to deadlock. The current version uses snd_pcm_drop.

[aknudsen]

I'm not I understand the rationale for all these changes. 1. The patch doesn't only enable the "dmix" device but also the "default" device. 2. Why always try twice to open a busy device, sleeping inbetween? Is this something the client wants in all cases? 3. Why implement Pa_StopStream through snd_pcm_drop instead of snd_pcm_drain in AlsaStop?, since the latter reflects the purpose of Pa_StopStream?

[leland_lucius]

Reply from Phuah:

1. the default device lets portaudio knows what the default device is,
currently portaudio always set the default to the first device that it
probes, and that's usually not the correct default value. So any users
who tries to use "default" in portaudio is actually not using the
default. I did this because on most systems, according to the alsa set
up, the default IS the dmix device. It can be configured otherwise using
alsa, system-wide.

2. Refer to this:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1184
Especially the last comment:
--- quote ---
Well, the dmix resource manager keeps the device allocated for a while
(up to 0.5sec). This has nothing related to audio bufferring. It would
be better to check for -EBUSY error code and keep trying to reopen audio
device about one or two seconds in xine-lib before giving up.
--- end quote ---
That's what solved the problem for xine.
Please note that because of the current implementation of portaudio's
Pa_Initialize, there's no chance that the retry can be done at user's
side. As the device are opened in quick succession to each other, not to
mention on most of Linux systems, the OSS devices are emulated using
ALSA interface as well.

3. Refer to this:
http://packages.debian.org/changelogs/pool/main/e/esound/esound_0.2.36-3/changelog
--- quote ---
* audio_alsa09.c: Disable snd_pcm_drain() call for now since it
sometimes triggers a race condition in the ALSA kernel driver which
causes the esd process to hang. This is not a proper bug fix, but at
least makes all those broken Colony installations out there work again.
(Ubuntu #12276)
---- end quote ----
Yes, I do realize "this is not a proper bug fix", but it enables dmix,
which to me is a deal breaker.

[aknudsen]

I've submitted changes that should address all of these concerns. Hopefully this resolves the matter.