Re: patch to esound to use ARts (KDE sound subsystem) if it's running

[Vlad Harchev <hvv hippo ru>]

On Sun, 19 May 2002, Elliot Lee wrote:

 Hi, 

> On 19 May 2002, Christian Fredrik Kalager Schaller wrote:
> 
> > Personally I think it sounds like a situation that has to give people
> > even more 'stuttering' when playing back sound through sound servers
> > (which I why I use none :), but if that isn't the case I think putting
> > it in is probably a good idea. Frederic Crozat, the maintainer, is on
> > vacation till the end of the month, but I think Elliot Lee have full
> > commit permits so I am adding him to the to list.
> 
> This is an aweful idea with an aweful implementation.
> 
> The idea is aweful because of possibility for the two layers thing.

 Why two layers are that bad? There is no noticable difference when sound is
passing through 2 layers (with this patch).
 
> The implementation is aweful because it patches every single sound driver.
> Instead of patching every single sound driver in esound, which isn't
> acceptable, the implementation could just be an audio_arts sound driver
> (which has drawbacks, but none worse than hacking every single sound
> driver).

 OK, next version of the patch will modify just esd.c and will add
implementations of drivers' methods for arts and will use either usual
driver's methods or arts-oriented substitutions. Arts support can't be made
just a driver - currently given esd binary can't have several drivers compiled
in since methods of the different drivers have the same name, so
either user will have to build several server binaries (and fiddle with
symlinks) or just give up.

> arts and esound both suck, let's not make it worse. :)
> 
> Possible solutions:
> . The solution suggested in the arts FAQ ('artsdsp esd') will provide the 
> same level of functionality as the patch, but without any patching. I 
> would take a patch to control exactly how esdlib auto-spawns esd, so that 
> running esd via artsdsp is automatic.

 This is unacceptable. As Igor (the patch's author) says, this will work if
esd is compiled with OSS driver only. It won't work if esd is compiled with
most other drivers - most importantly ALSA. This may be acceptable on RedHats
that don't support ALSA in any way, but it won't be on other more
desktop-oriented linux distributions that prefer ALSA to OSS.

 Also as Igor says, even with OSS the artsdsp works very bad - the latency is
noticable and sometimes the sound corrupts unacceptably - when playing games
in under WINE (that uses esd playing via artsdsp)  sometimes sound disappears
completely!

> . Getting esd to talk the arts protocol (not terribly likely) or artsd to 
> talk the esound protocol (maybe more possible than with esd, since I am 
> guessing the artsd source code is a little more modular than that of esd)

 This could be needed if the latency when esd is playing  via arts was
unacceptable, but it doesn't, so the complication does't worse the efforts.

> . Using a sound card that has hardware mixing, and running both daemons.

 That's not interesting case :)

> . Writing a sound server that doesn't suck (something that I have 
> threatened to do for umpteen years, but never followed through on so far 
> :)

 :)

 Yes, this seems to be a best solution provided it supports esd and arts
protocols..

> All of these solutions seem saner than the proposed patch.

 It seems the updated version of the patch (that modifies just esd.c) will be
announced soon here.

 Thank you for your input, it was very valuable!

 Best regards,
  -Vlad