[arch-general] PulseAudio in [extra]

[Ray Rashif]

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