On 20 June 2010 06:00, Jan Steffens <jan.steffens@gmail.com> wrote:
On Sat, Jun 19, 2010 at 10:14 PM, Ray Rashif <schivmeister@gmail.com> wrote:
Could you cite a case or reproduction whereby via ALSA's dmix, an instance of Flash has reserved the output for itself? The last time that ever occured was before dmix got into mainline ALSA, where OSS was a valid output within Flash and there was a way to use 'aoss'. I don't know whether that remains to be the case, but it should not and I have not faced this issue for a long time.
I can't cite anything, but I remember helping multiple people on IRC during the last year.
Even if it's not Flash, any application grabbing the OSS output will cause this problem. Or may fail to output sound if the device is already in use by dmix or pulse.
Yes, that's correct. It's only a problem if the first sound program to run defaults to OSS as a primary output device, and almost everything but the most archaic of tools should've stopped doing that by now. For eg. I have all the in-kernel OSS emulation modules loaded, yet Flash and MPlayer are playing fine together: $ lsof | grep pcm knotify4 3784 schiv mem CHR 116,4 5290 /dev/snd/pcmC0D0p knotify4 3784 schiv 14u CHR 116,4 0t0 5290 /dev/snd/pcmC0D0p chromium 6677 schiv mem CHR 116,4 5290 /dev/snd/pcmC0D0p chromium 6677 schiv 35u CHR 116,4 0t0 5290 /dev/snd/pcmC0D0p mplayer 7950 schiv mem CHR 116,4 5290 /dev/snd/pcmC0D0p mplayer 7950 schiv 6u CHR 116,4 0t0 5290 /dev/snd/pcmC0D0p Here I make a presumption that even if one of those snd devices is a mapping to /dev/dsp (MPlayer does complain that it's busy if used with '-ao oss'), I'm still able to play multiple streams at once. So to me, it doesn't make much of a difference if the modules are loaded by default or not. I believe we're doing that via our own udev rules, so it shouldn't be too much of a big deal. However, for a bigger audience, I say we leave it as it is for now. In any case, your plan looks good. -- GPG/PGP ID: B42DDCAD