[SDL] sdl audio jittering

Florian Hufsky fhufsky at phorus.at
Sun Nov 13 14:07:25 PST 2005


Sorry for taking so long to answer, but I'm currently quite busy.

>>Ok, my question is if you could help me get rid of that jittering at 
>>higher CPU loads. I guess someone with a more decent knowledge of
>>SDL audio internals might instantly know the answer.
>>    
>>
>
>What do you mean by jittering, more specifically? Are you getting 
>audio drop-outs, or is it a matter of varying event->audio output 
>latency?
>  
>
I can't tell you for sure, but I guess small audio drop-outs best 
describes it.
It sounds like the buffer is written only 7/8 but already played. Could 
be something different though.

Haven't tried event->audio yet. For now I'm just playing a single mp3.

>>How the thing works:
>>
>>I have a
>>
>>freq        = 44100;
>>channels    = 2;            //stereo
>>format        = AUDIO_S16;
>>samples        = 2048;   
>>SDL_AudioSpec (verified after initalizin, and it's the same format
>>that audiere gives us)
>>
>>In the audio callback I do the following:
>>1. let audiere mix the next streamlen bytes of audio data
>>2. put it in the sdl audio stream
>>    
>>
>
>Are you sure Audiere actually mixes the exact number of bytes you ask 
>for? If not, it may not actually render the same amount of data each 
>time you call it, which means you'll start missing deadlines long 
>before you're at 100% CPU load.
>  
>
I pass audiere the number of chunks to mix and assume it mixes that amount.

>>That's exactly the same thing audiere does in the windows backend.
>>    
>>
>
>Same buffer size too?
>  
>
Ah. I'll take a look at that.

>A general purpose OS usually has hideous scheduling jitter, even for 
>so called "real time priority", which severely restricts the latency 
>(buffer size) and CPU power available for real time DSP. Say you can 
>use 50% of the CPU time without problems with a certain buffer size. 
>Cut the buffer size in half, and you could end up getting drop-outs 
>even if you use virtually no CPU time att all. It does not scale 
>towards zero latency. It scales towards the buffer size that 
>corresponds to the worst case scheduling latency.
>  
>
Nice to know, thanks.

>>I guess the jittering is because of audiere taking too much time to
>>mix data (for sdl). However I'm worried because with the windows
>>backend everything works fine.
>>    
>>
>
>I can't swear that SDL isn't doing something funny, because I've been 
>having trouble with Audiality over the SDL audio backend all the 
>time, and never been able to figure out what's going on...
>
>However, this is on Windows only! On Linux, I get excellent 
>performance whether I use SDL audio or OSS. Even on old Linux kernels 
>that have worse real time performance than Windows, Audiality peforms 
>much better than on Windows.
>  
>
sdl_mixer works just fine so i guess it's not a SDL specific problem. 
Maybe SDL + an audio callback which takes too long to update the buffer.

>>But maybe the windows backend is written a way so that the audio 
>>callback can run multiple times at once.
>>    
>>
>
>Not sure what you mean... What would that accomplish?
>  
>
Hm.... right. .... Wait.... I think the Windows backend writes data to 
the audio buffer all the time unless it's filled. I guess that's quite a 
difference to SDL's on-demand filling.
.......
I have to check that.


>>Do you have any idea what could be the problem? Or what causes audio 
>>jittering under SDL in general.
>>    
>>
>
>Well, from what I've seen, SDL audio works great on Linux, whereas on 
>Windows, there are serious latency problems - by musical synthesis 
>standards, at least. (I'd say anything above 10 ms is unacceptable 
>for interactive real time synhesis, but you don't need to get 
>anywhere near those figures in games. In fact, if you do, you'll need 
>to delay the sound effects so they aren't played before the user can 
>see the visual events!)
>
>I don't know if the latency problems are caused by Windows, SDL or the 
>combination, but I suspect that it's mostly a Windows issue. To get 
>anywhere near the "standard" Linux, BeOS and Mac OS latencies on 
>Windows, you need to use ASIO, EASI or similar "bypass" audio API 
>instead of DirectSound. (KernelStreams might work, but only if you 
>disable the internal software mixer.)
>
>
>One thing you might try is to log and analyze timestamps from various 
>places, such as when you enter and leave the SDL audio callback. (Use 
>x86 asm RDTSC, Win32 performance counters or something. You *might* 
>get away with ms accuracy when looking for critical latency peaks, 
>but you'll get more interesting data with µs accuracy or better.)
>

Ok. I'm going to check the timing and if audiere really gives me the 
right amount of samples.

Thanks for your help so far.




More information about the SDL mailing list