mdsimon2
Major Contributor
I feel like this is not well documented (at least I couldn't find a quick reference to link to!) but use (# of channels)^2 - 1. So 1023 for 10 channels and 4095 for 12 channels.
Michael
Michael
-
Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
8ch hifiberry hat dac for RPI5
- Thread starter melomane13
- Start date
mdsimon2
Major Contributor
After a bit of multichannel gadget testing I think my hypothesis that it is related to the two different 7.1 channel formats is correct.
On a Mac, by default the gadget presents as 7.1 Wide as described in the Microsoft link I posted earlier and lists channels of FL, FC, FR, LFE, BL, BR, FLC, FLR.
Playing the 7.1 test track from here -> https://www2.iis.fraunhofer.de/AAC/multichannel.html does not give any output from channels 7 and 8. However, on a Mac you have the ability to adjust the channel mapping, and sure enough in the 7.1 Rear Surround format channels 7 (LRS) and 8 (RRS) are unassigned by default. Assigning these to FLC and FRC as is done in the 7.1 Surround format gives the correct behavior with the test track.
Things seem a little trickier on Windows 11. Again, if I play the 7.1 test track I get nothing out of channels 7 and 8. I can get sound from channels 7 and 8 when I click the test button shown below but see no way of re-assigning channels like on a Mac.
After thinking about this some more I realized the channel mask is exactly what it sounds like. 0x63F = 0b110001111111 = 1599 and 0xFF = 0b11111111 = 255. I tried 0x63F (1599 also works) and it gave this on a Mac which looks about correct!
It still doesn't seem to map correctly by default unfortunately, I wonder if it is because Side Left and Side Right do not match the Left rear surround and Right rear surround nomenclature.
Unfortunately trying 0x63F with a Windows PC as a USB host gave me nothing, I couldn't even test.
Still it may be worth trying to use 0x63F as a capture channel mask and see if that works with your setup. If it doesn't I would look at see if you have any ability to re-assign channels on your USB host.
Michael
On a Mac, by default the gadget presents as 7.1 Wide as described in the Microsoft link I posted earlier and lists channels of FL, FC, FR, LFE, BL, BR, FLC, FLR.
Playing the 7.1 test track from here -> https://www2.iis.fraunhofer.de/AAC/multichannel.html does not give any output from channels 7 and 8. However, on a Mac you have the ability to adjust the channel mapping, and sure enough in the 7.1 Rear Surround format channels 7 (LRS) and 8 (RRS) are unassigned by default. Assigning these to FLC and FRC as is done in the 7.1 Surround format gives the correct behavior with the test track.
Things seem a little trickier on Windows 11. Again, if I play the 7.1 test track I get nothing out of channels 7 and 8. I can get sound from channels 7 and 8 when I click the test button shown below but see no way of re-assigning channels like on a Mac.
After thinking about this some more I realized the channel mask is exactly what it sounds like. 0x63F = 0b110001111111 = 1599 and 0xFF = 0b11111111 = 255. I tried 0x63F (1599 also works) and it gave this on a Mac which looks about correct!
It still doesn't seem to map correctly by default unfortunately, I wonder if it is because Side Left and Side Right do not match the Left rear surround and Right rear surround nomenclature.
Unfortunately trying 0x63F with a Windows PC as a USB host gave me nothing, I couldn't even test.
Still it may be worth trying to use 0x63F as a capture channel mask and see if that works with your setup. If it doesn't I would look at see if you have any ability to re-assign channels on your USB host.
Michael
Last edited:
It could be somehow related as the player uses wasapi code with channel mask support in the sample format.
I would suggest to try setting the channel bits of c_chmask according to standard 8ch configurations in Portaudio https://github.com/PortAudio/portau...rc/hostapi/wasapi/pa_win_wasapi.c#L2899-L2903 -. https://github.com/PortAudio/portau...9fd8c33/include/pa_win_waveformat.h#L103-L106 or https://github.com/PortAudio/portau...f19fd8c33/include/pa_win_waveformat.h#L96-L99
Thanks for the quick replies @mdsimon and @phofman.
It appears that you nailed the problem Michael when i tested with the mask 0x63F and inputing 8 channels it works flawlessely atleast on linux (coreelec)
Unfortunely if i play a source with less than 8 channels, the sound comes out completely distorted (that didn't happen with chmask 63 or 255)
i didn't had much time last weekend to play with this stuff and i still have to try chmask 1599, to see if i get the problem fixed!
It appears that you nailed the problem Michael when i tested with the mask 0x63F and inputing 8 channels it works flawlessely atleast on linux (coreelec)
Unfortunely if i play a source with less than 8 channels, the sound comes out completely distorted (that didn't happen with chmask 63 or 255)
i didn't had much time last weekend to play with this stuff and i still have to try chmask 1599, to see if i get the problem fixed!
The gadget reports its channels mask (configured via the c_chmask parameter) and channel count (number of set bits in the configuration chmask) via UAC2 protocol to the host.
If the USB device accepts 8 channels, the player decides what to do with the non-8 channels user wants to play. If it transforms those fewer channels to the supported 8 channels of the device incorrectly, messing up the samples, the device/gadget cannot do anything about it.
Did linux host have issues with the channel mask previously? It would be surprising, as channel configuration is only optional in linux alsa. Unlike in windows WASAPI where the client must configure a channel mask which is accepted by the driver (which is likely accepting the channel mask sent by the USB device/gadget).
mdsimon2
Major Contributor
@mdsimon2 and @phofman the error was on my side, i forgot to lock the samplerate at the clientt/linux/coreelec.
That said, with the 0x63F mask it all works flawlessely, the channels are mapped correctly!
The gadget is connected via usb to coreelec and it is receveing all channels from any kind of audio source (2.0, 5.1, 7.1);
That said, this is a crazy alternative to a home cinema receiver, whit a pretty decent SINAD.
It probably will work in android clients like nvidia shield, as long as the client have the hability to convert the audio to LPCM.
The major downside is if you really are into atmos (which i'm not). If you have ceiling speakers this is a no go for you.
At the moment i'm only downmixing to 2.0 and applying EQ filters to the speakers but with these findings i almost feel obligated to buy a pair of JBL 305p mkII for the surrounds!
Thank you very much @mdsimon2 and @phofman for the fast help!
That said, with the 0x63F mask it all works flawlessely, the channels are mapped correctly!
The gadget is connected via usb to coreelec and it is receveing all channels from any kind of audio source (2.0, 5.1, 7.1);
That said, this is a crazy alternative to a home cinema receiver, whit a pretty decent SINAD.
It probably will work in android clients like nvidia shield, as long as the client have the hability to convert the audio to LPCM.
The major downside is if you really are into atmos (which i'm not). If you have ceiling speakers this is a no go for you.
At the moment i'm only downmixing to 2.0 and applying EQ filters to the speakers but with these findings i almost feel obligated to buy a pair of JBL 305p mkII for the surrounds!
Thank you very much @mdsimon2 and @phofman for the fast help!
Last edited:
I just got an email newsletter from Hifiberry which talked about two versions of their DAC8x. A single-ended output HAT and a balanced output one. The balanced output needs a breakout cable DB25, Tascam style. But I can't see the StudioDAC8x listed on their website. Any idea? Is it WIP?
HiFiBerry Studio DAC8x | HiFiBerry
www.hifiberry.com
I wonder if anyone has tested 4 x PCM5102 modules available e.g. from Aliexpress?
IIUC they have the same PCM5102a as Hifiberry DAC8x, each has its own linear regulator. Example e.g. https://diyelectromusic.com/2024/05/27/rpi-5-quad-stereo-sound-with-pcm5102a/ + https://diyelectromusic.com/2024/06/09/minidexed-quad-dac-pcb-design/
IIUC they have the same PCM5102a as Hifiberry DAC8x, each has its own linear regulator. Example e.g. https://diyelectromusic.com/2024/05/27/rpi-5-quad-stereo-sound-with-pcm5102a/ + https://diyelectromusic.com/2024/06/09/minidexed-quad-dac-pcb-design/
To be honest, with 8ch DAC ICs available, I personally prefer to build my own single IC board. I am a bit surprised hifiberry go 4 stereo route, they must get those chips really cheap.
@MCH: I agree (e.g. that ES9080 you use is a perfect candidate I would use as well for this purpose, perhaps in a stackable configuration allowing balanced output).
On the other hand joining several dirt-cheap ready-made boards is accessible for those not willing to make their own board (and solder that 0.4mm pitch QFN), with only trivial duponts for connecting.
On the other hand joining several dirt-cheap ready-made boards is accessible for those not willing to make their own board (and solder that 0.4mm pitch QFN), with only trivial duponts for connecting.
If complete boards can be sold for 2.5USD at single quantities, the chip itself at larger quantites must be probably lower than the 1.3USD@1k+ from TI eshop.
jmf11
Active Member
I have no idea, sorry
jmf11
Active Member
Thanks MCH and phofman for the feedbacks. I wondered if they were using ES9080, but there were "too many". I was not aware of PCM5242 and TI similar DAC with integrated power stage. Interesting.
So the guess for PCM5242 was right.
Again lost opportunity for using the master clock from RPi instead of PLL from bclk.
That's because none of the chips use any control from RPi (via I2C or GPIO), and the driver is just configuration of the RPi I2S interface in master mode. The only custom part is a GPIO sensing the ADC hat which enables the capture alsa device automatically if the hat is installed. That's why a standalone ADC requires a different overlay which just tells the driver to disable the playback alsa device.
Again lost opportunity for using the master clock from RPi instead of PLL from bclk.
Similar threads
