Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL audio implementation (mk 2) #13

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Phlamethrower
Copy link
Contributor

This is #12 with additional changes to fix a couple of issues with the core sound code and significantly reduce the number of audio breakups.

A couple of potential future improvements:

  • Try and minimise the latency (tricky because HostFS can block for arbitrary amounts of time)
  • Fix the core code so that when sound DMA is disabled it sends silence instead of nothing

ccawley2011 and others added 2 commits July 31, 2024 20:41
The code was basically acting as if it was 16 times larger than
specified, which would typically result in an entire DMA buffer being
processed at a time instead of in (roughly) the right size chunks.

It'll still deviate from Sound_BatchSize fairly frequently (mostly due
to any remainder at the end of the current DMA buffer), but by feeding
audio to the host more regularly it should help minimise latency and
reduce the chance of starvation.
@ccawley2011
Copy link
Member

Thanks, I've had the opportunity to test this out - it works nicely on newer machines, but on older ones the sound continues to break up quite a bit. It's still an improvement over PR #12 though, so it should be OK to merge once it's ready. Sorry for taking a while to get back to you on this.

SDL/sound.c Outdated Show resolved Hide resolved
This introduces an alternate Sound_FudgeRate implementation that acts as
a direct scale factor to the time to the next DMA event, so that it
adjusts the rate correctly regardless of the batch size.

The SDL sound code has been changed to use the new Sound_FudgeRate
system, under the control of a PID controller which aims to keep an
average of 0.1s of audio buffered at a time. The PID controller results
in much better behaviour than the old control logic, and should work
well across a wide range of Arc & host audio settings and performance
levels.

The 0.1s buffer level probably isn't the best for all situations (some
machines may be able to use lower values, others may need it higher), so
in future it may be worth having it auto-adjust based on if there have
been any underflows recently. But for now it works well enough, and is
less than the old code aimed for.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants