Re: patch to esound to use ARts (KDE sound subsystem) if it's running
- From: Vlad Harchev <hvv hippo ru>
- To: Elliot Lee <sopwith redhat com>
- Cc: Christian Fredrik Kalager Schaller <Uraeus linuxrising org>, desktop-devel-list gnome org
- Subject: Re: patch to esound to use ARts (KDE sound subsystem) if it's running
- Date: Mon, 20 May 2002 23:02:08 +0500 (SAMST)
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]