Mcop error causing sound latency

I have an SDL game that I have been developing in Linux and Windows. In
Windows I use 4096 sound buffer size, 1024 in linux. I recently
upgraded to RH 7.3 and now I get:

mcop warning: user defined signal handler found for SIG_PIPE, overriding

evertime I run the game in Linux(gnome or kde). The first time I get it
after boot I have no latency, but after that it causes a second or two
of latency. I do not know if arts is running, but i see no artsd in ps
-aux (attached in ps.txt).

My question is how to resolve this so that there is no latency. For
example, Quake3 (does it use SDL?) has no sound latency when I play.

Much thanks in advance for any help
Bob

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: ps.txt
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020630/f1b447d8/attachment.txt

— Bob Cober wrote:

My question is how to resolve this so that there is
no latency. For
example, Quake3 (does it use SDL?) has no sound
latency when I play.

Much thanks in advance for any help
Bob

(Bob… This email is much more for Sam, Ryan, and the
core engineers than for you, but I’m sure someone will
look into your problem.)

Hmm… I Just though of something that might greatly
improve latency (if it’s doable). The program
generally knows when it needs to add a new sound to
the mix. If at this time, would it be possible for
the program to signal SDL of this, so that SDL could
EXPIRE the REMAINDER of the current buffer (minus a
few micro-seconds to allow time for the remix). That
way the sound mix callback (or possibly a new special
purpose callback) would be re-called to mix the new
sound into the sound buffer with practically zero
latency. (Sound is not my forte, so this might not be
possible, but I it seems like a perfectly reasonable
idea.)

Comments anyone?

-Loren__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

Well I think I have resolved part of my problem - surprisingly it was my own
coding error!!! (Clearly - not really a surprise ;))

Anyway, to make a long story short, first I had been manually mixing
everything and decided to use SDL_mixer instead. BTW, SDL_mixer is
outstanding - really easy to use and performs great for my purposes.
Anyway after implementing the mixer code I realized I had called SDL_Init(
SDL_INIT_VIDEO) instead of SDL_Init( SDL_INIT_VIDEO | SDL_INIT_AUDIO).
Once I corrected to the proper SDL_Init the mcop error went away.

However, I still have latency issues in KDE if the Sound Server is enabled
in the Control Panel. There is no latency if the Sound Server is shut
down. The timeout value also seems to have no effect.

So my question boils down to getting no latency while the Sound Server is
on. There is no latency in Quake 3 even when the Sound Server is running.
Is it possible to accomplish this with SDL?

Thanks again for any help - I really appreciate it
Bob

Bob Cober wrote:> I have an SDL game that I have been developing in Linux and Windows. In

Windows I use 4096 sound buffer size, 1024 in linux. I recently
upgraded to RH 7.3 and now I get:

mcop warning: user defined signal handler found for SIG_PIPE, overriding

evertime I run the game in Linux(gnome or kde). The first time I get it
after boot I have no latency, but after that it causes a second or two
of latency. I do not know if arts is running, but i see no artsd in ps
-aux (attached in ps.txt).

My question is how to resolve this so that there is no latency. For
example, Quake3 (does it use SDL?) has no sound latency when I play.

Much thanks in advance for any help
Bob

rgc wrote:

So my question boils down to getting no latency while the Sound Server is
on. There is no latency in Quake 3 even when the Sound Server is running.
Is it possible to accomplish this with SDL?

sound servers introduce latency that SDL_mixer, or any other program using the sound server cannot really overcome…

so, the best thing to do is to disable the sound server…
I use a sound card that allows multiple opens on the dsp, which eliminates any dependance on a sound server…–
-==-
Jon Atkins
http://jonatkins.org/

[…]

Hmm… I Just though of something that might greatly
improve latency (if it’s doable). The program
generally knows when it needs to add a new sound to
the mix. If at this time, would it be possible for
the program to signal SDL of this, so that SDL could
EXPIRE the REMAINDER of the current buffer (minus a
few micro-seconds to allow time for the remix). That
way the sound mix callback (or possibly a new special
purpose callback) would be re-called to mix the new
sound into the sound buffer with practically zero
latency. (Sound is not my forte, so this might not be
possible, but I it seems like a perfectly reasonable
idea.)

This is pretty much how “shared memory zero latency mixing” works, although there are more efficient ways to do it than to entirely ditch and rerender the “future” part of the buffer. (That can become very expensive…)

All you need to do is mix the new audio over the data already in the buffer.

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Sun, 30/06/2002 12:12:12 , Loren Osborn <linux_dr at yahoo.com> wrote:

This is almost mutually exclusive with the current callback semantics
of the SDL audio API. It will be considered for the next generation SDL
API, but won’t go into the current stable code.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Sun, 30/06/2002 12:12:12 , Loren Osborn <linux_dr at yahoo.com> wrote:

[…]

Hmm… I Just though of something that might greatly
improve latency (if it’s doable). The program
generally knows when it needs to add a new sound to
the mix. If at this time, would it be possible for
the program to signal SDL of this, so that SDL could
EXPIRE the REMAINDER of the current buffer (minus a
few micro-seconds to allow time for the remix). That
way the sound mix callback (or possibly a new special
purpose callback) would be re-called to mix the new
sound into the sound buffer with practically zero
latency. (Sound is not my forte, so this might not be
possible, but I it seems like a perfectly reasonable
idea.)

This is pretty much how “shared memory zero latency mixing” works, although there are more efficient ways to do it than to entirely ditch and rerender the “future” part of the buffer. (That can become very expensive…)

— Sam Lantinga wrote:> > On Sun, 30/06/2002 12:12:12 , Loren Osborn <@Loren_Osborn> wrote:

[…]

Hmm… I Just though of something that might
greatly

improve latency (if it’s doable). The program
generally knows when it needs to add a new sound
to

the mix. If at this time, would it be possible
for

the program to signal SDL of this, so that SDL
could

EXPIRE the REMAINDER of the current buffer (minus
a

few micro-seconds to allow time for the remix).
That

way the sound mix callback (or possibly a new
special

purpose callback) would be re-called to mix the
new

sound into the sound buffer with practically zero
latency. (Sound is not my forte, so this might
not be

possible, but I it seems like a perfectly
reasonable

idea.)

This is pretty much how “shared memory zero
latency mixing” works, although there are more
efficient ways to do it than to entirely ditch and
rerender the “future” part of the buffer. (That can
become very expensive…)

This is almost mutually exclusive with the current
callback semantics
of the SDL audio API. It will be considered for the
next generation SDL
API, but won’t go into the current stable code.

I’m certainly not pushing for this in the 1.2 tree,
but I see no reason for this to be mutually-exclusive
with the current callback system:

  1. This is only relevant when a new sound is added to
    the mix (so the rest of the time the callback system
    will work fine).

  2. when a new sound IS added to the mix, the
    callback has already been called, and mixed one or
    more buffers already.

  3. If there was a hook in SDL to get the currently
    queued sound buffers, and the current position in that
    buffer-queue, all the user would have to do is
    determine if there is enough time to do a remix before
    the buffer-queue empties, lock the sound mutex (so the
    sound callback doesn’t get executed while remixing),
    remix the buffer after it’s current position, then
    unlock the buffer…

I don’t see how this is mutually exclusive with the
callback. (Also, I think except for a few hooks, the
changes to SDL would be minimal… SDL_mixer OTOH
would probably want to change to accomidate this)

Like I said, I’m not pressing the issue. I’m fighting
fires in the blitter code right now, so this isn’t
something I consider “on my plate” so to speak… Just
an idea that I thought was cool…

Best regards,

-Loren


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

So my question boils down to getting no latency while the Sound Server is
on. There is no latency in Quake 3 even when the Sound Server is running.
Is it possible to accomplish this with SDL?

Quake 3 doesn’t use SDL at all, audio, video, or input.

The KDE sound server (artsd), as well as Esound, will always have latency
due to the nature of what they do; it’s fine for bells and whistles from
KDE apps (“wow, it plays a sound when I maximize the window!”), but it
will always be unacceptable for real time video games.

The solution is to bypass the server; disable it or get a sound card that
allows multiple opens of /dev/dsp (the SB Live is one, there are others,
too). Other SDL audio targets, (“dsp”, “dma”, “alsa” under Linux) have
noticably less latency.

This is just a hard fact of life; sending audio streams over a socket,
mixing them in software, and then sending them to the audio device, all
while fighting for the CPU against a video game, will always be a losing
battle.

–ryan.

The mcop errors were caused by my failing to call
SDL_Init( SDL_INIT_VIDEO | SDL_INIT_AUDIO) with the SDL_INIT_AUDIO portion.

But I was still getting a small sound latency, that seemed to occur only in
my SDL/OpenGL apps. The latency wass small, perhaps 1/2 second or less,
but noticeable. Finally, I noticed if I called SDL_Delay(10) within the
game loop then there was no latency.

I believe the SDL_Delay() call schedules cpu time to the threads that are
executing the audio, which they don’t get if the app is running full speed.
Does this sound accurate?

Thanks again for any comments or input as it is very helpful

Bob

Ryan C. Gordon wrote:>

So my question boils down to getting no latency while the Sound Server is
on. There is no latency in Quake 3 even when the Sound Server is
running. Is it possible to accomplish this with SDL?

Quake 3 doesn’t use SDL at all, audio, video, or input.

The KDE sound server (artsd), as well as Esound, will always have latency
due to the nature of what they do; it’s fine for bells and whistles from
KDE apps (“wow, it plays a sound when I maximize the window!”), but it
will always be unacceptable for real time video games.

The solution is to bypass the server; disable it or get a sound card that
allows multiple opens of /dev/dsp (the SB Live is one, there are others,
too). Other SDL audio targets, (“dsp”, “dma”, “alsa” under Linux) have
noticably less latency.

This is just a hard fact of life; sending audio streams over a socket,
mixing them in software, and then sending them to the audio device, all
while fighting for the CPU against a video game, will always be a losing
battle.

–ryan.

An SDL_Delay(1) even seems to eliminate the latency…

rgc wrote:> The mcop errors were caused by my failing to call

SDL_Init( SDL_INIT_VIDEO | SDL_INIT_AUDIO) with the SDL_INIT_AUDIO
portion.

But I was still getting a small sound latency, that seemed to occur only
in
my SDL/OpenGL apps. The latency wass small, perhaps 1/2 second or less,
but noticeable. Finally, I noticed if I called SDL_Delay(10) within the
game loop then there was no latency.

I believe the SDL_Delay() call schedules cpu time to the threads that are
executing the audio, which they don’t get if the app is running full
speed. Does this sound accurate?

Thanks again for any comments or input as it is very helpful

Bob

Ryan C. Gordon wrote:

So my question boils down to getting no latency while the Sound Server
is
on. There is no latency in Quake 3 even when the Sound Server is
running. Is it possible to accomplish this with SDL?

Quake 3 doesn’t use SDL at all, audio, video, or input.

The KDE sound server (artsd), as well as Esound, will always have latency
due to the nature of what they do; it’s fine for bells and whistles from
KDE apps (“wow, it plays a sound when I maximize the window!”), but it
will always be unacceptable for real time video games.

The solution is to bypass the server; disable it or get a sound card that
allows multiple opens of /dev/dsp (the SB Live is one, there are others,
too). Other SDL audio targets, (“dsp”, “dma”, “alsa” under Linux) have
noticably less latency.

This is just a hard fact of life; sending audio streams over a socket,
mixing them in software, and then sending them to the audio device, all
while fighting for the CPU against a video game, will always be a losing
battle.

–ryan.

[…]

game loop then there was no latency.

No latency? That I’d like to see… :wink:

I believe the SDL_Delay() call schedules cpu time to the threads that are
executing the audio, which they don’t get if the app is running full speed.
Does this sound accurate?

Well, sort of. The threads involved will get the time they need, or you get very audible drop-outs, but yes, an audio daemon setup may allow the buffering to “flex” a lot. This most probably happens in the communication between application and sound daemon, since there is a large amount of available buffer space.

There isn’t much room for this kind of “flexing” when you talk directly to the audio driver, part because of smaller total buffer size, part because buffers are read and written in rather large fragments, tying the timing of the application closer to the driver “heartbeat”.

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Tue, 02/07/2002 08:55:00 , rgc wrote:

Actually, SDL_Delay(0) (ie “yield only if other threads are runnable”) should work as well (IMHO), but will only on certain platforms. The behavior of SDL_Delay(0) is inconcistent. (On Unix, you have to do sched_yield() where Win32 allows you to "abuse"
Sleep() with an argument of 0.)

This has been discussed, but I can’t remember seeing a fix.

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Tue, 02/07/2002 09:06:37 , rgc wrote:

An SDL_Delay(1) even seems to eliminate the latency…

Ok… I know what I’m about to propose isn’t a great
idea, and (whether I like it or not) will have audio
artifacts, but does anyone know of a good way to:

  1. Preserve the state of all the chunks playing on on
    the mixer, including position (how much of the sound
    is finished playing)…

  2. Close the SDL_mixer device

  3. reopen the SDL_mixer device with a different
    sample-rate, audio-data format, and or mono/stereo
    setting

  4. resample all the previously playing chunks to this
    new format

  5. restart all the chunks playing at the apropriate
    positions

Any suggestions?

Thanks in advance,

-Loren

P.S. Ryan, this question is mainly to you…but anyone
elses comments welcome as well…__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better