Bug#413974: gstreamer-properties needs libesd-alsa0

[Loïc Minier]

reassign 413974 gnome-desktop-environment
stop

On Fri, Mar 09, 2007, Robert Millan [ackstorm] wrote:
> >  autoaudiosink _will_ use esound if it's running (for example because
> >  the relevant configuration is set in GNOME to start esound), but this
> >  requires the esd plugin indeed.
> > 
> >  Please note that in the default install esound shouldn't be running
> >  IIRC.
> gnome-desktop-environment depends on it.

 It depends on it because people /may/ enable the sound server, but it's
 not enabled by default.  (That, and Esound is an official desktop
 module too.)

> >  Well, technically it would be useful to have it available, and I think
> >  that the latest esound plugin in gstreamer will _not_ spawn a daemon if
> >  it's not running (which is what we want); however, esound is not really
> >  rocket quality, and I wouldn't want to advocate it by pulling the
> >  elements; in fact, my personal preference goes to being able to remove
> >  it entirely.
> 
> I'm not in favour neither against that.  But if we're going to provide
> it, using it as default is mandatory.

 Why?  I think these are two independent decisions: install the sound
 server, run the sound server.  You may want to install esound and not
 run it all the time (e.g. only run it before some applications or when
 a certain user logs in).

 Beside, the fact that GStreamer will automatically prefer a running esound
 over ALSA (or OSS) makes it even easier to allow for esound to be
 running or not (you don't need to sync the "start sound server" option
 with the "preferred audiosink" one).

> >  I suppose that we should do one of these:
> >  - stop pulling esound altogether (but this would break e.g. the sound
> >    daemon option in GNOME), and suggest it only; alsa dmix should be
> >    enough for most users
> Doesn't that break for OSS users ?

 Err, I don't see any connection with OSS; this is about installing
 esound or not and the problems I see with this are:
 - if you don't install it, you can't use the "sound server" option in
   GNOME,
 - you obviously don't have software mixing, but some people have
   hardware mixing or ALSA dmix

 But it could indeed prevent mixing for people with non-working ALSA
 dmix or with OSS only and a single channel output in their hardware /
 OSS driver.  But these (rare) people could still install esound.

 The biggest problem for me in this scenario (let's call it scenario 1)
 is that the "sound server" setting is broken.  That's why I wouldn't
 follow it.

> >  - pull esound _support_ completely, that is gstreamer0.10-esd, and not
> >    only esound, but not turn it on by default
> I don't think you can safely rely on it not being started.  Have all Debian
> packages been widely tested and are known not to start esd if it's not
> running already ?

 I don't understand the direction of your remark.  We already install
 esound, so scenario 2 is about installing gstreamer0.10-esd as well so
 that GStreamer apps can use esound if it's running.  But this is still
 orthogonal to deciding to launch it or not during the session start.
   Of course, some apps could still trigger the start of esound -- this
 is the situation where we are now -- but at least if this happens in
 scenario 2, the necessary plugins would be available to permit playback
 on esound.
   IMO, scenario 2 is an enhancement over the current situation, just
 like scenario 1.  The only problem is that it makes it harder to get
 rid of esound, and that it generally sends a support statement for
 esound to the end user.  :-/

 My biggest problem with implementing scenario 2 is that we might be
 missing some use cases where pulling gstreamer-esd causes a regression.

> >  - pull support for pulseaudio instead which is a compatible replacement
> >    and is of good quality; we can't enable it by default either because
> >    it's heavy on the CPU and not all users want a sound daemon when they
> >    are happy with the capabilities of their sound card or of dmix
> Then again, what about OSS users ?  Also, I think it's too late for this
> kind of change to make it in etch.

 I don't see the relevance with OSS here either; I don't think
 pulseaudio is good enough to be pushed for all users in etch, but I
 would definitely push it a bit more for lenny.

> >  The only realistic option for etch is either to add a dep on
> >  gstreamer0.10-esd (perhaps in the meta-gnome2 package which pulls
> >  esound?), or to remove the dep on esound in meta-gnome2.
> I'm cloning this bug for gnome-desktop-environment.  Jordi, can you please do
> that (and make sure it gets into etch)?

 Fortunately you didn't clone it; we didn't reach a conclusion, and only
 a single package needs to be changed in both cases: gde; hence simply
 reassigning.

-- 
Loïc Minier <lool at dooz.org>