-
Notifications
You must be signed in to change notification settings - Fork 449
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
AudioGeneratorMOD - scratches/noise due to integer overflow #474
Comments
There was a bug in older versions of the MOD lib where I was off-by-one in shifting the audio output from fixed point to integer, causing overflow that way and bad sounding mods, but I haven't noticed any other problems with it, so good ears on you!
That would be great, especially since you not only found the problem but have a fix! |
update - after spending a few hours of debugging:
I'll create a pull request tomorrow or monday to fix (or work around) some of the problems - actually i need some time to clear out all my extra debugging code. |
PS: below some MODs for reproducing problems:
And some stranger things for the guru
|
Hey, good work digging into this. I would not be so harsh on Stellaplayer...he wrote it for a tiny microcontroller with way less RAM and MIPS than we have, and it works pretty well in many cases. And I'm sure that I busted some things as I ported to the ESP systems! Anyway, if you have a Linux machine, or WSL on Windows, it is easy to build and test changes to the MOD player. Look at the |
- do channel mixing in 32bit, to avoid noise from over/underflow - write audio output as "signed int" (not unsigned) - add int16 saturation check ("clipping")
Thanks for the tests/host tip, that's a lot better 👍 You are right about stellarplayer - the code is a bit "fragile", however it turned out that it works basically. Maybe I just experienced a high WTF/min (https://www.osnews.com/story/19266/wtfsm/) when trying to understand it ;-) |
* Fix a tricky bug that causes delays in playback ... this bug was already present in stellaplayer. Obviously "effectNumber" must be checked, because "effectParameterX" just holds the "upper nibble" of effectParameter * fix for issue #474 - do channel mixing in 32bit, to avoid noise from over/underflow - write audio output as "signed int" (not unsigned) - add int16 saturation check ("clipping") * avoid crash when MOD file has to many CHANNELS - avoid guru meditation, by logging an error and refusing playback in case MOD.numberOfChannels > CHANNELS - correct small typo * internal DAC: avoid possible overflow in conversion int16 -> uint16 * update constants .. we can do 16bit and 8 channels, so let's do it ;-) This adds some debugging code to better understand what is going on inside the mixer code (AudioGeneratorMOD::GetSample). And it also prints out some usefull information from the MOD file. Only active when do_MIXER_DEBUG is defined. * MOD generator: 12 bits of "real" resolution (instead of 10) With this change, we gain 2 additional bits of "real resolution" from the sample interpolation step. Still need some testing to be sure that nothing get "lost" at the same time. * limit to 4 channels on ESP8266 As discussed in #479 (comment)
Hi,
Thanks for creating this audio library, which even allowed me to dig out some "amiga MODs" and play them on a micro-controller :-)
Actually I have noticed some "over-saturation" noise in the MOD generator, especially when several channels are playing at high volume. It seems to me that the following code is having a 15-bit overflow:
ESP8266Audio/src/AudioGeneratorMOD.cpp
Lines 738 to 739 in fe7a1f7
ESP8266Audio/src/AudioGeneratorMOD.cpp
Line 744 in fe7a1f7
ESP8266Audio/src/AudioGeneratorMOD.cpp
Lines 806 to 815 in fe7a1f7
Probably the overflow is caused by the "16-bit up-scaling" that was not present in the original stellarplayer.
Changing
sumL
,sumR
andout
toint32_t
fixes the problem.Maybe I can make a PR over the weekend.
Cheers, Frank.
The text was updated successfully, but these errors were encountered: