On Mon, Sep 12, 2005 at 09:16:30AM +0200, Loïc Minier wrote:
> I'm not sure of what "esdctl off" tries to achieve: if it's only a
> matter of not producing any sound, then it shouldn't disrupt any
> application using esound; if it's goal encompass perturbing the
> application, then you simply shouldn't use it or suffer the
> consequences.
What esdctl(1) says about off/on:
standby, off suspend sound output for other programs
resume, on resume sound output
So at a first read I understand it simply accepts input but unlocks dsp.
Anyway There's no problem in stopping application, if it's wanted
(changing accordingly manpage).
> > The bug can be splitted: the CPU load part due to gst, but the "going on
> > next track instead of pausing" still be on rhythmbox side IMHO.
> Again, I don't see any reason why you blame the rhythmbox application
> in this case: it is certainly not a nominal case to remove a sound card
> from a system while playing. If your goal is to pause rhythmbox, then
> you can simply use the pause button.
That's not removing a sound card, but suspending esd to sending output
to its DSP.
The reason is becasue you want to use something that not supporting
esound, for instance gnomemeeting (it seems that communication quality
suffers and gets delayed using esd instead of direct ALSA).
Suspending esound is a normal operation, AFAIK, and esdctl is the way
intended for handle it without killing esd.
Anyway when a communication is started by gnomemeeting, esound is
suspended by gnomemeeting itself, so there's no way to avoid it unless
you've more then a DSP to use.
thanks,
c.
