Multichannel audio on a Pi will get a whole lot easier and cheaper!

[mdsimon2]

I have to admit the multichannel I2S input is pretty cool and was much more plug and plug than I ever expected, although that is largely due to folks way more knowledgeable than me.

I did some more testing today and really think an Apple TV + HDMI to I2S Extractor + RPi5 + CamillaDSP + multichannel USB DAC (preferably with some ability to clock to an external SPDIF clock) is a really nice AVR alternative.

Today I reduced chunk size to 256 at 48 kHz with no rate adjust or resampling. I played a movie for two hours and buffer level stayed at 340 +/- 5, there were no buffer under runs and no lip sync issues.

CamillaDSP will go in to STALLED state if the Apple TV is powered off, but it comes right back when the Apple TV is powered on. I plan on seeing how it does powered off overnight but so far it is really well behaved. There are no nasty pops or noises when powering the RPi on / off either. Although part of this may be due to how well behaved the MOTU Ultralite Mk5 is when it loses clock lock.

Michael

 

[phofman]

Today I reduced chunk size to 256 at 48 kHz with no rate adjust or resampling. I played a movie for two hours and buffer level stayed at 340 +/- 5, there were no buffer under runs and no lip sync issues.

Is that because your playback DAC is clocked by the HDMI extractor via SPDIF?

 

[mdsimon2]

Yes, exactly, the extractor outputs SPDIF in addition to I2S and I have the MOTU clock set to SPDIF.

The Apple TV also powered up nicely after a night shut down and CamillaDSP came right out of STALLED state.

Michael

 

[mdsimon2]

A few measurements of the HDMI to I2S Extractor -> RPi 5 running CamillaDSP -> MOTU Ultralite Mk 5. MOTU is clock sync'd to extractor via SPDIF, all running at 48 kHz.

Here is digital output from the MOTU to UR23 TOSLINK to USB card.

And here is the analog output of the MOTU Ultralite Mk5. Blue trace is baseline using USB input to the MOTU, green trace is through the HDMI to I2S Extractor -> RPi 5 + CamillaDSP -> MOTU Ultralite Mk5 path. Volume is set to -6 dB on the MOTU to give approximately 4 V output. Measurements are made with Cosmos ADC in stereo mode at 6.7 V input sensitivity setting.

First I'll show 1 kHz at 0 dBFS through the extractor with the REW distortion overlay panel to give some quantification. As you'll see later the USB input and path the extractor + RPi 5 are identical.

Michael

 

[MCH]

Yes, exactly, the extractor outputs SPDIF in addition to I2S and I have the MOTU clock set to SPDIF.

the good part is that all the HDMI extractors i have ever seen have a spdif output.

I did some more testing today and really think an Apple TV + HDMI to I2S Extractor + RPi5 + CamillaDSP + multichannel USB DAC (preferably with some ability to clock to an external SPDIF clock) is a really nice AVR alternative.

Today I reduced chunk size to 256 at 48 kHz with no rate adjust or resampling. I played a movie for two hours and buffer level stayed at 340 +/- 5, there were no buffer under runs and no lip sync issues.

I have a question for you, just out of curiosity and hopefully not very stupid:
If i was going to do a setup similar to yours but instead of the motu, using a i2s DAC, like this:
HDMI extractor -> i2s -> rpi5/camilladsp -> i2s -> DAC
Do you think it would be possible to take the master clock from the extractor and connect it directly to the DAC and have it working in slave mode to have both in synchronous mode?

and thanks for the measurements!

Another question for all, that i am sure it has been discussed somewhere but i don't remember. Can the rp5 do TDM?

 

[mdsimon2]

If i was going to do a setup similar to yours but instead of the motu, using a i2s DAC, like this:
HDMI extractor -> i2s -> rpi5/camilladsp -> i2s -> DAC
Do you think it would be possible to take the master clock from the extractor and connect it directly to the DAC and have it working in slave mode to have both in synchronous mode?

I believe that would work with the RPi in I2S slave mode. The extractor would provide MCLK (if needed), LRCLK (split to RPi) and BCLK (split to RPi) to the I2S DAC, RPi would provide I2S data to the I2S data. I2S input and output data should be synchronous with MCLK, LRCK and BCLK from the extractor.

Another question for all, that i am sure it has been discussed somewhere but i don't remember. Can the rp5 do TDM?

I am not sure. I don't see a reference in the RP1 data sheet, however that doesn't necessarily mean it doesn't have the capability.

Michael

 

[phofman]

Do you think it would be possible to take the master clock from the extractor and connect it directly to the DAC and have it working in slave mode to have both in synchronous mode?

IMO it's the only working mode as there is only one I2S I/O interface working at the same time - either master, or slave. That means if you use the extractor I2S clock lines (I2S master) and clock both RPi5 and your DAC with them (+ the extractor MCLK output if available), it should work OK.

Another question for all, that i am sure it has been discussed somewhere but i don't remember. Can the rp5 do TDM?

I2S details in RP1 datasheet are solved by "For a reference implementation see the Synopsys I2S Linux kernel driver." Finding the DWC I2S technical docs takes a while as DesignWare does not provide these publicly. Fortunately a number of implementations include them in their datasheet, e.g. https://www.ampedrftech.com/datasheets/ACH1190_Datasheet.pdf or https://filebin.net/3kekvvgu489hl1fw/i2s-docs-HS6621Cx_Datasheet_V1.5.pdf (valid for 6 days, I cannot find the PDF anymore online, I dug it out from some chinese pages).

TDM support was added to the DWC I2S driver very recently in July '23, https://github.com/raspberrypi/linux/commit/221acc16aee16eb246bad32a6b9014021218b7cd , this patch is not in the official RPi 6.1 kernel. None of the two datasheets above mention TDM. My 2 cents TDM is not in the RP1 implementation. But it can be tried with that DT option dai-tdm-slot-* with the latest RPi kernel.

 

[MCH]

Thank you both!

 

[charlielaub]

Yes, 5.1/7.1 audio from streaming services

My hope would be to clock sync the UL Mk5 to HDMI extractor via the TOSLINK output of the HDMI extractor. This should allow me to avoid resampling in CamillaDSP. In synchronous systems I've been able to successfully use a chunk size of 256 and 48 kHz which gives around 15 ms latency with the UL Mk5, although I might need to increase chunk size. Long story short, under 30 ms.

Michael

Now that the hardware is shown to be clean, I am very interested in seeing how latency is impacted when N IIR filters are added to the chain within CDSP for each channel. Let's say N=5 would be a fair test. These should probably be second order filters, e.g. implement a second order Butterworth (Q=0.707) highpass at 100Hz five times in a row. I chose 100Hz because the delay at high frequency from this filter will be zero, and so the beginning of an impulse should remain unaffected. Then measure the latency from source (whatever is the source of your HDMI signal that is coming into the extractor) to the outputs of the ULmk5 and compare it to the case with no filtering. This will confirm how suitable the processing chain will be if used for movie audio processing, where audio and video must remain synchronized. If you can keep that under the 30msec you mentioned before that would really be a positive development for software audio processing, something I would really love to see.

Also, if you have the input and output synchronized via the extracted toslink clock you could use any other DSP type program to implement this processing chain. For example I started back over 10 years ago now with a simple LADSPA host called Ecasound, which has good control over buffer size but has no sample rate conversion/correction capabilities. The latter would be unnecessary for your setup, so it would be a simple alternative to CDSP.

 

[mdsimon2]

I plan on making some latency measurements but for reference I've been using a CamillaDSP based system with an Apple TV as my main A/V source for 2 years and there are no lip sync issues. I am implementing DIY active speakers and use an Okto dac8 pro running at 48 kHz and 512 chunk size. The Okto is clocked via a HDMI to SPDIF extractor and is run in AES / USB mode. It runs for months on end with no drop outs.

Just so I understand your request, are you saying you want to see latency with 5 BW2 HPFs on each channel?

Michael

 

[mdsimon2]

OK, did some latency testing.

For test setup I used a HDMI to TOSLINK extractor upstream of the HDMI to I2S extractor and routed the TOSLINK output from the upstream extractor to a RME Fireface 800. The RME was clocked via this TOSLINK input. HDMI continued out of the HDMI to TOSLINK extractor in to the HDMI to I2S extractor.

The other half of the chain was HDMI to I2S extractor -> RPi5 + CamillaDSP + MOTU Ultralite Mk5 as described elsewhere in the thread. MOTU analog output 1 was routed to RME analog input 1.

Measurements were made by running a frequency sweep in REW, main output channel was set to HDMI channel 1 and timing reference was set to HDMI channel 2. I used RME analog input 1 as my main measurement channel and right channel of RME TOSLINK input as timing reference.

CamillaDSP is running at 48 kHz and 256 chunk size with no resampling or rate adjust.

With no filters applied I ran 5 sweeps over the course of several minutes, reported latency in all cases was 15.66 ms.

I then applied a single 100 Hz BW2 HPF on one output channel, reported latency was 15.66 ms.

I then applied 5 100 Hz BW2 HPFs on all 8 channels and ran 5 sweeps over several minutes, reported latency was 15.66 ms.

Here is a comparison of impulse response between no filter and 5 HPFs applied to all 8 channels.

So easily under 20 ms latency with no impact from filters which matches my experience with my existing CamillaDSP system.

Michael

 

[charlielaub]

Thanks for doing that! 15msec latency is pretty darn good.

 

[Nspace]

You noticed that MotU has new drivers and firmware recently released?
Details here.

 

[gordoste]

Time for me to buy an RPi5. I am looking to create a RPi multi-channel soundcard HAT (although it won't be the HAT form factor). Is anyone interested in reviewing schematics and PCB design? I can move it to a separate thread.

 

[MCH]

Time for me to buy an RPi5. I am looking to create a RPi multi-channel soundcard HAT (although it won't be the HAT form factor). Is anyone interested in reviewing schematics and PCB design? I can move it to a separate thread.

I plan to build a HDMI to multichannel i2s hat using the IC of a extractor I already have.

The idea is to then use my Motu UL as multichannel dac and have a simple HT similar to what Michael has been testing.
If I see I have space enough I might add the footprints for a i2s multichannel dac on the same hat, just to experiment with the extra PCBs I get.
But I will take it easy, I have a few other projects going on, including building a house...

Please open a thread, I will be very interested. How do you plan to handle the cooling? I see they sell a fan hat for the pi5, but I am not sure if 1. It is necessary for this application. 2. it is compatible with regular shape hats.

 

[gordoste]

Yeah I am hoping mine comes in under $100, so it is cheap and doesn't take a lot of space. Anyone who wants premium performance needs to buy a commercial product. Surely the Pi5 fan doesn't totally block HATs? I will investigate.

 

[mdsimon2]

I moved the RPi5 to my main Okto system today. This system uses an Apple TV 4K as the source which brought up some issues with the HDMI to I2S extractor due to the extra bandwidth. The HDMI output of the extractor will pass 4K SDR 4:2:0 at 60 Hz, however, will not pass 4K HDR or Dolby Vision or 4:4:4 color.

I tried using a monoprice HDMI splitter upstream of the extractor. It has the ability to downscale each output from 4K to 1080P and has the option to either pick the best common EDID setting between the outputs or to copy the EDID settings from the first output to the second output. I figured I might be able to get full resolution by having my TV hooked up to output 1, using the copy setting and downscaling outpu 2 to the HDMI to I2S extractor. I got full resolution video to my TV but no sound. I guess I need a device with more advanced EDID management?

I set the Apple TV 4K to not change format so I can get multichannel LPCM out. I modified my typical CamillaDSP setup to use the I2S input of the RPi5. I first tried clocking the Okto from the SPDIF output of the extractor while in USB / AES mode. This worked but I would get dropouts for the first few seconds after starting playback. I then added a HDMI to TOSLINK extractor upstream of the HDMI to I2S extractor and used TOSLINK from the upstream extractor to clock the Okto, this seems to work without issue. The Okto seems to work fine in USB / AES mode even though I am not actually using the AES input.

I don't have a multichannel system but in CamillaDSP I mixed in the center channel to all channels and added the LFE channel to my subs to test the multichannel output. So far so good. With the HDMI to I2S extractor set to "Amp" CEC works which means I can continue to use the Apple TV remote to turn the TV on / off and control the volume on the Okto which is nice.

I plan on living with this setup for a while to make sure it is stable. If anyone has a recommendation for a better HDMI splitter I would love to hear it!

EDIT: I did a bit more troubleshooting. It seems like my TV (Vizio M558-G1) is the culprit. It doesn't accept 7.1 LPCM (it is an older TV and does not have eARC), so if I use the EDID settings of the TV it explains why I don't get multichannel sound on the HDMI to I2S extractor. If I put the HDMI to I2S extractor on output 1 and use copy EDID settings, I get sound but the TV resolution is limited to 1080P, which is odd because I can get 4K SDR if I go straight to the HDMI to I2S extractor and use the HDMI output to the TV. I think something like the SHARC V2 (https://www.thenaudio.com/product/sharc-v2-8k-earc-audio-processor/) will allow me to send 4K HDR/DV to my TV and 7.1 LPCM audio to the HDMI to I2S extractor, but not entirely sure.

Michael

 

[MCH]

Time for me to buy an RPi5. I am looking to create a RPi multi-channel soundcard HAT (although it won't be the HAT form factor). Is anyone interested in reviewing schematics and PCB design? I can move it to a separate thread.

@gordoste this is the first "proof of concept" for a HDMI -> MCH i2s hat recovering some work i had for a different project.
All the components necessary are there, all SMD components are 0805 (easy to hand solder) and all are on one side. I superimposed a RPi 5 rough footprint and as you can see it is doable if using the space on top of the connectors. Of couse everything needs to be reorganized to leave the header space free, but i think there is space enough.

What is definitely not possible is to have a multichannel DAC on the same hat, unless i use the bottom side, what is feasible but makes it for me much more difficult to correct any soldering mistake.

This hat is just a multichannel extractor and hopefully ARC. The problem for me is that I would like to use the apps in my TV, and mistakenly thought ARC would be enough, but seems that eARC is needed to have non compressed multichannel, and i dont see a feasible way to build a eARC capable hat.... this is a bummer for me and kind of makes me lose interest on the project. I have a fire stick that i could use with this setup but i don't think my family is willing to use it, the tv apps are much more convenient.

However, i have seen these boxes that take eARC and output a "only audio HDMI". I have no idea what that means and if one of these boxes in between the TV and the hat would do the trick. I am not sure if i want to get the thing done and find out. Will see.

https://www.amazon.de/-/en/FeinTech-AX110-Audio-Extractor-Converter/dp/B0CC9935WX/ref=pd_ci_mcx_mh_mcx_views_0?pd_rd_w=RmdPJ&content-id=amzn1.sym.f81e69b0-8d25-4d0a-a0ba-d47e95a31f14%3Aamzn1.symc.ca948091-a64d-450e-86d7-c161ca33337b&pf_rd_p=f81e69b0-8d25-4d0a-a0ba-d47e95a31f14&pf_rd_r=MXZJ1ND54K74Z5A3HPF7&pd_rd_wg=dvIVd&pd_rd_r=7a3ce8af-fb9b-499d-a9ad-b76ddd7879a2&pd_rd_i=B0CC9935WX&th=1

 

[gordoste]

That's cool. I wouldn't be worrying about soldering 0603 SMD components, if you can solder the IC and HDMI connectors then that's easy! Personally I use a DIY reflow oven which saves a lot of time.
You might wonder why I don't use HDMI. I have no surround sound speakers - I am using my TV as the media centre, and taking the stereo output from it and using my Pi as an active crossover. I also want to have more than one stereo input, to avoid the need for a separate input switching mechanism (e.g. if I want to play music from a different source). So I just need an old-school soundcard. The thing that doesn't fit on the HAT is the input and output filtering for so many channels.
If the Pi supported eARC, that would solve your problem, as I considered that previously. Unfortunately it doesn't.

 

[charlielaub]

Here is an new product that might be of interest to @mdsimon2 and others reading this thread... it's the Orange Pi 5 Plus.

What is very interesting about the 5 Plus is that I/O includes a full size HDMI input! With this and a multichannel DAC you could do all the processing on the same board. It would not have the clocking output via SPDIF but I assume the HDMI input could be a clock source...

Orange Pi - Orangepi