Hi Loïc,
I'm keeping you and esound maintainer in CC.
On Mon, Sep 12, 2005 at 03:40:35PM +0200, Loïc Minier wrote:
> This looks clearly like a bug in esound to me, and I'm reassigning it
> to the esound package.
Unfortunately Esound isn't developed anymore and is maintained only
because it's in gnome (from README) :( Maybe maiintainers will get more
info.
In all this stuff what underlies is that some sort of bad behaviour is
detected. Don't know if it's a architectuarl problem or not.
Actually the behaviour esdctl has is not a problem to me, at least now.
It stops clients too, that's might be OK (even if I'd prefer to silently
ignore output to DSP, discarding inputs)
The bug in rhythmbox, for which I filed a report, is that he cannot
detect that gst exited _not_ because track was ended _but_ because
of an external event (esdctl off) occurred that prevents gst to go on,
and jumps to the next track.
It leads to get the box heavely loaded until esdctl is resumed or pause
is pressed, because each time next track is pushed in gst pipe, gst try
to play and loads the box itself.
The fact that gst loads the box is a minor problems, because it simply
exits in a bunch of seconds.
So, the main problem do not resides in esound (IMHO) but in a bad
communication between gst and rhythmbox.
What I actually don't know is if gst can handle but rhythmbox ignores it
(a rhythmbox bug) or gst cannot handle it and exits normally (gst bug).
I'd avoid to reassing it to esound.
that's my 2 cents,
c.
