[arch-general] PulseAudio package group - Arch-general - lists.archlinux.org

newer
[arch-general] kernel 2.6.34-1

[arch-general] PulseAudio package group

older
[arch-general] Fwd: testing kernel...

Jan Steffens

18 May 2010 18 May '10

10:25 p.m.

I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group. This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins. Should I go ahead with this? Any suggestions?

Show replies by date

Isaac Dupree

18 May 18 May

10:44 p.m.

On 05/18/10 18:25, Jan Steffens wrote:

I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group.

This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins.

Should I go ahead with this? Any suggestions?

Sounds neat! (disclaimer: i haven't used PA on Arch, only on Ubuntu in the past.) Question: OK this would make it easy to transition *to* a PulseAudio based system, but suppose I later decide I don't like it-- is it easy to transition back to a non-PA system?(wait, it's trivial if those packages don't conflict with 'sdl' etc. -- do they?) also I wonder why the group name to be "pulse" and not "pulseaudio".

Ng Oon-Ee

10:50 p.m.

On Tue, 2010-05-18 at 18:44 -0400, Isaac Dupree wrote:

On 05/18/10 18:25, Jan Steffens wrote:

...
I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group.

This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins.

Should I go ahead with this? Any suggestions?

Sounds neat! (disclaimer: i haven't used PA on Arch, only on Ubuntu in the past.) Question: OK this would make it easy to transition *to* a PulseAudio based system, but suppose I later decide I don't like it-- is it easy to transition back to a non-PA system?(wait, it's trivial if those packages don't conflict with 'sdl' etc. -- do they?)

also I wonder why the group name to be "pulse" and not "pulseaudio".

The only thing this would make simpler is not requiring user-compilation (and the packages must conflict with sdl/openal I believe, in most cases). I'd be happy with this if only for the reason that I wouldn't have to wait for the REALLY slow mplayer downloads to compile mplayer-pulse. You may have difficulty selecting which packages though (would gnome-media-pulse qualify?).

bardo

19 May 19 May

12:07 a.m.

2010/5/19 Isaac Dupree :

also I wonder why the group name to be "pulse" and not "pulseaudio".

This was an upstream decision.

Karol Babioch

12:50 a.m.

On Wednesday 19 May 2010 00:25:41 Jan Steffens wrote:

I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group.

I think its a great idea to provide more "pulse" packages, so the installation of PulseAudio would be easier. However I don't think that the "pulse" group is a good idea at all, because by installing the whole group you force people to install applications they don't use (or need). "openal-pulse" and "sdl-pulse" would be great. I've had also some struggle to recompile "phonon-gstreamer" with PulseAudio support, so "phonon-gstreamer- pulse" would be another nice package to have. I guess there are plenty of packages that support PulseAudio, but haven't been compiled to do so yet. -- Best regards, Karol Babioch

Eric Bélanger

12:58 a.m.

On Tue, May 18, 2010 at 6:25 PM, Jan Steffens wrote:

I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group.

This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins.

Should I go ahead with this? Any suggestions?

I would suggest to apply for a jr. dev position so that the pulseaudio stuff could be moved to extra. That would save us from duplicating work by having both pulse and non-pulse packages. BTW, does adding pulse support make it a depends or optdepends? I would guess it depends on the package.

Jan Steffens

3:41 a.m.

The problem with doing that is some packages will indeed have to *depend* and not just optdepend on PA. PulseAudio installs some desktop files that causes it to autostart together with Gnome or KDE. The PA client library will start the PA server if it's not running, instead of failing. That means output libraries like sdl (which, by default, tries pulse before alsa) will start the server instead of failling back to other output methods. gnome-media, when compiled with PulseAudio support, will be inseparable from it. E.g., gnome-volume-control will only control PulseAudio. So as I see it, it would be hard to make PulseAudio part of ArchLinux without making it mandatory. On Wed, May 19, 2010 at 2:58 AM, Eric Bélanger wrote:

On Tue, May 18, 2010 at 6:25 PM, Jan Steffens wrote:

...
I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group.

This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins.

Should I go ahead with this? Any suggestions?

I would suggest to apply for a jr. dev position so that the pulseaudio stuff could be moved to extra. That would save us from duplicating work by having both pulse and non-pulse packages.

BTW, does adding pulse support make it a depends or optdepends? I would guess it depends on the package.

Eric Bélanger

5 a.m.

On Tue, May 18, 2010 at 11:41 PM, Jan Steffens wrote:

The problem with doing that is some packages will indeed have to *depend* and not just optdepend on PA.

PulseAudio installs some desktop files that causes it to autostart together with Gnome or KDE.

The PA client library will start the PA server if it's not running, instead of failing. That means output libraries like sdl (which, by default, tries pulse before alsa) will start the server instead of failling back to other output methods.

gnome-media, when compiled with PulseAudio support, will be inseparable from it. E.g., gnome-volume-control will only control PulseAudio.

So as I see it, it would be hard to make PulseAudio part of ArchLinux without making it mandatory.

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.

On Wed, May 19, 2010 at 2:58 AM, Eric Bélanger wrote:

...
On Tue, May 18, 2010 at 6:25 PM, Jan Steffens wrote:

...
I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group.

This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins.

Should I go ahead with this? Any suggestions?

I would suggest to apply for a jr. dev position so that the pulseaudio stuff could be moved to extra. That would save us from duplicating work by having both pulse and non-pulse packages.

BTW, does adding pulse support make it a depends or optdepends? I would guess it depends on the package.

Ray Rashif

7:33 a.m.

On 19/05/2010, Jan Steffens wrote:

The problem with doing that is some packages will indeed have to *depend* and not just optdepend on PA.

There are some cases where you can get away with it when there is no hard runtime dependency on the library in question. You can have them as makedepends and optdepends. You might want to check whether that is possible. Whatever it is, a group would be helpful. A lot of people are voluntarily entangled in the PA web because of some kind of confusion resulting from the number of "add-ons". -- GPG/PGP ID: B42DDCAD

b1

11:36 a.m.

Hi Since I am just a comperativly inexperienced user, it took me some time to get pulseaudio working (Digging the forum to change the asound.conf, getting vlc to work with pulse by the aur-package). I think it would be great having a package group, with which I could install all this stuff at once, alongside with the necessary configuration (asound.conf). However I can't really assess the packaging problems, so if this isn't possible, bad luck. But I would really appreciate it. Thanks Benedikt On Wed, 2010-05-19 at 00:25 +0200, Jan Steffens wrote:

I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group.

This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins.

Should I go ahead with this? Any suggestions?

甘露(Gan Lu)

3:03 p.m.

On Wed, May 19, 2010 at 7:36 PM, b1 wrote:

Hi

Since I am just a comperativly inexperienced user, it took me some time to get pulseaudio working (Digging the forum to change the asound.conf, getting vlc to work with pulse by the aur-package). I think it would be great having a package group, with which I could install all this stuff at once, alongside with the necessary configuration (asound.conf). So do I, not really complex, but you have to do it again when you re-install system or do it again for anyone else, which could be boring.

However I can't really assess the packaging problems, so if this isn't possible, bad luck.

But I would really appreciate it. I support this idea, and in fact I don't meet any problem with Fedora since version 11, which (I mean Fedora or pulseaudio) runs well on my wife's laptop, so I think it's time to adapt it someway.

Thanks

Benedikt

On Wed, 2010-05-19 at 00:25 +0200, Jan Steffens wrote:

...
I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group.

This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins.

Should I go ahead with this? Any suggestions?

5116

Age (days ago)

5117

Last active (days ago)

Download

10 comments

9 participants

tags

participants (9)

b1
bardo
Eric Bélanger
Isaac Dupree
Jan Steffens
Karol Babioch
Ng Oon-Ee
Ray Rashif
甘露(Gan Lu)