This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• My extra debug output, an HG diff (change_4911_4912.diff, text/plain, 2010-11-22 22:11:58 +0000, 7652 bytes)
• ALSA's aplay can set variable buffer sizes even when period size is fixed (aplay.c, text/x-csrc, 2010-11-22 22:13:43 +0000, 57785 bytes)

Reported in version: HG 1.2
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2010-11-22 22:11:58 +0000, Jason Rohrer wrote:

Created attachment 545
My extra debug output, an HG diff

Similar behavior for 1.2.11 up through latest code checked into HG.

When using ALSA driver, some cards (like mine) apparently cause ALSA to be very inflexible about "period" length. SDL assumes double-buffering (buffer = period * 2), which means that it ignores my requested buffer size.

Below is some debug output (that I added to latest HG code) when I am trying to open an 11025 Hz, 16-bit, stereo stream with a requested buffer size (spec->samples) of 8192. Note that an "obtained->samples" value of 235 is returned to me from my SDL_OpenAudio call. The same value is returned no matter what buffer size I request, giving me no control over latency or drop-out safety.

ALSA: buffer min/max = 470/3763, period min/max = 235/236
ALSA: requested buffer size = 8192
ALSA: period size = 235, periods = 2, buffer size = 705

A total buffer size of 705, when a buffer of 3763 would actually be possible.

This may seem like an ALSA problem or a problem with my card, but the "aplay" program that ships with alsa-utils can correctly set various buffer sizes (or the closest possible size) without issue, even though the period size cannot be changed (adding debug output to aplay shows the same fixed period min/max). In those cases, I think it's necessary to simply have more than 2 periods (more than double-buffer).

I've attached my patch to SDL to produce the extended debug output shown above. Also attached aplay source code as an example of correct ALSA usage.

I'm afraid that I don't quite understand the latest SDL code well enough to fix this behavior myself. If someone decides to take this on and needs someone to test a fix, I have HG working here. Please email me:

jasonrohrer AT fastmail DOT fm

On 2010-11-22 22:13:43 +0000, Jason Rohrer wrote:

Created attachment 546
ALSA's aplay can set variable buffer sizes even when period size is fixed

On 2011-04-12 20:08:31 +0000, Jen Spradlin wrote:

Thank you for your bug report!

We're busy working on getting SDL 1.3 ready for a high quality release, and want to make sure as many things are fixed there as possible.
Could you check to see if your bug is resolved by the latest SDL 1.3 snapshot?
http://www.libsdl.org/tmp/SDL-1.3.zip

Thanks!

On 2011-04-13 12:48:25 +0000, Jason Rohrer wrote:

Sorry, I've never used 1.3, and I don't have any code that compiles against it.

This was a report about 1.2...

On 2012-01-17 19:36:57 +0000, Kevin Locke wrote:

This may be due to the fact that the Alsa Dmix plugin, which is used by default on soundcards which don't support hardware mixing (most cards), has a fixed period size. I recently confirmed this fact on the alsa-user mailing list.[1]

Although this is the underlying cause of this problem on my system, it may not be the only cause (although I suspect it is likely). The original submitter may want to post the aplay output to confirm that the period size can be manipulated (Note that aplay outputs the information for the hardware, slave, and any plug PCMs in use, which may differ and may or may not be relevant). It is also worth trying with the AUDIODEV environment variable set to "hw:0,0" (or another hardware device) to test if the buffer can be adjusted when using the hardware device directly.

The problem is present in SDL 1.3 (as best I can tell from looking at the code, I have not run tests against it). It would be nice to support variable buffer sizes on such hardware by allowing a variable number of periods instead of the fixed 2 currently used, but I do now know enough about the SDL audio internals to know how feasible this is.

1. http://article.gmane.org/gmane.linux.alsa.user/36003

On 2015-08-25 09:38:22 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.