Ok, I’ve been digging around and trying a few things out…
(and pulling some hair out too 
Right now, it seems (at least here at my office computer) that the cause
of my Latency problems is caused by using KDE/aRts.
I’m getting a message whenever I start an SDL_mixer-based program under
KDE that says: mcop warning: User defined signal handler for
SIG_PIPE,overriding. (I assume this caused by blocking SIGPIPE signals
in the SDL_thread stuff?)
It took me a while to realize that the warning was coming from artsd ,
which apparently uses mcop. So I started up X windows with Gnome and
poof …the latency disappears. (At least it is reduced well enough
that I dont notice it )
Reading through arts’ documentation online I found a section on audio
latency http://www.arts-project.org/doc/mcop-doc/latency.html
According to this,the latency you get between the time the server starts
playing and the soundcard gets something is (number of fragments)*(size
of each fragment)/(samplingrate * (size of each sample)).
So, back in KDE I tried Opening the Mixer with a samplerate of
44100,instead of 22050, which according to the eqn. above should produce
a smaller latency. The delay did not disappear, but it was reduced
somewhat (Down to about ~0.72 seconds from ~1.35 seconds). I’ll keep
playing with the values, but so far I havent been able to reduce it much
more.
Has anyone using ESD (or anything besides artsd) experienced this audio
latency problem, or is it strictly limited to KDE/aRts? Perhaps the
problem is within aRts? Or maybe in SDL’s interaction with aRts?
I hope this helps.–
.The Government just announced today the creation of the Neutron Bomb II.
Similar to the Neutron Bomb, the Neutron Bomb II not only kills people
and leaves buildings standing, but also does a little light housekeeping.
Jason Remley
@Jason_Remley
I have the same problem in GNOME and Windows 
I’m sending Sam a test
case.
Lic. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy> ----- Original Message -----
From: Jason Remley [mailto:jareml00@earthlink.net]
Sent: Martes, 19 de Agosto de 2003 07:41 p.m.
To: sdl at libsdl.org
Subject: [SDL] SDL Audio Latency Update
Ok, I’ve been digging around and trying a few things out… (and pulling
some hair out too
Right now, it seems (at least here at my office computer) that the cause
of my Latency problems is caused by using KDE/aRts.
I’m getting a message whenever I start an SDL_mixer-based program under
KDE that says: mcop warning: User defined signal handler for
SIG_PIPE,overriding. (I assume this caused by blocking SIGPIPE signals
in the SDL_thread stuff?)
It took me a while to realize that the warning was coming from artsd ,
which apparently uses mcop. So I started up X windows with Gnome and
poof …the latency disappears. (At least it is reduced well enough
that I dont notice it )
Reading through arts’ documentation online I found a section on audio
latency http://www.arts-project.org/doc/mcop-doc/latency.html
According to this,the latency you get between the time the server starts
playing and the soundcard gets something is (number of fragments)*(size
of each fragment)/(samplingrate * (size of each sample)). So, back in
KDE I tried Opening the Mixer with a samplerate of 44100,instead of
22050, which according to the eqn. above should produce a smaller
latency. The delay did not disappear, but it was reduced somewhat (Down
to about ~0.72 seconds from ~1.35 seconds). I’ll keep playing with the
values, but so far I havent been able to reduce it much more.
Has anyone using ESD (or anything besides artsd) experienced this audio
latency problem, or is it strictly limited to KDE/aRts? Perhaps the
problem is within aRts? Or maybe in SDL’s interaction with aRts?
I hope this helps.
–
.The Government just announced today the creation of the Neutron Bomb
II. Similar to the Neutron Bomb, the Neutron Bomb II not only kills
people and leaves buildings standing, but also does a little light
housekeeping.
Jason Remley
jareml00 at earthlink.net
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
I have the same problem in GNOME and Windows I’m sending Sam a test
case.
Here was my reply:
The reason you have so much latency is the sample buffer size of 16384.
At 22050 Hz, the default mixer frequency, this works out to be:
16384/22050 = 0.74s of latency.
Since SDL audio drivers usually double-buffer the sound, it works out
to approximately 1.5 seconds of latency.
For interactive applications, I typically use a sample buffer size of
1024 at 22050 Hz:
1024/22050 = 0.46s of latency … much better. 
If I do that in your app, it becomes much more responsive.
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:
I have the same problem in GNOME and Windows I’m sending Sam a test
case.
Here was my reply:
The reason you have so much latency is the sample buffer size of 16384.
At 22050 Hz, the default mixer frequency, this works out to be:
16384/22050 = 0.74s of latency.
Since SDL audio drivers usually double-buffer the sound, it works out
to approximately 1.5 seconds of latency.
For interactive applications, I typically use a sample buffer size of
1024 at 22050 Hz:
1024/22050 = 0.46s of latency … much better.
If I do that in your app, it becomes much more responsive.
I find 3072 at 44 is the smallest buffer size I can use on windows
without the sound hissing.
Anyone else find that?
Continued…
For interactive applications, I typically use a sample buffer size of
1024 at 22050 Hz:
1024/22050 = 0.46s of latency … much better.
It’s actually 0.046s, which is much better :))
Oh, right, that’s what I meant.
If I do that in your app, it becomes much more responsive.
May I ask why? I originally tried with 4096, but I thought increasing
this number would yield better results. I thought bigger buffer => less
"refills" => less overhead => less latency. What am I missing here? Is
this buffer locked or something and the mixer can’t pump new data until
it’s used? It’s already transfered to the soundcard?
bigger buffer => less “refills” => less overhead => more latency.
Think of the audio stream as a fifo queue. You push samples in, and
then put more samples in, and they are drained out at your audio rate.
The more samples you have queued up, the longer it takes for new samples
to be heard.
See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Hello, Sam!
SL> Here was my reply:
SL> The reason you have so much latency is the sample buffer size of 16384.
SL> At 22050 Hz, the default mixer frequency, this works out to be:
SL> 16384/22050 = 0.74s of latency.
SL> Since SDL audio drivers usually double-buffer the sound, it works out
SL> to approximately 1.5 seconds of latency.
SL> For interactive applications, I typically use a sample buffer size of
SL> 1024 at 22050 Hz:
SL> 1024/22050 = 0.46s of latency … much better.
SL> If I do that in your app, it becomes much more responsive.
This changes can cause clickering sound due to lack of CPU time to update
sound buffers, because in SDL audio stream played in another thread. For
example ALSA 0.5/0.9 have the configurable policy of sound buffer usage:
SND_PCM_START_DATA and SND_PCM_START_FULL. First define used to direct to
sound engine to start play when first part of data arrived to sound buffers,
second define used to start play after all buffers have been filled.
ALSA 0.9 have the slightly different defines: SND_PCM_START_DATA and
SND_PCM_START_EXPLICIT=SND_PCM_START_LAST, defined in enum snd_pcm_start_t.
But looks like this functionality (function
snd_pcm_sw_params_set_start_mode() ) somehow deprecated, but it works.
Ah, just found that for ALSA 0.9 must be used
snd_pcm_sw_params_set_start_threshold function instead of
snd_pcm_sw_params_set_start_mode to configure sound buffer usage algorithms.
But SDL driver doesn’t uses this ability of ALSA. So it would be nice, if
ALSA driver maintainer add this ability. So we’ll have large buffers to
avoid underrun condition, and lowest latency
P.S. QSA/QNX driver (which is really have the ALSA 0.5 interface) uses this
functionality.
With best regards, Mike Gorchak. E-mail: mike at malva.ua