Mailinglist Archive: opensuse-packaging (139 mails)

[Adrian Schröter <adrian@xxxxxxx>]

On Wednesday 12 March 2008 22:46:51 wrote Wade Berrier:
> Hi,
>
> 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
> > > > PulseAudio)?
> > > > 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
> of pulseaudio.
>
> (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 ?

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 ...

-- 

Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
email: adrian@xxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx