Kii Three, D&D 8c, Neumann Monitors, Genelec…. And many others rely on digital / DSP / Class D amplifiers, one per driver => I works great. Many don't have anymore Analog sources and use only digitized music. Streamers replace turntables…
Rpi packs some much for Audio applications is a cheap small package. It has great audio features. CamillaDSP is powerful and flexible. Many cheap and great Class D differential analog input amplifiers are available around (TPA3251, TPA3255, Merus MA).
I may have missed something, but the weak link here is how to gap the multiple audio channels in the Rpi to the amplifiers. RME / Okto DAC8 / Motu4 / Focusrite do the job, but are expensive. My first answer has been the digital In / Integrated DSP NeatAmp based on the TAS3251. It works and drive beautifully my LX-Mini. Can we do more modular / versatile / cheap?
Proposal would be a HAT for Single Board Computer that would implement Linux alsa => TDM (multi-channel I2S) => DAC with 8 x differential analog outputs. Linux would be the player, the DSP, possibly the USB interface (USB gadget) or AES67 (if exists on Linux). The HAT would be seen as a 8 channels sound card. Class D amps inputs would be connected to the HAT to implement up to 8 channels. Having differential analog interface, users would have freedom to choose their module.
Rpi / HAT / amplifiers all in the same box. Or balanced XLR - 1/4" TRS to the amplifiers.
8 channels DAC with TDM inputs from ESS, AKM, TI are in the 5-30€ range. Needs good power supplies, clock, buffers, maybe a small uC.
OK, bad luck, the Rpi does not supports TDM (yet). But some alternatives do, run equivalent Linux, support CamillaDSP and MPD… Good enough? The HAT would be along the Rpi GPIO header compatible to ease interfacing with other SBCs that would have similar pinout. And maybe one day a Rpi will do TDM…
Performance target would be DAC datasheet performance, using datasheet implementation (ex not select the 90€ DAC, but select a good one that squeeze most of the performance in the 5-30€ range).
What would be your feedback on the use case? Is it something that we need? In which type of projets would it be usefull?
What would make it not so sexy? What are the alternatives it would be in competition with?
What are the expected difficulties:
I don’t have the skill in all needed areas. Would some willing to contribute?
Feedback welcomed!
Candidate DACs:
Best regards,
JMF
Rpi packs some much for Audio applications is a cheap small package. It has great audio features. CamillaDSP is powerful and flexible. Many cheap and great Class D differential analog input amplifiers are available around (TPA3251, TPA3255, Merus MA).
I may have missed something, but the weak link here is how to gap the multiple audio channels in the Rpi to the amplifiers. RME / Okto DAC8 / Motu4 / Focusrite do the job, but are expensive. My first answer has been the digital In / Integrated DSP NeatAmp based on the TAS3251. It works and drive beautifully my LX-Mini. Can we do more modular / versatile / cheap?
Proposal would be a HAT for Single Board Computer that would implement Linux alsa => TDM (multi-channel I2S) => DAC with 8 x differential analog outputs. Linux would be the player, the DSP, possibly the USB interface (USB gadget) or AES67 (if exists on Linux). The HAT would be seen as a 8 channels sound card. Class D amps inputs would be connected to the HAT to implement up to 8 channels. Having differential analog interface, users would have freedom to choose their module.
Rpi / HAT / amplifiers all in the same box. Or balanced XLR - 1/4" TRS to the amplifiers.
8 channels DAC with TDM inputs from ESS, AKM, TI are in the 5-30€ range. Needs good power supplies, clock, buffers, maybe a small uC.
OK, bad luck, the Rpi does not supports TDM (yet). But some alternatives do, run equivalent Linux, support CamillaDSP and MPD… Good enough? The HAT would be along the Rpi GPIO header compatible to ease interfacing with other SBCs that would have similar pinout. And maybe one day a Rpi will do TDM…
Performance target would be DAC datasheet performance, using datasheet implementation (ex not select the 90€ DAC, but select a good one that squeeze most of the performance in the 5-30€ range).
What would be your feedback on the use case? Is it something that we need? In which type of projets would it be usefull?
What would make it not so sexy? What are the alternatives it would be in competition with?
What are the expected difficulties:
- linux side?
- hardware side?
- others?
I don’t have the skill in all needed areas. Would some willing to contribute?
Feedback welcomed!
Candidate DACs:
- AK4458,
- ES9027PRO,
- PCM1690,
Best regards,
JMF
RPi tends to produce conducted and radiated EMI/RFI. Also, the GPIO bus is jittery. If wanting to use RPi and if dac performance matters, probably better to use it as a USB host for a decent multichannel dac, with the dac shielded and or separated somewhat from the RPi. There are various USB options out there such as multi channel recording interfaces and or Oktodac, for some possible examples.
This thread might interest you: https://www.diyaudio.com/community/...rry-pi-interface-options.395392/#post-7258299
RPi GPIO bus is not the way to go unless you use a multi-channel isolator/reclocker and some shielding and or physical separation. What do you think made Iancanada offer products like Shield_Pi and StationPiPro?
https://www.audiophonics.fr/en/acce...i-and-hat-boards-adapter-station-p-16550.html
https://www.audiophonics.fr/en/powe...r-supply-filter-for-raspberry-pi-p-16965.html
These things are no joke if wanting to use RPi GPIO bus for serious audio. However, you don't need all that stuff if you use galvanically isolated asynchronous USB, along with some shielding and or physical separation.
Now if the question is can you make a multi-channel dac poorly and without careful attention to detail, then the answer is of course, Yes.
https://www.audiophonics.fr/en/acce...i-and-hat-boards-adapter-station-p-16550.html
https://www.audiophonics.fr/en/powe...r-supply-filter-for-raspberry-pi-p-16965.html
These things are no joke if wanting to use RPi GPIO bus for serious audio. However, you don't need all that stuff if you use galvanically isolated asynchronous USB, along with some shielding and or physical separation.
Now if the question is can you make a multi-channel dac poorly and without careful attention to detail, then the answer is of course, Yes.
many definitions of serious, some people seriously have never heard any difference between DACs or carts or AMPs, some have never seen aliens ? I don't know if any amount of galvanic isolation could fix all the issues with the PI but they are fun and useful if your not to serious or cant tell a doggle from a denafrips. This will all be a moot point as the PI is going down, unable to deliever product
Yeah, true. However, some of those same people have never had an opportunity to hear an all around really good system. IME when they do they are usually surprised at what is possible, even if they are not attuned to notice every little detail. Again IME, they sometimes tend to say things like, "That's a CD!?" Followed by, "How much does it cost?"
No matter the answer, even on a very modest budget there are technically better and worse ways of proceeding. In that regard, the attraction of RPi hats is more of a cool fad than a wise choice for good audio design.
No matter the answer, even on a very modest budget there are technically better and worse ways of proceeding. In that regard, the attraction of RPi hats is more of a cool fad than a wise choice for good audio design.
This is not the right time to speak about RPi, but this semiconductors shortage won't last forever. Despite of that, I bought a few weeks ago a board - model 3A+ with about EUR 35 including VAT and shipping. Two years ago I bought model 4B+/4GB with EUR 55. At this price, it beats any reasonable USB2I2S module on the market.
As a standalone network player project, RPI is unbeatable. Even as an USB player, it is a powerfull solution.
But YES, you should take care about the issues Mark pointed of, but most of them are also valid for USB2I2S solutions powered by an HTPC. Maybe it is a little harder to do that for RPi, due to EMI radiation, but look at the advantages above!
@JMF11 I think that considering RPi as starting point of your project is a very good choice. I would reccomend you not to give up the I2S benefit of RPi. There are not so many good implementations of USB2I2S modules on the market, and even if you will pay the price, you have no (easy) control over its firmware!
As a standalone network player project, RPI is unbeatable. Even as an USB player, it is a powerfull solution.
- you can implement a silent (passive) cooling system;
- you can reduce noie using a better power supply easier than for an HTPC/laptop;
- it has less noise sources (there are a lot of PMICs in any HTPC/laptop, a single one on RPi), so it is easier to filter/isolate it;
- it is easier to disable HDMI out, Audio Out, etc if you don't need them, to reduce power consumption and noise;
- it has many GPIOs, so you don't need an additional microcontroller for buttons/rot-encs/IR-recv, etc.
- it has I2S output/input pins, they are jittery, I agree, but it can be configured as a slave or as a master I2S; (an HTPC/laptop doesn't have it)
- it benefits of a huge software support, mostly open source;
But YES, you should take care about the issues Mark pointed of, but most of them are also valid for USB2I2S solutions powered by an HTPC. Maybe it is a little harder to do that for RPi, due to EMI radiation, but look at the advantages above!
@JMF11 I think that considering RPi as starting point of your project is a very good choice. I would reccomend you not to give up the I2S benefit of RPi. There are not so many good implementations of USB2I2S modules on the market, and even if you will pay the price, you have no (easy) control over its firmware!
Last edited:
Thanks all for the valuable feedback. It allows to assess the benefits, not understimate the difficulties.
@Markw4 : So EMI are an important concern, as well as the jittery I2S of the Pi. Thanks to the examples and links to good practices.
Would you have identified USB2I2S multichannel modules on the market (USB to TDM or to 4xI2S), possibly with galvanic isolation?
Can the DACs mitigate the jitter issues at their level?
I have seen this: https://www.audiosciencereview.com/...s-of-audiophonics-dac-i-sabre-es9038q2m.8640/
It seems to show that well engineered board can mitigate some of the difficulties and deliver decent performance.
Maybe I should not stress here on the "Rpi HAT" concept but more on "TDM in / 8xdifferential analog out"
@ernperkins : thanks for the link to the interfaces options. This helps identify "competitors"
@Indigent Audio : I have seen this FreeDSP Octavia, and sort of started from there. I'm more of a software guy and already use CamillaDSP, I like the idea to "simplify" and just "fill the gap" from CamillaDSP to multiple differential outputs.
@Thorp : in fact the Rpi is not suitable for the project as the I2D does not supports TDM. So target is "any" SBC with TDM I2S and RPi header.
@All: I understand that this may be more a "PC base" topic. However many of the pitfalls for such a project are in fact DAC related. Possibly clients are on the PC based forum, but experts are here
Competitors:
@Markw4 : So EMI are an important concern, as well as the jittery I2S of the Pi. Thanks to the examples and links to good practices.
Would you have identified USB2I2S multichannel modules on the market (USB to TDM or to 4xI2S), possibly with galvanic isolation?
Can the DACs mitigate the jitter issues at their level?
I have seen this: https://www.audiosciencereview.com/...s-of-audiophonics-dac-i-sabre-es9038q2m.8640/
It seems to show that well engineered board can mitigate some of the difficulties and deliver decent performance.
Maybe I should not stress here on the "Rpi HAT" concept but more on "TDM in / 8xdifferential analog out"
@ernperkins : thanks for the link to the interfaces options. This helps identify "competitors"
@Indigent Audio : I have seen this FreeDSP Octavia, and sort of started from there. I'm more of a software guy and already use CamillaDSP, I like the idea to "simplify" and just "fill the gap" from CamillaDSP to multiple differential outputs.
@Thorp : in fact the Rpi is not suitable for the project as the I2D does not supports TDM. So target is "any" SBC with TDM I2S and RPi header.
@All: I understand that this may be more a "PC base" topic. However many of the pitfalls for such a project are in fact DAC related. Possibly clients are on the PC based forum, but experts are here
Competitors:
- Behringer UMC1820: ~260€
- Evo by Audient EVO 16 interface audio : ~435€
- Topping DM7: ~599€
- MOTU - Interface audio USB UltraLite-mk5 18 x 22: ~730€
- Okto DAC8 : ~1300€
Last edited:
Just fell on that for some hope:
"Jitter test over either USB or network was very good showing that a "noisy" computer need not cause any problem for a properly designed DAC..." (https://www.audiosciencereview.com/...ini-lcd-kit-review-streamer.27456/post-946292)
Inside: https://www.audiophonics.fr/fr/modu...n-raspberry-pi-i2s-spdif-pcm-dsd-p-12811.html
"Jitter test over either USB or network was very good showing that a "noisy" computer need not cause any problem for a properly designed DAC..." (https://www.audiosciencereview.com/...ini-lcd-kit-review-streamer.27456/post-946292)
Inside: https://www.audiophonics.fr/fr/modu...n-raspberry-pi-i2s-spdif-pcm-dsd-p-12811.html
IMO focusing on RPi for a multichannel is not the best choice.
Either USB - any PC will do, and IME x86 thin clients make a better device, including professional metal case with proper EMI/RFI certifications, top-quality power adapter, and often lower final price.
Or I2S - RPi does not have the necessary HW and any further version (I have not seen any RPi5 official announcement) may not have it either.
Either USB - any PC will do, and IME x86 thin clients make a better device, including professional metal case with proper EMI/RFI certifications, top-quality power adapter, and often lower final price.
Or I2S - RPi does not have the necessary HW and any further version (I have not seen any RPi5 official announcement) may not have it either.
Probably best to take that with a grain of salt. Those guys don't seem know that J-Test is intended for seeing PSS deterministic jitter. The test is not useful for random jitter (or effectively random jitter as viewed on an FFT).
Multichannel USB2I2S modules tend to be uncommon. Don't know of any with galvanic isolation.
Asynchronous USB is good for exactly that. It allows the dac clock to be master clock for the audio system, rather than have it be the computer clock.
That said, its true that RPi GPIO bus I2S can operate in I2S Slave mode, which allows the dac to clock the GPIO I2S bus.
Its also true that Thorp raised some good points. One faces much the same problems whether using GPIO bus or USB bus. In both cases some combination of physical isolation and or shielding between the noise source and the dac is needed. Therefore a neat, compact hat stackup is probably not the wisest way to use RPi GPIO bus.
One big advantage of using USB is that it allows for more modularity of the reproduction system. The dac need not be married to a GPIO bus interface. If you want to upgrade the dac later there are a lot more options available if using USB. One can use an off-the shelf dac if desired.
Another reason to use USB is that I2S bus (at least in its LVCMOS form as used by dac chips) is not good for much physical separation. It needs to be converted to another signal format to go over any distance. That's why commercial dacs with I2S connectors on the back use LVDS signaling. IIRC, Iancanada makes boards to do that signal type interfacing.
Which brings me to the following thoughts: When I think of what it takes to really clean up RPi I2S, it tends to remind me of the path Iancanada has taken. In the end his customers tend to end up with several boards that over time end up costing as much or more than a good USB solution probably would have cost. If USB can suffice, its simply not necessary to go down that rabbit hole.
I also saw what Allo did with their Katana RPi hat dac. It sounded better with their isolator board between the dac and the RPi, and better yet with their low noise USBridge Sig substitute for RPi. Next dac they made after that was USB (Revolution dac), yet it was specifically promoted for use with RPi. IIRC from my email conversations back then with Ioan, their chief designer, Allo learned from experience and decided they would rather go with USB.
Last edited:
Not quite. J-test is intended to excite data-dependent jitter but it does not somehow exclude other types of jitter. Random jitter can possibly be seen as unrelated sidebands or noise skirt.
Anyhow published studies have found quite high detection threshold (30-300ns) for jitter (‘Theoretical and Audible Effects of Jitter on Digital Audio Quality’ by Benjamin and Gannon;
'Detection threshold for distortions due to jitter on digital audio' by Ashihara, Kiryu, Koizumi, Nishimura, Ohga, Sawaguchi, Yoshikawa).
My STM32F723 based USBI2S bridge has 6 channels with galvanic isolation. Making it 8-channel (or up to 16-channel with TDM) with isolation would be straightforward. But I don't have any use for such device.
Anyhow I don't see the point in all this. Economically this type of endeavour is not very practical as it would be very hard to compete price-wise with e.g. Topping, Behringer or MOTU. Choosing low grade DAC chips to cut costs is just silly.
I would agree that if we are interested in the threshold of audibility for the average ear of 'distortion' produced by jitter, then quite bit of jitter may be needed to become objectionable.
However, jitter is timing error as viewed in the time domain. Phase-noise is the corresponding measure as viewed in the frequency domain. Also, jitter is commonly treated differently in the literature as opposed to close-in phase noise, since they tend to have different effects on signal detection, and they may require different types of measurement equipment.
When I use the term jitter, I am including the effects of close-in phase noise. In that regard, 'distortion' is the not the first audible effect of close-in phase noise. What is affected at lower levels is the stereo illusion of sound stage (which is known to be sensitive to phase). A threshold of audibility for average ears for jitter/phase-noise as it affects soundstage is not something I have seen in published research.
However, jitter is timing error as viewed in the time domain. Phase-noise is the corresponding measure as viewed in the frequency domain. Also, jitter is commonly treated differently in the literature as opposed to close-in phase noise, since they tend to have different effects on signal detection, and they may require different types of measurement equipment.
When I use the term jitter, I am including the effects of close-in phase noise. In that regard, 'distortion' is the not the first audible effect of close-in phase noise. What is affected at lower levels is the stereo illusion of sound stage (which is known to be sensitive to phase). A threshold of audibility for average ears for jitter/phase-noise as it affects soundstage is not something I have seen in published research.
The best USBtoI2S board I have found is "one" that I made myself. There are very good boards on the market, but they are expensive (related to the diy ones) and sometimes they have connection issues. Having properly routed PCB traces, impedance controlled, to the DAC directly, instead of pinheaders or even u.fl connectors may have important benefits. XMOS have some good chips, and their audio refference design & examples & documentation & comunity suport are the best in this area. As I have seen a few days ago, Digikey has these parts on stock, I want to test in the near future the newer XU316.
@Markw4 I also have a good impression about Allo Katana hat dac. I actually use their Linux driver in one of my projects, which is based on Marcel's RTZ shift register FIRDAC project. This is one of the benefits of Linux, as a hobbiest you don't even have to make a new driver, but just to use an already made open source one, even if your hat is completely different than the original one.
@Markw4 I also have a good impression about Allo Katana hat dac. I actually use their Linux driver in one of my projects, which is based on Marcel's RTZ shift register FIRDAC project. This is one of the benefits of Linux, as a hobbiest you don't even have to make a new driver, but just to use an already made open source one, even if your hat is completely different than the original one.
Attachments
Iancanada, does it right for sure. But his products look expensive to me, to squeeze latest performance % or dBs from the products. And I know how those last % are expensive to get, with diminishing returns. I reckon this wouldn't be my target, nor to do a poor design.
The intention would be to do a sound design: use the the right stuff at the right place. Pay attention to what matters most. Pay attention to keep things easy to manufacture with hobbyist souces (lile JLCPCB) and cost.
Looking from the "system perspective", studio monitors pack a lot of value for finally incredible prices:
- JBL 305P: for 300€ you have DSP+amplification+Speaker with very good peformance,
- Neumann 120 II: for 900€ you have high end results DSP + amplification+Speaker. Same for Genelec
When you open those boxes, no fancy components most of the time: few $ CODEC, DACs, Class D chips... and very good engineering from people that know their job. The Power supply is still on-board with its EMI, I have not seen fancy isolation, reclocking... As all is integrated, the distances between parts are short and everything is kept simple and efficient...
This issue with the specific "USB for multi-channel use case" is just the lack of off the shelf easy solution. Even with XMOS, you need learn their SDK to achieve the thing. If it is your daily job, fine. But too complex for most hobbyist. I like Asynch USB a lot, and my current set-up works with an USB2I2S asynch module that you had advised to me some years ago (here I do the splitting and DSP after the USB in).
As of today, for multi channel application, the simplest common denominator between software (CamillaDSP, Streamers, Linux) and Analog (DACs/Amplifiers) world seems to be I2S TDM.
To do it clean, the DAC should be the clock Master and the computer should be Slave. I think that this can be done. To be confirmed.
Thanks a lot for all those information. they are very important to arrive to something that makes sense.
JMF