| Summary: | ALSA buffer size cannot be set with SDL_OpenAudio | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Jason Rohrer <jasonrohrer> |
| Component: | audio | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED ENDOFLIFE | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | jspradlin, kevin |
| Version: | HG 1.2 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Attachments: |
My extra debug output, an HG diff
ALSA's aplay can set variable buffer sizes even when period size is fixed |
||
Created attachment 546 [details]
ALSA's aplay can set variable buffer sizes even when period size is fixed
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! 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... 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 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. |
Created attachment 545 [details] 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