“Sam” == Sam Lantinga writes:
Sam> ESD has an autostandby mode in which it will release the
Sam> soundcard if there has been no activity for a while. Currently,
Sam> if an SDL application starts up when ESD is idle, then SDL will
Sam> grab the soundcard and ESD will not be able to run.
Which–for the benefit of people who haven’t yet seen this–has the
side effect of delaying, without any hint as to why, any activity that
is normally accompanied by a sound. This includes popping up a new
window or moving the GNOME panel to the side. Then, when the
SDL-using app quits, all the queued activity takes place. Although
it’s not SDL’s fault, it’s still a pretty ugly situation to get into,
especially for the user who doesn’t know what’s going on.
Sam> The RedHat 6.1 default (?) configuration has ESD set up this
Sam> way, but also turns on window manager sounds so that the window
Sam> manager will hang if it can’t play sounds for some reason.
Although in earlier e-mail to you I said that I thought the RH 6.1
default was to use ESD, I was mistaken.
As a test I removed ~/.gnome/sound/system to see what defaults I would
get and ESD isn’t started by default and you can’t get sound cues
unless you click the box to make it start. I created a new test
account and verified that it gets the same defaults.
Sam> I consider this a bug in the window manager, but it’s affecting
Sam> lots of SDL-game users.
Yes, and unfortunately it will only get worse.
Sam> The problem with using ESD by default is that it has high
Sam> latency. ESD has a hard-coded lag of at least 4k samples, or
Sam> So, I made the ESD support into it’s own selectable driver, and
Sam> it currently has preference if ESD is running. The problem is,
Sam> some audio card drivers can handle multiple applications
Sam> accessing the audio device, and it simply mixes them together on
Sam> output. We want to do this whenever possible, to avoid the
Sam> latency issues with ESD.
Sam> There are two problems with this: 1. What if the user
Sam> explicitly wants to use ESD for audio over the network? 2. How
Sam> do we detect when the audio device can handle opening the device
Sam> multiple times when ESD is idle?
I think you should look for a technical contact at Red Hat (and perhaps
with other Linux distributors) and see what he recommends, both for
the current distribution of Red Hat and for future distributions.
Sam> My inclination is to have the /dev/dsp driver take preference,
Sam> but have the ESD driver selectable by the user via environment
In the long run, that’s going to lead to more tech. support calls for
anyone releasing SDL-using applications. As Linux is used by more and
more non-propeller-heads, more of them will find the check-box for
enabling ESD and check it. Some of them will install an SDL-based app
later and then be totally mystified by the apparent breakage. They
won’t remember having turned on ESD and from their point of view the
last thing they did was install the SDL-using application. Some will
figure out what went on, but others will call tech. support.
This issue might affect anyone who releases an application that opens
/dev/dsp. As such, it’s quite possible that Red Hat (and any other
distribution creator that makes it easy for people to turn ESD on in
the “shoot yourself in the foot mode by allowing someone else to grab
/dev/dsp out from under us”) already has recommendations on how to
deal with this problem. If they don’t, then now might be a good idea
to bring it to their attention so that come May we don’t find Red Hat
7.0 having the same problem, but defaulting to ESD being on.
Sam> See ya! -Sam Lantinga (slouken at devolution.com)