[opensuse-kde] PulseAudio for KDE in 11.4
After management found some loose change down the back of the sofa at the end of the quarter I spent it on some Bluetooth kit including a headset to test the new Bluedevil KDE Bluetooth UI. This morning I got the headset working with KDE SC 4.5. I would like to discuss testing PulseAudio for KDE in openSUSE 11.4. I hope that by then our crash test dummies who are already using PA will have run over all the major, frequent bugs in implementation and deployment for us. The advantage over plain ALSA that appeals to me is allowing the user to do some useful configuration of her audio environment with UI tools, as this covers the (for example) Bluetooth case of configuring music/effects to come out of the speakers while VOIP calls are handled by a headset. I guess you can do that with ALSA but it will probably be a static setup and there is no KDE UI for it. Since KDE SC 4.5 there is a nice UI for configuring PulseAudio's Phonon backend, and KMix supports dynamic PA mixers and application audio streams. When 4.6 is released there will be a speaker setup System Settings module that can let you select audio processing depending on your speaker setup and configure audio profiles for devices. The other reason for embracing PA is that it's not going away from the distribution. At the moment (11.3) we have kept the zombies away from our sound cards on the KDE CD by removing anything that uses it, but this is fragile - most users will soon install other software that pulls in PA as a dependency. By testing out PA now we can help fix bugs in the KDE infrastructure and discover problems with the rest of openSUSE's KDE multimedia stack (eg see how Phonon VLC works with PA. FWIW, the steps I had to take to get the headset working with KDE:Distro:Factory on 11.3 are: (steps we would preconfigure OOTB for 11.4) * install pulseaudio, pulseaudio-module-bluetooth and pulseaudio-module-x11 * register KDE:Unstable:Playground repo * install bluedevil and start it with Service Manager (or relogin) * uninstall kbluetooth (not necessary but removes confusion due to 2 bluetooth icons) * start pulseaudio manually (or relogin) * execute start-bluetooth-x11 and start-bluetooth-kde * from the Bluetooth system tray, Manage Devices... * Put the headset into pairing mode * Add Device and run through the wizard with default settings. * Click 'trust' in the Bluetooth Device Manager. * restart kmix (or relogin) * Play some music * In kmix, open the mixer window and go to playback streams, right click the eg amarok stream and select 'Move' to the headset device. Make sure the stream and the headset playback device are not muted. The last step won't be necessary once we rebuild kdebase4-runtime with PulseAudio support, since then the Phonon KCM allows phonon sound categories to be routed to specific devices. Thoughts? More info and debugging tips at http://pulseaudio.org/wiki/KDE Will -- Will Stephenson, KDE Developer, openSUSE Boosters Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 30 July 2010 15:54, Will Stephenson <wstephenson@suse.de> wrote:
After management found some loose change down the back of the sofa at the end of the quarter I spent it on some Bluetooth kit including a headset to test the new Bluedevil KDE Bluetooth UI. This morning I got the headset working with KDE SC 4.5.
I would like to discuss testing PulseAudio for KDE in openSUSE 11.4.
I hope that by then our crash test dummies who are already using PA will have run over all the major, frequent bugs in implementation and deployment for us.
The advantage over plain ALSA that appeals to me is allowing the user to do some useful configuration of her audio environment with UI tools, as this covers the (for example) Bluetooth case of configuring music/effects to come out of the speakers while VOIP calls are handled by a headset. I guess you can do that with ALSA but it will probably be a static setup and there is no KDE UI for it.
Since KDE SC 4.5 there is a nice UI for configuring PulseAudio's Phonon backend, and KMix supports dynamic PA mixers and application audio streams. When 4.6 is released there will be a speaker setup System Settings module that can let you select audio processing depending on your speaker setup and configure audio profiles for devices.
The other reason for embracing PA is that it's not going away from the distribution. At the moment (11.3) we have kept the zombies away from our sound cards on the KDE CD by removing anything that uses it, but this is fragile - most users will soon install other software that pulls in PA as a dependency.
By testing out PA now we can help fix bugs in the KDE infrastructure and discover problems with the rest of openSUSE's KDE multimedia stack (eg see how Phonon VLC works with PA.
FWIW, the steps I had to take to get the headset working with KDE:Distro:Factory on 11.3 are:
(steps we would preconfigure OOTB for 11.4) * install pulseaudio, pulseaudio-module-bluetooth and pulseaudio-module-x11 * register KDE:Unstable:Playground repo * install bluedevil and start it with Service Manager (or relogin) * uninstall kbluetooth (not necessary but removes confusion due to 2 bluetooth icons) * start pulseaudio manually (or relogin) * execute start-bluetooth-x11 and start-bluetooth-kde
* from the Bluetooth system tray, Manage Devices... * Put the headset into pairing mode * Add Device and run through the wizard with default settings. * Click 'trust' in the Bluetooth Device Manager.
* restart kmix (or relogin) * Play some music * In kmix, open the mixer window and go to playback streams, right click the eg amarok stream and select 'Move' to the headset device. Make sure the stream and the headset playback device are not muted.
The last step won't be necessary once we rebuild kdebase4-runtime with PulseAudio support, since then the Phonon KCM allows phonon sound categories to be routed to specific devices.
Thoughts?
More info and debugging tips at http://pulseaudio.org/wiki/KDE
Will
Sounds reasonable to me. Vadym -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Fredag den 30. juli 2010 16:54:28 skrev Will Stephenson:
I would like to discuss testing PulseAudio for KDE in openSUSE 11.4.
Thoughts?
I don't have a big problem with it. I guess it's inevitable. I just pray that the upstream KDE developers and openSUSE package dependencies will do everything possible to avoid "hard dependencies" on it, so at least people _can_ get rid of it, if it fscks up on their hardware or with the apps they use etc. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Fredag den 30. juli 2010 16:54:28 skrev Will Stephenson:
I would like to discuss testing PulseAudio for KDE in openSUSE 11.4.
Thoughts?
I don't have a big problem with it. I guess it's inevitable.
I just pray that
dependencies will do everything possible to avoid "hard dependencies" on it, so at least people _can_ get rid of it, if it fscks up on their hardware or with the apps
On Friday 30 July 2010 19:03:28 Martin Schlander wrote: the upstream KDE developers and openSUSE package they use etc. I think that's fairly safe; 4.5 falls back at runtime to the existing Phonon backends if pulseaudio is not present, and since we have this great abstraction layer, I don't see anyone making PA a hard dependency upstream. But how do we implement this at a packaging level? Just put it in the patterns? Make kdebase4-runtime Recommends: it? (NB this is a soft dep that can be broken, but that will be used by YaST and zypper to pull in the dep when installing kdebase4-runtime. I'm not sure if PA would be reinstalled if the user did a subsequent zypper dup without making PA taboo. Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
2010/7/30 Will Stephenson <wstephenson@suse.de>:
Fredag den 30. juli 2010 16:54:28 skrev Will Stephenson:
I would like to discuss testing PulseAudio for KDE in openSUSE 11.4.
Thoughts?
I don't have a big problem with it. I guess it's inevitable.
I just pray that
dependencies will do everything possible to avoid "hard dependencies" on it, so at least people _can_ get rid of it, if it fscks up on their hardware or with the apps
On Friday 30 July 2010 19:03:28 Martin Schlander wrote: the upstream KDE developers and openSUSE package they use etc.
I think that's fairly safe; 4.5 falls back at runtime to the existing Phonon backends if pulseaudio is not present, and since we have this great abstraction layer, I don't see anyone making PA a hard dependency upstream.
But how do we implement this at a packaging level? Just put it in the patterns? Make kdebase4-runtime Recommends: it? (NB this is a soft dep that can be broken, but that will be used by YaST and zypper to pull in the dep when installing kdebase4-runtime. I'm not sure if PA would be reinstalled if the user did a subsequent zypper dup without making PA taboo.
Right now the only thing that gets installed is libpulse0 and libpulse-mainloop-glib0 (both required by libphonon anyway). The """problem""" would be the daemon from the "pulseaudio" package. And the only packages that require it are subpackages of pulseaudio, alsa-plugins-pulse and package-lists-openSUSE-images (I don't see why another package would require it). So don't worry about this. If someone doesn't wants to use PulseAudio he just needs to uninstall it. And if you want to additionally "recommend" it somewhere instead of requiring it still there is no problem. By default PulseAudio is installed, and If someone uninstalls it it will be added to /var/lib/zypp/SoftLocks. Once it's in the SoftLocks file the "recommends" are basically converted to "suggests", so no automatic installation. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Fredag den 30. juli 2010 19:15:40 skrev Will Stephenson:
On Friday 30 July 2010 19:03:28 Martin Schlander wrote:
it, so at least people _can_ get rid of it
I think that's fairly safe; 4.5 falls back at runtime to the existing Phonon backends if pulseaudio is not present, and since we have this great abstraction layer, I don't see anyone making PA a hard dependency upstream.
But how do we implement this at a packaging level? Just put it in the patterns? Make kdebase4-runtime Recommends: it? (NB this is a soft dep that can be broken, but that will be used by YaST and zypper to pull in the dep when installing kdebase4-runtime. I'm not sure if PA would be reinstalled if the user did a subsequent zypper dup without making PA taboo.
I'm not sure what the best way to do it is. But 'zypper dup' reinstalling it is not something I'd consider a problem. If the user runs 'zypper dup' he forfeits whining privileges in my book. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Friday 30 July 2010, 20:56:25 Martin Schlander wrote:
Fredag den 30. juli 2010 19:15:40 skrev Will Stephenson:
On Friday 30 July 2010 19:03:28 Martin Schlander wrote:
it, so at least people
_can_ get rid of it
I think that's fairly safe; 4.5 falls back at runtime to the existing Phonon backends if pulseaudio is not present, and since we have this great abstraction layer, I don't see anyone making PA a hard dependency upstream.
But how do we implement this at a packaging level? Just put it in the patterns? Make kdebase4-runtime Recommends: it? (NB this is a soft dep that can be broken, but that will be used by YaST and zypper to pull in the dep when installing kdebase4-runtime. I'm not sure if PA would be reinstalled if the user did a subsequent zypper dup without making PA taboo.
How about only starting the daemon (and insserv'ing it) on the first install attempt only? (Isn't that the usual default of system services?) If it does harm on a system, we can tell the user to stop the service. That implies: as long as the daemon is dead, PA should behave as not being there.
I'm not sure what the best way to do it is.
But 'zypper dup' reinstalling it is not something I'd consider a problem. If the user runs 'zypper dup' he forfeits whining privileges in my book.
Hmm, how do you do your usual update tasks with say a dozen repos containing overlapping packages and be sure, that you get the most current ones? zypper dup is the most useful zypper command, and I tend to believe, that for those who run zypper directly, it's the most frequently used one, too. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Fredag den 30. juli 2010 22:23:02 skrev Hans-Peter Jansen:
On Friday 30 July 2010, 20:56:25 Martin Schlander wrote:
But 'zypper dup' reinstalling it is not something I'd consider a problem. If the user runs 'zypper dup' he forfeits whining privileges in my book.
Hmm, how do you do your usual update tasks with say a dozen repos containing overlapping packages and be sure, that you get the most current ones?
zypper dup is the most useful zypper command, and I tend to believe, that for those who run zypper directly, it's the most frequently used one, too.
I normally use yast and cherrypick my updates one repo at a time. Cuz I want to know what I update, and where it comes from. But when I do use zypper, 'zypper up' should suffice, or in some extreme cases, like a major upgrade of KDE I'd do 'zypper dup --from <repo>' But I'd never ever do a straight 'zypper dup' unless I actually wanted to do a full distro-upgrade (except in the milestone testing phase, but then I wouldn't have many additional repos). And _if_ a time should come where I just wanted whatever package has the hightest version number, no matter where it comes from and how much repo-ping- pong there'd be etc., then I'd allow vendor change in zypp.conf, and just use 'zypper up' -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Friday July 30 2010 22:23:02 Hans-Peter Jansen wrote:
On Friday 30 July 2010, 20:56:25 Martin Schlander wrote:
Fredag den 30. juli 2010 19:15:40 skrev Will Stephenson:
On Friday 30 July 2010 19:03:28 Martin Schlander wrote:
it, so at least people
_can_ get rid of it
I think that's fairly safe; 4.5 falls back at runtime to the existing Phonon backends if pulseaudio is not present, and since we have this great abstraction layer, I don't see anyone making PA a hard dependency upstream.
But how do we implement this at a packaging level? Just put it in the patterns? Make kdebase4-runtime Recommends: it? (NB this is a soft dep that can be broken, but that will be used by YaST and zypper to pull in the dep when installing kdebase4-runtime. I'm not sure if PA would be reinstalled if the user did a subsequent zypper dup without making PA taboo.
How about only starting the daemon (and insserv'ing it) on the first install attempt only? (Isn't that the usual default of system services?) If it does harm on a system, we can tell the user to stop the service. That implies: as long as the daemon is dead, PA should behave as not being there.
I'm not sure what the best way to do it is.
But 'zypper dup' reinstalling it is not something I'd consider a problem. If the user runs 'zypper dup' he forfeits whining privileges in my book.
Hmm, how do you do your usual update tasks with say a dozen repos containing overlapping packages and be sure, that you get the most current ones?
zypper dup is the most useful zypper command, and I tend to believe, that for those who run zypper directly, it's the most frequently used one, too.
Why on earth would you run "dup" regularly? It just switches your packages randomly around between all your enabled repos. Simply use "up" instead and be done with it.
Cheers, Pete -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
participants (6)
-
Cristian Morales Vega -
Hans-Peter Jansen -
Martin Schlander -
Stephan Kleine -
Vadym Krevs -
Will Stephenson