b-em
b-em copied to clipboard
stardot
sn76489 audio output sounds slightly grainy
This is a follow on from #11 (which we decided to make specific to Music 5000) and have since resolved.
These comments apply to official B-Em 2.2 release, as well as the current build. The problem seems to be present on Linux and Windows.
In very general terms, the sn74689 audio sounds slightly grainy. I really noticed this when I hooked up a decent amp and speakers, so that I could compare the B-Em sn76489 emulation with an FPGA hardware implementation (that uses a decent SPI DAC).
The difference was significant. My testy case was simply the ^G beep.
I think there are a few going on:
- the audio output of most PCs is pretty noisy
- the output level of B-Em is quite low compared to other applications
- the default re-sampling is probably just using linear interpolation
- on Windows the default openal32.dll is routing directly to DirectSounds3D - it may be better to replace this with OpenAL Soft, then we can control global levels and resampling via alsoft.ini file in %AppData%
- there is some noticeable modulation on the ^G beep
As a comparison, I tried the Beech emulator on Windows, and this sounded very clean in comparison.
Looking at the ^G waveform on a scope:
you can see there is one sample's worth of jitter.
I'm not sure if this is the problem, or if it's even avoidable. The real sn76489 runs at 4MHz/16 = 250KHz, which is 8x the audio sampling clock. So clearly some frequencies will jitter.
Oh, and the sn76489 code is much more complicated that I would expect: https://github.com/stardot/b-em/blob/master/src/sn76489.c I don't understand what sidcount is doing here!
I need to do some more investigation, but I would be interested in feedback from other people. Most people I suspect would not notice, unless the issue is pointed out to them.
Returning to an old thread is this with the Internal filter on or off?
I have just been looking at the sound code and it seems it is feeding integer data into an IIR filter that expects floats by simply converting the data type and not the range, i.e. normally data in float format would vary fron -1 to +1 not from +32767 to -32768. I don't know enough to know if the IIR algorithm depends on the range of its input values but maybe worth considering.
Recording the output from B-Em with audacity gives this:
This is on Linux and is recording the "monitor" output from pulse audio. It was certainly quiet - I had to normalise it to be able to see the waveform.