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 2944 - directsound: underruns with 44100Hz/1024 samples, not in SDL1.2, due to timer resolution change
Summary: directsound: underruns with 44100Hz/1024 samples, not in SDL1.2, due to timer...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: HG 2.1
Hardware: x86_64 Windows 8
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.4
Depends on:
Blocks:
 
Reported: 2015-04-14 20:21 UTC by Eric Wasylishen
Modified: 2015-04-21 18:13 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Wasylishen 2015-04-14 20:21:34 UTC
Requesting a 1024 sample buffer for 44100Hz audio worked fine with SDL1.2, but I get buffer underruns with these settings in SDL2 with the directsound backend.

Steps to reproduce:
In test/loopwave.c:
+	SDL_AudioInit("directsound");
+
 	wave.spec.callback = fillerup;
+	wave.spec.samples = 1024;
+	wave.spec.freq = 44100;

Also replace sample.wav with a 44100Hz sample, otherwise you'll have sped-up audio. Expected is pop-free audio, observed behaviour is occasional pops in the audio (every few seconds). I can't reproduce it 100% of the time, but the issue usually comes back after a reboot or restarting VS.
Tested on Windows 8, on two systems, one Cirrus Logic and one Realtek audio.


Analysis:
-The cause seems to be SDL1.2 set the OS timer resolution to 1ms a startup (in SDL_StartTicks), but SDL2 no longer does this. The default 15 ms resolution in Windows 8 is too large for the directsound backend to work with 1024 samples / 44100Hz.

I realize that changing the default timer resolution is a separate topic, and defaulting to 1ms for SDL2 would increase power use. However, I think asking for a 1024 sample buffer to work with directsound is not unreasonable, that's 23ms, and it used to work in SDL1.2.

One possible solution could be calling timeBeginPeriod/timeEndPeriod in the directsound wait function, so the extra power use only applies when the directsound backend is used, and the timer res change won't be visible outside (assuming it works to change the resolution for a short block of time like that.)
Comment 1 Ryan C. Gordon 2015-04-20 16:22:09 UTC
Yeah, we should be upping the timer resolution by default and offer a hint to tell SDL not to for the unlikely cases you wouldn't want it. There's some coderot that is preventing this from working correctly though.

Fixing it now.

--ryan.
Comment 2 Ryan C. Gordon 2015-04-20 17:45:13 UTC
This is fixed in https://hg.libsdl.org/SDL/rev/7454bfce9202, thanks!

--ryan.
Comment 3 Eric Wasylishen 2015-04-21 18:13:05 UTC
Thanks! Confirmed the fix works for me.