[arch-general] PulseAudio in [extra]
On Wed, May 19, 2010 at 7:00 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Tue, May 18, 2010 at 11:41 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
In this situation, we should go with a case by case approach. If adding pulseaudio support to a package doesn't force the use of a pulseaudio setup, then we build with it and add a pulseaudio optdepends (or depends as required). In cases like gnome-media, we provide a pulse and non-pulse version of the package. Having both of these versions in extra would enable us to use split PKGBUILD to build them. So it will add no extra work for you.
Of course, we have to wait what the other devs have to say. IIRC the past pulseaudio discussions, the main stumbling block (I don't recall other issues) was that no dev wanted to maintain it. As you are interested in it and with the jr dev scheme, that issue seem to be resolved.
I *am* interested in getting pulseaudio into [extra], and created a more detailed plan of what to do: http://gist.github.com/444917 Any comments are welcome. I am willing to apply as a junior dev to get this done, should it be approved.
On 06/19/2010 03:46 PM, Jan Steffens wrote:
On Wed, May 19, 2010 at 7:00 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Tue, May 18, 2010 at 11:41 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
In this situation, we should go with a case by case approach. If adding pulseaudio support to a package doesn't force the use of a pulseaudio setup, then we build with it and add a pulseaudio optdepends (or depends as required). In cases like gnome-media, we provide a pulse and non-pulse version of the package. Having both of these versions in extra would enable us to use split PKGBUILD to build them. So it will add no extra work for you.
Well, vlc seems to work fine if pulse is not present and vlc was compiled with pulse support, but I maybe have done something wrong when testing that, if pulse got into [extra] it may be worth a shot getting vlc to support it "out of the box". However it seems a lot of other programs will fail miserably in the same scenario or try to use pulse as default which would upset many users I guess. Also there is the case of some programs pulling jack when the user doesn't need it (it just stays put though and doesn't get in the way), so if pulse was in [extra] it might be possible to include that too for vlc as an "optdepend". As always, some users wouldn't mind while others would get really upset about that if it was a "depend". -- Mauro Santos
On Sat, Jun 19, 2010 at 6:29 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
Well, vlc seems to work fine if pulse is not present and vlc was compiled with pulse support, but I maybe have done something wrong when testing that, if pulse got into [extra] it may be worth a shot getting vlc to support it "out of the box". However it seems a lot of other programs will fail miserably in the same scenario or try to use pulse as default which would upset many users I guess.
Also there is the case of some programs pulling jack when the user doesn't need it (it just stays put though and doesn't get in the way), so if pulse was in [extra] it might be possible to include that too for vlc as an "optdepend". As always, some users wouldn't mind while others would get really upset about that if it was a "depend".
One of the problems of PulseAudio is that it pretty much becomes the default as soon as you install it. So I'm trying to avoid that, offering separate packages where needed.
On 06/19/2010 07:34 PM, Jan Steffens wrote:
One of the problems of PulseAudio is that it pretty much becomes the default as soon as you install it. So I'm trying to avoid that, offering separate packages where needed.
I was also thinking about that, somehow pulse has the nasty habit of starting with the DE or when called the first time (and then itself sort of hijack the soundcard it is using). However like I said, at least vlc (one of the 2 programs I do recompile with support for pulse, the other is mplayer and it explodes if it doesnt find pulse) seems to be able to cope with the absence of vlc in the system but I am well aware that pulse support is not enabled in vlc because pulse is still in [community]. Likewise if other programs don't explode when they don't find pulse, it would be a nice addition to have support for it enabled for the people that choose to use pulse, this just in case it gets into [extra]. -- Mauro Santos
Jan Steffens <jan.steffens@gmail.com> writes: *SNIP*
Any comments are welcome.
I am willing to apply as a junior dev to get this done, should it be approved.
Your plan leaves me with a question. Here's a quote from that document:
TODO: - What about the neccessary kernel changes? 1. Blacklist snd-{pcm,mixer,seq}-oss (tto kill off ALSA's OSS emulation)
This is apparently the common cause of Flash or other applications hogging the audio device. Also happens when you run ALSA dmix, so it's not specific to PulseAudio.
2. Boot with soundcore.preclaim_oss=0 (required for osspd)
How will this affect people who don't wish to run PulseAudio? Can they still have their ALSA OSS emulation, or will they need to run PulseAudio for applications which still use OSS? -- Chris
On 20 June 2010 03:53, Chris Brannon <cmbrannon@cox.net> wrote:
Jan Steffens <jan.steffens@gmail.com> writes:
*SNIP*
Any comments are welcome.
I am willing to apply as a junior dev to get this done, should it be approved.
Your plan leaves me with a question. Here's a quote from that document:
TODO: - What about the neccessary kernel changes? 1. Blacklist snd-{pcm,mixer,seq}-oss (tto kill off ALSA's OSS emulation)
This is apparently the common cause of Flash or other applications hogging the audio device. Also happens when you run ALSA dmix, so it's not specific to PulseAudio.
2. Boot with soundcore.preclaim_oss=0 (required for osspd)
How will this affect people who don't wish to run PulseAudio? Can they still have their ALSA OSS emulation, or will they need to run PulseAudio for applications which still use OSS?
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. Now, PA has never sparked any interest in me, nor has it motivated me to find out even the bare essentials of what makes PulseAudio, PulseAudio. But if the common options are not going to be affected, then I'm willing to help out as well. -- GPG/PGP ID: B42DDCAD
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.
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
On Sat, Jun 19, 2010 at 9:53 PM, Chris Brannon <cmbrannon@cox.net> wrote:
How will this affect people who don't wish to run PulseAudio? Can they still have their ALSA OSS emulation, or will they need to run PulseAudio for applications which still use OSS?
Most desktop users would want to blacklist the OSS emulation - it doesn't support software mixing. That means that in the absence of hardware mixing (which is usually the case with onboard audio codecs), if an application is using ALSA's built-in OSS emulation to output sound, no other application can. An alternative are wrappers like aoss and padsp, which preload a library emulating the OSS devices in userspace, outputting sound through ALSA or PulseAudio respectively. An even better alternative is osspd, which uses CUSE to provide the devices. It can redirect to either ALSA or PulseAudio. If disabling the OSS emulation would be made the default, and the modules only loaded if added to MODULES in rc.conf, I would welcome that. Disabling OSS preclaim for everyone by altering the kernel config should be safe to do. It's even in the feature removal schedule:
What: sound-slot/service-* module aliases and related clutters in sound/sound_core.c When: August 2010 Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR (14) and requests modules using custom sound-slot/service-* module aliases. The only benefit of doing this is allowing use of custom module aliases which might as well be considered a bug at this point. This preemptive claiming prevents alternative OSS implementations.
Till the feature is removed, the kernel will be requesting both sound-slot/service-* and the standard char-major-* module aliases and allow turning off the pre-claiming selectively via CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss kernel parameter.
After the transition phase is complete, both the custom module aliases and switches to disable it will go away. This removal will also allow making ALSA OSS emulation independent of sound_core. The dependency will be broken then too. Who: Tejun Heo <tj@kernel.org>
I will be testing the effects of disabling that option tomorrow.
Jan Steffens <jan.steffens@gmail.com> writes:
On Sat, Jun 19, 2010 at 9:53 PM, Chris Brannon <cmbrannon@cox.net> wrote:
How will this affect people who don't wish to run PulseAudio? Â Can they still have their ALSA OSS emulation, or will they need to run PulseAudio for applications which still use OSS?
Most desktop users would want to blacklist the OSS emulation - it doesn't support software mixing. *SNIP* An even better alternative is osspd, which uses CUSE to provide the devices. It can redirect to either ALSA or PulseAudio.
If disabling the OSS emulation would be made the default, and the modules only loaded if added to MODULES in rc.conf, I would welcome that.
Disabling OSS preclaim for everyone by altering the kernel config should be safe to do. It's even in the feature removal schedule:
Thanks for the answer. All of this sounds good, and I like your plan. -- Chris
participants (4)
-
Chris Brannon
-
Jan Steffens
-
Mauro Santos
-
Ray Rashif