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

4-bit and 8-bit audio not implemented #167

Open
clbr opened this issue Oct 24, 2020 · 6 comments
Open

4-bit and 8-bit audio not implemented #167

clbr opened this issue Oct 24, 2020 · 6 comments

Comments

@clbr
Copy link
Contributor

clbr commented Oct 24, 2020

4-bit and 8-bit audio are not implemented, only 16-bit is.

@clbr
Copy link
Contributor Author

clbr commented Oct 24, 2020

Actually, the hw may be capable of arbitrary bitrates. Needs to be verified.

@hcs64
Copy link
Member

hcs64 commented Nov 1, 2020

Are these actually implemented on HW? Could you provide an N64 program that uses non-16-bit?

@clbr
Copy link
Contributor Author

clbr commented Nov 1, 2020

Krom has many 8-bit samples at
https://github.com/PeterLemon/N64/tree/master/Sound/PCM/

@clbr
Copy link
Contributor Author

clbr commented Nov 2, 2020

Krom's 8-bit and mono examples kept me up for a while, how could they work by halving/quartering the rate like that? I had to look at the crystal ball, which just confused me for several hours. Eventually things clicked.

The hw is always s16 16-bit stereo. Always. Rate hacks like that use less source data by worsening the audio quality in several ways. For example, s16 mono at half rate results in one channel played at half the rate - losing high frequencies - while the other channel plays out of sync. s8 stereo at half rate results in garbage in the lower bits of one channel, played at half rate, while the other channel is out of sync plus low bits garbage.

All the existing homebrew AI register docs are wrong. The bit rate register has an inverse relationship, and the 2-16 (-1) range is just a convenient ruse. It is not "bit rate", it is "clocks per bit". Setting it too high means one channel is starved of resolution, while too low has no indirect adverse effects, just gets the resolution requested.

This means the hw is only capable of 9-bit logical resolution at 44.1kHz; more at lower frequencies. If you set freq 44100 and bitrate 16 (-1), that would result in one channel having 16 bits of resolution and the other having 2 bits.

Wrt cen64, emulating this would mean worse audio quality but more accuracy. As such it may not be high priority, but should be eventually implemented. After all, accurate emulators for other platforms faithfully emulate bad sides of their audio systems, clicks, pops, aliasing, harmonic overwaves etc. The title could be edited to "Audio bit emulation inaccurate", but github is bork for me.

@clbr
Copy link
Contributor Author

clbr commented Nov 2, 2020

Sorry, mistakes in math above: hw is capable of 16-bit at 44100, and the bitrate 16-1 example has a wrong value. However too high/too low conclusions are correct, if possibly inverted.

@hcs64
Copy link
Member

hcs64 commented Nov 2, 2020

Yeah in my experience I was never able to get anything but 16-bit stereo working as expected on hw.

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

No branches or pull requests

2 participants