I didn’t upload any files. I can if it’s needed.
Aahh I thought you had already done that since wesk05 asked for it.
Sorry probably misunderstood or something.
I imagined all he would do is hexdump the file like I did above, but if I’m missing something I will have to generate it again. I’ve only kept a clip with a few periods at 6kHz, not a full second.
OK, for the avoidance of doubt, here is the mono, 4kHz, 24-bit 10-sec wav generated by sox.
https://collab.osmc.tv/s/t9N9hYTQ3ZZBoaa
and here is 1 second of the captured output saved from audacity as 24-bit stereo.
https://collab.osmc.tv/s/LCpqmgYnCBMdgqA
1 Like
I asked for the clip only for checking the actual peak value. The hexdump did provide that information.
I did check this further. I can confirm that you can indeed get 24-bit output from Amlogic SoCs on both SPDIF and HDMI outputs when the output device selected is PCM, Analog. If the audio output device is HDMI, you can still get 24-bit output from audio only files and multichannel audio+ video files. Stereo audio+ video file is output as 16-bit.
The caveat here is, the word length is set as 16-bit for HDMI output and none for SPDIF output in all cases. If the sink honors the 16-bit word length, you may end up with ringing artifacts (as seen in one of my earlier screenshots). Now, this will happen only for sample values that are outside near the 16-bit quantization range. Very few audio tracks actually have the full 24-bit dynamic range. So, practically this won’t be much of an issue.
I do have to add that this is the case with LE builds on Amlogic devices. Amlogic devices running Android OS are still limited to 16-bit output for both SPDIF and HDMI (I only checked Minix U9-H and Xiaomi Mi Box 3).
This was fun!
3 Likes
Thanks for your confirmation. At the moment, the 16-bit restriction applies only to the ‘HDMI’ ALSA device. I’ve tried removing that restriction (it’s only in the ALSA conf file) but I have to fiddle with the audio buffers to make it work. The ‘PCM’ device you see in Kodi accepts 32 bits and feeds 24 of those to the S/PDIF and HDMI physical devices. With your help, we are now signalling that bit-depth to HDMI properly. There does not seem to be a (documented) way of signalling that to S/PDIF.
I can’t say why LE on Android can’t manage the trick.
As you know, Kodi converts everything to 32-bit float then sends the ‘best’ format that the sink will support. If the volume is not 100% it will therefore use the bottom 8 bits of 24 if the sink supports 24 bits. I can’t immediately see how ‘ringing’ could be introduced but could look into that if you can shed more light on it.
Thank you for confirming and providing information and your insight from my side as well 
I hope that, with proper signalling coming for HDMI, this should be satisfyingly solved for everyone: proper bit-perfect 24bit output from our Vero 
And great work, @grahamh!
Thanks for the clarification guys!
Don’t really know what the ringing artifacts mean though, but by the sound of it it looks like small issue.
Ringing might only appear when using the HDMI device for PCM which we will stop from happening soon. The PCM device always outputs 24bit correctly and signalling via HDMI (the physical output, not the ALSA device 
) will be fully functional soon as well
To my understanding, this issue is solved completely and to everyone’s satisfaction
1 Like
The first edition of IEC 60958 (1999) didn’t have the word length defined. Bits 32-35 of the channel status block were reserved. It was set to 0000 as default. In the later editions, this meant word length not indicated. It looks like Amlogic IEC 60958 part of the code is from the 1999 era (as indicated by the original “958” designation).
I am not sure what you mean by “LE on Android can’t manage the trick”. The output is 24-bit on LE builds also. It is 16-bit on Android because there is only one output device “Android Audiotrack”. You can set the output as PCM, HDMI, SPDIF etc in the Amlogic Android setttings, but that doesn’t seem to change the output on Minix U9-H or Mi Box 3.
As for ringing, take a look at what you call as “dithering” with the 16-bit -90.3dBFS signal that you generated. This is actually the ringing artifact (Gibbs phenomenon) introduced due to bandwidth limitation. This is what you can expect when 24-bit signal is truncated to 16-bit without proper dithering. I do have to say that this is all academic because in reality there aren’t many audio tracks with this high dynamic range. This website lists the dynamic range of released tracks- http://dr.loudness-war.info/
BTW: I will be getting a Maplin 7.1 USB sound card next week 
You don’t expect me to let that go, do you? 
Apparently sox applies dither by default Re: [SoX-users] Sox -b 16 vs dither | SoX - Sound eXchange So just to check I ran sox with -D for no dither:
sox -c2 -r 192k -b16 -D -n 4k-90.3dBtri192kc2b16nodither.wav synth 10 tri 4000 gain -90.34
The result is the bottom trace in this. The top trace is the original dithered 16-bit file which was perfectly reproduced through the HDMI port as shown above.
Someone must have bought up the bankrupt stock. It’s a nice device - probably the same as the similar one badged by Diamond outside the UK. I doubt it’s as good sonically as > $100 devices like the Dragonfly because I reckon I can tell the difference between a 96kHz and a 48kHz recording made from an analogue source with <16kHz content (cassette tape!). That really shouldn’t happen.
sox dithering algorithm is then pretty bad and without dithering, it is clipping.
Save the 24-bit -90.3dBFS waveform as 16-bit without dithering (truncation) and the resulting waveform will look like what can be expected in an AVR when processing 24-bit signal with truncation. Generate another 24-bit waveform at -50dBFS or so and then save that also 16-bit. You should be able to notice the difference between the two waveforms.
In the July update, HDMI channel status is set to 24-bit only for multichannel LPCM. For stereo it is still set to 16-bit.
Thanks for that. I’m stumped. I’ve checked the register which signals the bit depth (CSB32-35) and it is set to 0xb (24-bit) for all PCM streams - stereo/7.1 with audio output PCM 2.0 or 7.1 or audio output HDMI 2.0 or 7.1. Only when streaming NLPCM is it set to 0x2 (16-bit).
And it does correctly re-set to 0xb after playing NLPCM.
Well… that’s how it’s being reported by the HDMI analyzer. May be there is another location some where else in the code.
Just curious about 24 bit in stereo after the last april update, was any further investigation or even improvments done in that point ?
Actually all my stereo music sounds really good through Vero 4K, but maybe one day will be even better
24-bit stereo plays as 24-bit as I show above but we’ve been unable to make HDMI signal it as such. It’s in the design of the chip.
I doubt whether any AVRs or other audio sinks actually round the bottom 8 bits, but if anyone can show one that does, I would be interested.
Based on my testing, HDMI audio input is unlikely to be processed as 24-bit without proper AVI InfoFrame. With S/PDIF input, it is processed as 24-bit.
HDMI input was tested on Oppo UDP-205 UHD Blu ray player and Denon X2600H AVR. S/PDIF input was tested on Oppo UDP-205, Gustard X-26 DAC, Topping D70 DAC. Balanced output (except the X2600) was analyzed on a Audio Precision analyzer and also on a RME ADI-2 Pro Fs using HpW & Virtins software. With HDMI input, the output never showed greater than 16-bit dynamic range suggesting that the devices (UDP-205 & X2600H) processed the input signal as 16-bit. Greater than 16-bit dynamic range output was detected with S/PDIF input on UDP-205, X-26, D70.
I do have to say that the test results may be specific to the devices that I tested. The results could be different on other devices.
Useful, thanks. Was this with stereo or multi-channel?