I'm running GNOME.  For GNOME to be able to play system sounds, I have
the "esd" sound daemon running.

If I start xscavenger, I get no sound.

If I first kill esd and then start xscavenger I get sound.

I'd like xscavenger to automatically detect there's a sound daemon
running, and talk nicely to it.

On Fri, Mar 11, 2005 at 05:59:15PM +0100, Johan Walles wrote:
[...]
[...]

Currently, xscavenger uses /dev/dsp directly, which is probably why
you have to kill esd first.

Also, I don't have GNOME on my desktop; would you be willing to help
me with testing the fix? Thanks.


T

Yes, I'd be willing to help you test a fix.

However, ESound doesn't require GNOME, so you should be able to apt-get
install esound and then start the sound daemon with "esd".  This should
make it simple for you to test your fix yourself.

As for the implementation, I don't have much experience with neither
sound in general nor ESound in particular, but there are two ways I can
come up with for doing this.

The first is to use SDL for the sound.  AFAIU that should give you
sound server detection and integration "for free".

The second (more scriptable, possibly a simpler implementation) would
be to use esddsp ("apt-get install esound-clients" first).  Its man
page is great :-).

  Regards //Johan

On Fri, Mar 11, 2005 at 05:59:15PM +0100, Johan Walles wrote:
[...]
have
[...]

Currently, xscavenger uses /dev/dsp directly, which is probably why
you have to kill esd first.

Also, I don't have GNOME on my desktop; would you be willing to help
me with testing the fix? Thanks.


T

----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info

Hi, just FYI, I've managed to implement a (very rough) prototype fix
that makes xscavenger work with esd. Unfortunately, I'm running into
some hard problems:

- esd shows horrible latency when in stream mode (which is the easiest
  to implement on the existing code), making the sound delayed and
  unsynchronized with game events.

- I've tried to resolve this by using the sample caching feature,
  which solves the synchronization problem, but it is very inflexible:
  the falling sound cannot be stopped until the entire clip is played,
  and I can't play multiple sounds at the same time (which is what
  xscavenger's internal mixer currently does).

Given these problems, I'm becoming a bit hesitant about esd support.
I'll take a look at the SDL code to see how they did it, but I'm
inclined not to use SDL because of the way the existing code is
written (difficult to port to a new API), and I dislike introducing
additional dependencies into xscavenger.

If you're interested in testing out the prototype fix anyway, let me
know and I'll send you a testing .deb package. Be warned, though,
there's an as-yet unidentified problem with playing the samples
through esd, which causes sound distortion. :-)


T

Hi!

Very cool that you're looking into this.

You're saying that you're reluctant to use SDL since that would
introduce calls into a new API.  But doesn't implementing ESD support
"manually" give you the same issues?  Or is it that the ESD API is
close enough to what XScavenger already has that the changes aren't as
big as what SDL sound would require?

SDL would have the advantage over pure ESD that it auto-detects and
talks to other sound daemons as well (like KDE's ARTS), but of course
SDL might have drawbacks.  As I haven't really used neither SDL nor ESD
I'm unforturnately not the right person to give advice here...

Anyway, I won't be able to look at anything before the end of March,
but if you want feedback on anything I will look at it after that.

  Regards //Johan

Hi, just FYI, I've managed to implement a (very rough) prototype fix
that makes xscavenger work with esd. Unfortunately, I'm running into
some hard problems:

- esd shows horrible latency when in stream mode (which is the easiest
  to implement on the existing code), making the sound delayed and
  unsynchronized with game events.

- I've tried to resolve this by using the sample caching feature,
  which solves the synchronization problem, but it is very inflexible:
  the falling sound cannot be stopped until the entire clip is played,
  and I can't play multiple sounds at the same time (which is what
  xscavenger's internal mixer currently does).

Given these problems, I'm becoming a bit hesitant about esd support.
I'll take a look at the SDL code to see how they did it, but I'm
inclined not to use SDL because of the way the existing code is
written (difficult to port to a new API), and I dislike introducing
additional dependencies into xscavenger.

If you're interested in testing out the prototype fix anyway, let me
know and I'll send you a testing .deb package. Be warned, though,
there's an as-yet unidentified problem with playing the samples
through esd, which causes sound distortion. :-)


T
----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info

On Fri, Mar 18, 2005 at 12:42:07PM -0800, Johan Walles wrote:
[...]

Actually, now that I've gritted my teeth on libesd a bit, perhaps I
should try SDL instead. :-) ESD seems to require manual
synchronization, which is very tricky. I still haven't figured out how
to make it work properly yet.
[...]

OK, if you really want, you can try this package:

http://quickfur.ath.cx:8080/~hsteoh/debian/xscavenger_1.4.4-4_i386.deb

Warning: this is an unofficial version, and you probably want to keep
the "official" .deb handy. The sound in this version is very screwy
when used with esd. (But I made it so that it will use /dev/dsp as
before if esd is not running. So if you want a normal game with normal
sound, you can just stop esd before running xscavenger, as before.)

There are timing/sync issues that make the sound get out of sync with
the game as the level progresses, and there's apparently also some
sampling problem that makes the sound come out distorted. I haven't
been able to figure out how to fix this.


T

Hi, it's seems that, more generaly, when a sound is already playing on the
system, Xscavenger stays quiet(e.g. when the following is running in the
background: mplayer -afm ffmpeg -ao alsa -cache 599 -cache-min 99 -framedrop
-lavdopts fast:skiploopfilter=all -msgcolor -msglevel all=6 -noconfig user 
-noar -nolirc -softvol https://radios.rtbf.be/classic21-128.mp3)

Hi, after more games played, it seems that the behaviour is inconsistent.
Anyway, I'm stuck at level twelve. I've briefly become addicted to levels
creation while editing it to make it playable.