On 20 June 2010 06:00, Jan Steffens <jan.steffens@xxxxxxxxx> wrote: > On Sat, Jun 19, 2010 at 10:14 PM, Ray Rashif <schivmeister@xxxxxxxxx> 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
