Add WASAPI resampling so all sampling rates work #143
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Once we add the resampler, we'll always generate audio at 16 bits and use libsamplerate to convert to float32 (before optionally resampling).
Audio is generated at the sampling rate in the program settings. Wave export outputs audio at the program sampling rate. Audio playback is converted to float, resampled to the WASAPI sampling rate if it differs, then sent to speakers.
This does not have a significant effect on behavior.
This prevents calling it too early before writing enough audio.
WAV export now always writes at 16-bit, and audio playback always renders at 16-bit (due to Blip_Buffer), upmixes to float, then resamples if necessary.
https://stackoverflow.com/q/11259128 indicates that project references are the newer recommended system (and they add both build ordering, and automatic linking without hard-coding the .lib name built by libsamplerate, making the build setup cleaner).
Previously we tried to open a stream at the internal sampling rate, only falling back to the system rate if it failed. This was pointless on Windows, since opening a stream at a non-system rate always fails. On Linux Wine, you *can* open a stream at any sampling rate, but this is a bad idea since Wine delegates resampling to PulseAudio/PipeWire, and PulseAudio uses a low-quality resampler by default (https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/310).
Sizes below ~22ms are rounded up by WASAPI shared mode.
|
is this a fucking joke, it requires 4-channel audio output (and I don't even know the channel layout) In any case, this issue is unrelated to this PR. See #145. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, after the WASAPI merge, using a sampling rate different from the system rate would fail to open a WASAPI stream.
This continues to run emulators or Blip_Buffer at the sampling rate in the program settings. Then it converts all audio from blip_buffer from int16 to float32, then (if the system speaker sampling rate doesn't match the tracker rate) uses libsamplerate medium to resample audio to the system sampling rate, and outputs to WASAPI as float32.
WAV export continues to use the sampling rate in the settings, and ignores the system speaker sampling rate.
This removes the 8-bit audio output option, for both system playback (useless), and WAV export (halves file size, but degrades quality more than FLAC or Opus compression).
IDS_SOUND_BUFFER_ERRORmessage from "WASAPI error: Could not open audio stream (likely wrong sampling rate)!"Behavior
I wrote a test build at nyanpasu64@debug-channels-rates, to see whether Windows and Wine would reject incorrect sampling rates or channel counts.
Windows rejects all alternative sampling rates, and 1 channel audio. (In theory there could be 1ch speakers like 1ch microphone?)
Wine allows all sampling rates and both 1/2 channel audio. It gives PulseAudio or PipeWire the task of resampling audio (
pw-topshows Dn-FT at 44100 when the system rate is 48000). And PulseAudio is bad: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/310😂
We should unconditionally resample to the system rate ourself, to protect Wine users from low-quality PulseAudio resampling. (done)