We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 79 - ALSA latency fixes...
Summary: ALSA latency fixes...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: HG 1.2
Hardware: All Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-24 05:01 UTC by Ryan C. Gordon
Modified: 2006-03-19 05:42 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan C. Gordon 2006-01-24 05:01:03 UTC
Forwarded message: -------------------
Date: Thu, 28 Aug 2003 07:43:57 +0300
From: "Mike Gorchak"  mike malva ua
Subject: Re: [SDL] SDL Audio Latency Update

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 malva ua
Comment 1 Ryan C. Gordon 2006-01-27 11:23:23 UTC
Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

Comment 2 Sam Lantinga 2006-03-19 05:42:41 UTC
I implemented this in CVS.  It didn't actually change the latency for me, possibly because there was another application that already had the audio open, but it's the right thing to do.