Mailinglist Archive: opensuse-packaging (139 mails)
|< Previous||Next >|
Re: [opensuse-packaging] PulseAudio plans for suse 11.0
- From: Wade Berrier <wberrier@xxxxxxxxxx>
- Date: Wed, 12 Mar 2008 17:43:08 -0600
- Message-id: <1205365388.10300.52.camel@xxxxxxxxxxxxx>
On Wed, 2008-03-12 at 22:59 +0100, Adrian Schröter wrote:
On Wednesday 12 March 2008 22:46:51 wrote Wade Berrier:
On Wed, 2008-03-12 at 18:07 +0100, Ludwig Nussel wrote:
Marcus Rueckert wrote:
On 2008-03-12 17:45:05 +0100, Christian Morales Vega wrote:
In any case what openSUSE will do is something must be cleared.
For what I understood Gnome is going to use PulseAudio yes or yes.
Upstream will port their apps to PulseAudio and openSUSE can't patch
all of them, correct?
GStreamer, xine... they can't have a default output for KDE and
another one for Gnome. KDE4 will use Phonon, that can use xine or
gstreamer like backend. Will KDE4 apps use PulseAudio when Phonon
uses gstreamer and ALSA directly when Phonon uses xine? In the first
case apps will have *two* per application volume controls (Phonon and
Without a clear path this could be very confusing.
ideally pulseaudio and phonon would be just wrapper for that
functionally inside alsa.
Quoting the fedora-devel mail:
6. If you have an application that uses ALSA, please make sure that it
doesn't hardcode ALSA driver names (i.e. something like "hw:0"), it
should use "default" instead, which is now being redirected to
"pulse", our plugin for libasound. Hardcoding ALSA device names
(besides "default") is a bug in your application anyway, so here
you have yet another reason to fix that!
So there is an alsa plugin and if an application normally uses alsa
it will transparently use pulseaudio. No application change
required. Sounds sane to me. I wonder whether that also works for
applications that support surround sound such as quake4 though.
I'm not sure either... but, if it fails, this would be an instance where
the real quake binary could be wrapped in a shell wrapper that also runs
'pasuspender' beforehand so that quake could use the hardware directly.
I brought this up on opensuse-packaging with the hope of preconfiguring
all apps (patching our packages to: create wrappers, modify default
config files, etc... ) so they would work with pulseaudio.
The goal: to be running any desktop environment, start up any
application that uses sound, have sound actually work (even when using a
cheap sound card that does no hardware mixing), and get all the features
(I'm currently using one of those cheap cards, but am almost frustrated
at the point of buying a sound card that can mix 32 streams in hardware
just so I can hear pidgin beeps and hear flash video at the same time :)
Was there any problem in the last years ?
Not so much when I had a card with at least 4 ports for hardware mixing,
but when using a 1 port card, definitely yes. There always seem to be
oss apps that hog my sound card.
Plus, as a gnome user, some apps still expect to output sound to esd
(instead of going to gstreamer as they should).
And surely some headaches come from me trying to configure everything to
work with pulse, but the features of pulse are important to me. I think
it's doable to have both: features of pulse, all apps working.
I can only remeber that some sound cards, which do not support mixing where
not configure with dmix. But beside of that, I think we got rid off all
problems since that we dropped sound server in KDE 3 and used plain alsa.
From that perspective, I fear more steps backward than forward with
introducing a sound daemon again ...
I agree there may be steps taken backwards in transition, but the
feature set of pulse makes it possible to move ahead of where alsa alone
is capable of.
|< Previous||Next >|