ESD issues

[Wytter]

I have been testing how the latest CVS behaves with a sound server daemon running, and even though it seems to run fine using artsd (v1.1.5) even while playing music in xmms and video in xine.

But I have run into some issues when using ESD (latest version available...). I'm not sure whether these issues have anything to do with EL, glibc, ESD or OpenAL, but I think they're it's worth mentioning

 

When playing music in xmms at the same time as running Eternal Lands this will happen:

First of all there are performance problems when starting the game (mouse cursor is very laggy etc.) and in the game it runs with lower framerates than normally... The CPU usage of ESD is not higher than normal.

Second of all there's a memory leakage in Eternal Lands where it would use ~77.5% of my system ressources (512MB RAM+1024MB Swap).

By doing a backtrace in gdb the system seems to halt in libpthread.so.0 waiting for a restart signal upon exit (I have to kill the process to end it).

Furthermore the game is very laggy upon entering, and this caused 2 server resyncs which caused me to be cloned...

 

When ESD is not used by another program the following will happen:

The application runs normally, but with lower performance than normal. The program exits normally.

 

I'll try to get it working with the Jack Sound Daemon next...

[Leeloo]

From http://www.xmms.org/

 

"I don't know why and I'm not yet motivated to fix it since my views on esd are mostly unprintable."

- Alan Cox

 

I don't know what exactly ESD does to get that description, but it must be pretty bad. And since we don't use ESD at all, ESD-related problems must be in either OpenAL (the sound library) or ESD itself. I.e. we can't fix it in the EL client, it must be fixed somewhere else.

[Wytter]

I know that ESD has caused troubles from time to time, but I am able to listen to music from xmms, play a movie in xine etc. with ESD. Just promised Cicero to try out some different sound servers

 

Starting the program with esddsp will cause all of the sounds to be piped through ESD.

 

I have the latest CVS-version of OpenAL - that might also be the cause of the problem - I'll try with Cicero's snapshot...

 

It might be a good idea to inform users of these problems though (in a Technical FAQ perhaps)...

[Cicero]

It's true, I did tell him to try and break it

 

There's a lot of things that are out of my control. OpenAL (and specifically, the alut) controls how it accesses the sound device. There is some platform specific code that I could write to initialize everything manually, but it would be messy and probably not fix anything.

[Leeloo]

No, I believe it's ESD that is broken... So unless your custom initialization code includes system("killall esd"); it probably won't fix anything.

 

(Bun don't killall anything on a HP/UX or Solaris machine).

[Wytter]

Just write a warning for ESD-users (I doubt it that there are many ) that ESD and the current sound implementation is broken, and that if they want to use a sound server daemon they should use artsd...

[Leeloo]

Last time I checked, artsd was for KDE, and esd was for Gnome. So, unless that's changed recently, they are not interchangable.

[Wytter]

Last time I checked, artsd was for KDE, and esd was for Gnome. So, unless that's changed recently, they are not interchangable.

You can use artsd in gnome - but originally artsd is for KDE and ESD is intended for Gnome - but really, who wants to use a broken sound server daemon?

[Leeloo]

You know, there is a reason that I did a chmod -x /usr/local/bin/esd :-)

[duran]

and why use a soundserver at all? alsa does the job nicely on any newer soundcard from what i udnerstand.

 

oh and the E in ESD stands for enlightenment...

[Wytter]

Nope, it's Enlightened Sound Daemon http://www.gnome.org/softwaremap/projects/esound/

 

Not all soundcards or drivers supports hardware mixing, so a sound server daemon is still necissary for some...

 

Alsa can do some low level mixing though, through the function called dmix.