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



On Mon, 20 May 2002, Elliot Lee wrote:

> 
> > 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
> 
> Hmm, maybe this limitation needs fixing.

 That's questionable..

> >  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.
> 
> >  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!
> 
> Well, it might be more beneficial to fix these problems in artsdsp (and
> help programs that use neither libarts* nor libesd) rather than fix only
> libesd-using programs.

 And one will need to write support for other 7 sound systems esd supports
(or at least ALSA) for it to be considered a fully functionaly esd->arts
proxy.

 Also Igor says that artsdsp doesn't support sound recording too.
 But that is nothing compared to support of esd compiled with OSS driver
only..
 
> > > . 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.
> 
> I don't think you are accurately estimating the severity of the problem on
> a wide range of systems... Conceptually the chaining seems sort of ugly to 
> me anyways, but I'm sure you'll find the best solution given all the 
> constraints.

 At least on modern hardware the delay is not noticable, even in games played
under wine (sound is passing 3 layers!) - i.e. in realtime-requiring
applications. This should be enough, shouldn't it?
And anyway, somebody will have to approve the patch :)

 The good news are the following - Igor attached an updated version of the
patch that modifies just the sound server main loop (and doesn't touch any
driver) to that bugzilla ticket - see

	http://bugzilla.gnome.org/show_bug.cgi?id=82154

 Guys, what do you think about it now?
 Please review it.
 
 Thanks for input!

 Best regards,
  -Vlad




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]