Submitted on 2016-08-12 01h54 by shentino, last changed by fluzz.
Date: 2016-08-12 01h54
FDRPG is naively assuming the output device for audio has a fixed sample rate of
44100. This is a reasonable *default*, but I had my alsa dmix plugin set at
48000 or even 96000, and it caused the sound effects to be pitch-skewed and sped
up a bunch.
Suggested fix: When opening audio device, either properly detect the sample
rate and resample the audio, or select the proper sample rate. Outputting 44100
as 48000 or such will cause it to sound funky.
Date: 2016-08-12 01h56
If you guys use SDL for audio I think it allows you to let SDL do the resampling
Date: 2016-10-21 16h02
IRC log of a conversation about that bug:
[11:15:11] <fluzz> Shentino, ping
[11:15:24] <Shentino> pong
[11:15:41] <fluzz> about your issue report...
[11:15:57] <fluzz> Do you have any skill with SDL audio ?
[11:15:58] <Shentino> the one about sample rate mismatch?
[11:16:04] <fluzz> yup
[11:16:10] <Shentino> some, I wrote an FM synthesizer that used SDL as the output
[11:16:26] <Shentino> moving the mouse around changed the modulator's multiplier
[11:16:59] <Shentino> why do you ask?
[11:17:14] <fluzz> I thought that Mix_OpenAudio() would automatically detect the
actual parameters of the "sound system", and then resample if needed...
[11:18:08] <Shentino> I tried reporting it to my distro and they pooped onme
[11:18:10] <fluzz> Can you please add a Mix_QuerySpec() call after the
Mix_OpenAudio(), to check what framerate it gets ?
[11:18:18] <Shentino> I can try
[11:18:21] <fluzz> thx
[11:18:30] <Shentino> I'll need to rebuild first
[11:18:49] <fluzz> yup. use last git version, please.
[11:20:51] <fluzz> Perhaps we need to (1) OpenAudio (2) call QuerySpec() and if
actual audio format is not the one used to OpenAudio then (3) CloseAudio() and
(4) OpenAudio with the actual parameters... It would sound strange however...
[11:21:36] <fluzz> Do you know any foss application using SDL that works well
with your 48kHz set up ? I could check how that initialize SDL audio...
[11:21:56] <fluzz> s/that/they/
[11:24:09] <Shentino> well, my homebrew fm program
[11:24:12] <Shentino> :P
[11:24:33] <Shentino> basically, if you tell it to force an audio format, SDL
will do the conversion/resampling itself if it doesn't match the output device
[11:24:52] <Shentino> that is from libsdl.org's own documentation
[11:25:13] <fluzz> ah... interesting: SDL can resample but only by doubling or
halving frequency... So it does not resample from 44.1 to 48
[11:25:47] <Shentino> funny
[11:26:09] <fluzz> your synthesizer does not play sound file, does it ?
[11:26:41] <Shentino> Nope, my synthesizer generates raw samples :)
[11:26:59] <Shentino> according to this, i fyou leave Obtained as NULL, then SDL
will emulate it for you instead of giving you what it actually got
[11:27:13] <fluzz> Shentino, yep, but that's SDL 2.0. We still use 1.2, until
the port is done...
[11:27:16] <Shentino> my synthesizer uses the sampel rate to calculate how
quickly to drive the osc...
[11:27:18] <Shentino> v.v
[11:27:21] <Shentino> poop
[11:28:41] <Shentino> yes, api says it will autoconvert if you tell it to
[11:29:04] <Shentino> Just pass a NULL obtained to tell SDL to shut up and give
you what it wants even if it has to fake it in software
[11:30:44] <Shentino> if you guys manage to get a simple fix for this...I could
probably have gentoo (my distro) backport it
[11:33:45] <fluzz> arghhh... We have to use Mix_OpenAudio instead of
SDL_OpenAudio, to use mix functions...
[11:36:06] <Shentino> O_O
[11:36:11] <Shentino> what's the difference?
[11:37:23] <Shentino> I'll check the source, something strange is going on
[11:37:36] <Shentino> If you guys are using the api properly it could be a bug
[11:38:16] <fluzz> some internal initialization I guess... It is said that it
will adapt to actual audio system. So perhaps that indeed about SDL not
resampling from 44.1 to 48...
[11:39:00] <Shentino> all I know is that I had my alsa set up with a dmix node
at 48000, and when I played FDRPG it sounded like everyone was sucking helium
[11:40:25] <Shentino> but bumping the dmix rate down to 44100 fixed it. All the
other applications worked properly
[11:41:25] <fluzz> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460536 - no
44.1 to 48 resampling also reported here...
[11:41:42] <Shentino> O_O
[11:41:59] <Shentino> hmm
[11:42:05] <Shentino> sounds like a bug in SDL then
[11:42:19] <Shentino> most apps that I know of either have only one output
channel, or do their own mixing
[11:42:29] <Shentino> ...or let alsa handle it
[11:42:30] <fluzz> or a not implemented feature ;-)
[11:42:36] <Shentino> bitrot
[11:42:53] <Shentino> I'll play with it and see what happens. If I reproduce it
without FDRPG I'll refile the bug with SDL
[11:44:29] <fluzz> STK uses OpenAL... mhhh, what game suses SDL ?
[11:45:45] <fluzz> OpenArena uses OpenAL...
[11:46:45] <Shentino> Is OpenAl pretty much the audio version of OpenGL?
[11:47:17] <fluzz> mhhh... no OpenArena uses SDL...
[11:47:51] <Shentino> woudl it be a pain if FDRPG went just to SDL_OpenAudio and
did its own mixing?
[11:49:26] <fluzz> More or less... It's rather done to play spatialized sounds,
and was proposed by Creative Labs, and can use the hardware for some audio effects.
[11:50:22] <fluzz> Shentino, we are mono-threaded, so doing our own mixing is
not really an option.
[11:50:31] <Shentino> eww
[11:51:15] <Shentino> well it sounds like a bug in sdl_mixer
[11:51:25] <Shentino> I honestly haven't heard it used all that much
[11:51:39] <fluzz> But, we could add sound resampling, possibly...
[11:53:13] <fluzz> mhhh, it would mean keeping a cache of all already resampled
sounds... not that good...
[11:54:01] <fluzz> if we can affirm that SDL does not resample between 44.1k and
48k, then providing 2 sets of sounds is perhaps better...
[11:54:27] <Shentino> technically, you're working around a bug in a support library
[11:54:41] <Shentino> I have an idea
[11:54:57] <Shentino> add a config option you can poke in the start menu to
select the output rate
[11:54:59] <fluzz> sure, but that's usual ;-)
[11:55:13] <fluzz> and ?
[11:55:20] <Shentino> then the user (who probably knows the sample rate) can
punch it in
[11:55:33] <Shentino> because if sdlmixer is bugged, it might not report the
actual sample rate properly
[11:55:42] <Shentino> also, users can set their dmix to any rate they want
[11:55:52] <Shentino> 44100, 48000, 32000, 13337, etc :P
[11:56:23] <Shentino> highest sample rate I've ever known is 192000
[11:56:40] <fluzz> that's why I would like you to use QuerySpec() to know what
it reports. We first needs to have this info before to start thinking at a fix...
[11:57:15] <fluzz> Then, I'll check in SDL code what and how they resample.
[11:57:30] <fluzz> Then only, we could try to find a fix.
[11:58:18] <Shentino> I'll get around to it eventually, having things on my
[12:01:15] <Shentino> ...ewwww
[12:01:20] <Shentino> ok, not a bug
[12:01:50] <Shentino> Mix_QuerySpec deliberately says you can ask it for the
"actual" sample rate and parameters, meaning that Mix_OpenAudio is only a hint
[12:02:10] <Shentino> which means its the application's job to do its own
resampling if it doesn' tget what it wants
[12:02:17] <Shentino> unlike SDL_OpenAudio
[12:14:26] <fluzz> please.... try the QuerySpec()... :-)
[12:19:42] <Shentino> I will
[12:19:50] <Shentino> but I'm super sleepy right now. I sent myself an emaila
[12:21:05] <fluzz> thx.
[12:25:15] <Shentino> but yeah, if you find that you have to do the resamples
yourself, keeping a cache of resamples between the audio files and the mixer
would be a smart move
[12:25:30] <Shentino> and you'd only have to resample each sound once per runtime
[12:38:23] <fluzz> ah, a second test that I would you to do please, Shentino, is
to replace the Mix_OpenAudio parameters with yours (so 48k instead of 44.1k),
and see if it works.
[12:38:45] <fluzz> Please report your findings in your bug report.