Hello,
I consider designing and building a board fill the gap between a Linux streamer, CamillaDSP and Class D amplifier modules. Same functionnal use case normally as Motu, Okto Dac8, Topping DM7... but simpler, cheaper and open. It would be TDM (multi channel I2S) input to 8 x differential analog outputs, to fill the gap between a Linux streamer (any Single Board Computer (SBC) similar to RaspberryPi, but with TDM), CamillaDSP (for ex) and multi-channel Class D amplifier modules. Core could be an AK4458 (or similar).
I wonder if this is a "niche use case" interesting only few of us or if we are more than that.
I would be happy to hear about people having this type of set-up, and what it is composed of. If there could be some interest for a multi-channel DAC bridging a Linux SBC to balanced In Amplifiers...
Criterias:
Additional question: are the amplifiers boxeed together near the streamer? Or more an "active speaker topology" with amplifiers near each speaker?
Me:
Best regards,
JMF
Nota: not clear to me what is the best forum for that question as it is "system oriented": streamer/DAC/DSP/Speakers/DIY. I posted a similar question on AudioScienceReview.
I consider designing and building a board fill the gap between a Linux streamer, CamillaDSP and Class D amplifier modules. Same functionnal use case normally as Motu, Okto Dac8, Topping DM7... but simpler, cheaper and open. It would be TDM (multi channel I2S) input to 8 x differential analog outputs, to fill the gap between a Linux streamer (any Single Board Computer (SBC) similar to RaspberryPi, but with TDM), CamillaDSP (for ex) and multi-channel Class D amplifier modules. Core could be an AK4458 (or similar).
I wonder if this is a "niche use case" interesting only few of us or if we are more than that.
I would be happy to hear about people having this type of set-up, and what it is composed of. If there could be some interest for a multi-channel DAC bridging a Linux SBC to balanced In Amplifiers...
Criterias:
- source is a Linux SBC (not sure Windows machines or Mac can expose/control TDM interface,
- filtering is done with DSP,
- each speaker driver is powered by a dedicated amplifier,
- those are not off the shelf active speakers.
Additional question: are the amplifiers boxeed together near the streamer? Or more an "active speaker topology" with amplifiers near each speaker?
Me:
- RPi with Moode,
- CamillaDSP for room correction,
- USB2I2S Asynch board,
- 2xDIY TAS3251 NeatAmp amplifiers, each one driving a speaker. Each TAS3251 implements the LX-Mini Crossover in its internal DSP,
- LX-Mini
- I groupped in the same box the Meanwell power supply, the USB2I2S Asynch board, and the 2xNeatAmps. A cable with 2 pairs to drive the LX-Minis.
Best regards,
JMF
Nota: not clear to me what is the best forum for that question as it is "system oriented": streamer/DAC/DSP/Speakers/DIY. I posted a similar question on AudioScienceReview.
If you are concerned about it being a bit of a niche product, I think you are right about that. How many computer platforms give you I2S on a header? SBCs like the Pi or other ARM boards, yes, and that is about it I think.
Otherwise, the overall concept sounds good. You could design it as a HAT for the Pi, since there have been very few good multichannel DAC HATs.
IMHO onboard amplifiers are not worth including in the design. Let the application determine what sort of amplification and power levels are needed. This can vary alot from one speaker project to another.
Otherwise, the overall concept sounds good. You could design it as a HAT for the Pi, since there have been very few good multichannel DAC HATs.
IMHO onboard amplifiers are not worth including in the design. Let the application determine what sort of amplification and power levels are needed. This can vary alot from one speaker project to another.
Thanks Charlie for the valuable feedback.
In my idea, to make it easy on the design side, genuine RaspberryPi can't be used as their I2S is exposed but limited to stereo.
So other "similar" SBC has to be used that has exposed I2S with TDM (Radxa RockP, Pine64, OrangePi...). Those SBC have similar functions and often same GPIO header but don't have as big communities and support.
Do you believe that it is a show stopper for potential users?
Agreed for the onboard amplifiers. They have to be kept separate from the DAC board.
JMF
In my idea, to make it easy on the design side, genuine RaspberryPi can't be used as their I2S is exposed but limited to stereo.
So other "similar" SBC has to be used that has exposed I2S with TDM (Radxa RockP, Pine64, OrangePi...). Those SBC have similar functions and often same GPIO header but don't have as big communities and support.
Do you believe that it is a show stopper for potential users?
Agreed for the onboard amplifiers. They have to be kept separate from the DAC board.
JMF
The MAJOR show stopper is the software, as always. A common multichannel I2S + I2C hat can be used basically on any 3.3V SBC, using a simple shim rerouting the pins as required for the specific SBC. But every SBC requires a specific kernel + DTS configs, which need to be kept up-to-date to allow new kernel features running on the device. And that is the huge work and long-term commitment. A good example of that is Armbian and their approach/policy towards new SBCs e.g. https://docs.armbian.com/User-Guide_Board-Support-Rules/ . Basically if you want to have a board supported, either do it yourself and make an official commitment to long-term support, or pay them. That's a healthy model, IMO.
Hello phofman,
Effectively. I did a bit of homework about Devive Tree Overlays and the configuration for such an application. Even if relying on components and interfaces well implemented in the mainline kernel, the deployment on different SBC and distribution versions is more complex than pushing files in correct location and modifying some txt file. Not good... And drivers are another concern.
But this is a different topic than the one I would like to be discussed in this thread, more oriented on the application/usage side (but this is a very important aspect).
JMF
Effectively. I did a bit of homework about Devive Tree Overlays and the configuration for such an application. Even if relying on components and interfaces well implemented in the mainline kernel, the deployment on different SBC and distribution versions is more complex than pushing files in correct location and modifying some txt file. Not good... And drivers are another concern.
But this is a different topic than the one I would like to be discussed in this thread, more oriented on the application/usage side (but this is a very important aspect).
JMF
I hesitate to say this as I know you have received the same feedback from others but I really don't see the point of this project.
There are a lot of very good commercial options across a variety of price ranges. On the low cost side HDMI out in to a used receiver is one of the most inexpensive options, another good low cost option is a miniDSP USBstreamer/MCHstreamer using ADAT out in to an older pro audio ADAT DAC.
If you did want to stick with a TDM DAC design the USBstreamer would be a good way to get TDM in to it with a variety of sources where you would not be limited to a niche SBC.
Michael
There are a lot of very good commercial options across a variety of price ranges. On the low cost side HDMI out in to a used receiver is one of the most inexpensive options, another good low cost option is a miniDSP USBstreamer/MCHstreamer using ADAT out in to an older pro audio ADAT DAC.
If you did want to stick with a TDM DAC design the USBstreamer would be a good way to get TDM in to it with a variety of sources where you would not be limited to a niche SBC.
Michael
Thanks for all those feedbacks. Sometimes you channel in one idea that looks OK to you, and can spend too much time on something that doesn't appeal to others. So benefit is limited at the end....
I thought that price of USB in - 8xout existing products could be an issue but it seems that it is not.
USB input is clearly more versatile, but:
However as long as there is no real need from the community, time investment won't be really justified (even if it is a hobby)
I thought that price of USB in - 8xout existing products could be an issue but it seems that it is not.
USB input is clearly more versatile, but:
- XMOS is the best technical solution, but it seems not like a chip you put on the PCB. You have to program it, so new techno to learn, dev board to learn and program... With little hope to reuse it for something else than USB input,
- stm32 I know, but no proven USD UAC2 stack,
- NXP has the USB UAC2 stack, but have to learn a new ecosystem. Could be the easiest option for DIY...
However as long as there is no real need from the community, time investment won't be really justified (even if it is a hobby)
Last edited:
For USB it's contained in the UAC2 protocol. For I2S - typically only one bitdepth is used (32bits), no reason to complicate with switching bit depths over I2S. For sampling rate - either the DAC detects the incoming rate automatically, or some side channel is used (I2C, GPIO pins) - specific for every DAC chip.
I'm interested here to learn what people really use (compared to what is possible).
If I'm not wrong, the USB device has to expose the available options. Which then in turn have to be coded. My previous stm32 USB UAC1 asynch interface managed only 16 bits at 48kHz. This was fine for me. I wonder if this is sufficient or if people have different needs.
What do you use in you setup normally?
JMF
If I'm not wrong, the USB device has to expose the available options. Which then in turn have to be coded. My previous stm32 USB UAC1 asynch interface managed only 16 bits at 48kHz. This was fine for me. I wonder if this is sufficient or if people have different needs.
What do you use in you setup normally?
JMF
Can this be interesting for you?
https://www.diyaudio.com/community/...-x-over-with-hdmi-and-av-receiver-pdf.795229/
Best Regards
Guenter
https://www.diyaudio.com/community/...-x-over-with-hdmi-and-av-receiver-pdf.795229/
Best Regards
Guenter
I use RME digiface usb - toslink... for 2-way active... CamillaDSP on a Mac Mini.
I'm satisfied with 24/44 and would lik to see 8 and 16 channels available for system solutions.
But to get more channels than 8 out of a the RME digiface one need to go ADAT... so I'm seeking an ADAT compliant 4 toslink in (16ch ADAT) -> 8 toslink out (16ch) kind of box to be used, in the end, with ordinary stereo DACs that take toslink. Where can I get one?
I'm thinking also of a one-box solution; mains, ethernet in + USB disk in, streamer, DAC(s), 4 ch very high quality 2x200W + 2x50w-ish/ch out. A display + a remote
//
I'm satisfied with 24/44 and would lik to see 8 and 16 channels available for system solutions.
But to get more channels than 8 out of a the RME digiface one need to go ADAT... so I'm seeking an ADAT compliant 4 toslink in (16ch ADAT) -> 8 toslink out (16ch) kind of box to be used, in the end, with ordinary stereo DACs that take toslink. Where can I get one?
I'm thinking also of a one-box solution; mains, ethernet in + USB disk in, streamer, DAC(s), 4 ch very high quality 2x200W + 2x50w-ish/ch out. A display + a remote
//
@JMF11 I am doing this, using RPi 4B with CamillaDSP sending to the suptronics HDMI audio extractor board that is discussed at length in a different thread. But eventually that board will stop working and there isn't a good replacement for it. RPi4, 4 of these TPA3116 boards, Meanwell SMPS (and 24V/5V DC/DC converter), suptronics board plus RCA input switcher and ADC hat are all inside a DIYaudio.com case. 8-pole Speakon cables go to my DIY 3-way speakers based on Troels Gravesen's Bookshelf-3WC design (but of course with no crossover in it).
Personally, I do not want to use a USB DAC because if you have your SBC and amps in the same case then you want the RPi's USB ports to be exposed externally, and that means you can't have the DAC inside the case. Also, a separate DAC (whether a board or a box) takes up a lot more space than a HAT and requires power connections.
There is another recent thread here where we were discussing potential multi-channel I2S on RPi 5. If it does in fact support 8ch I2S, then I would expect multi-channel DAC hats to be released by vendors like HiFiBerry.
I would definitely be interested in helping to develop and prototype an open-source 8-channel DAC Hat.
Personally, I do not want to use a USB DAC because if you have your SBC and amps in the same case then you want the RPi's USB ports to be exposed externally, and that means you can't have the DAC inside the case. Also, a separate DAC (whether a board or a box) takes up a lot more space than a HAT and requires power connections.
There is another recent thread here where we were discussing potential multi-channel I2S on RPi 5. If it does in fact support 8ch I2S, then I would expect multi-channel DAC hats to be released by vendors like HiFiBerry.
I would definitely be interested in helping to develop and prototype an open-source 8-channel DAC Hat.
I think perhaps it is about wanting to choose once DACs
but for many of my "experiments" I think such a device that you mention would be ideal. //
Not sure how relevant my approach is to you, but FWIW I used to do this kind of multi-way active crossover thing on windows, and now am revisiting it but on Linux. I really like the flexibility of software crossovers and EQ and have always preferred bi/tri-amping etc. so the general approach appeals to me. I'm quite surprised more people don't do it, really.
Currently I'm experimenting with using a raspberry Pi4 in USB-Gadget mode - so a Host PC will see it simply as a USB playback device; it is early days, but it seems to have a lot of potential. In the past I've used various kinds of network streaming with servers, control points and clients, but for use in the same room I'm greatly enjoying the simplicity of playing direct to a USB device. Arguably it might be better to do this all on one PC and omit the Pi, but I like that the Pi is dedicated to this one task, so then any source PC or laptop (maybe even phone) could play to it without needing special setup.
I believe g_audio might be able to offer the USB gadget in more than one rate, and there is scripple's IO plugin to make CamillaDSP responsive too. Though previously I've been quite happy using a fixed rate between input and output, and have so far taken that approach here too; letting the (much more capable) Host PC upsample its various sources to that rate; in my case 96K 32-bit, which is well above what I'd ever need. But many audiophiles would likely cringe at the very idea, so auto-switching to the source's native rate and maintaining this throughout could be a more saleable approach.
I have a DM7 as the DAC, but in the past have had good results with more modest interfaces and even USB soundcards (e.g ASUS Xonar 7.1). I lost interest in I2S (for practical reasons; I find USB so much more generic and flexible) so haven't really gone there recently. However my belief is that DACs should ideally become unnecessary at some point, in this kind of PC-based setup. For a long time now my sytem's signal path would have been purely digital were it not for the last stage, the power amp(s), and now we are starting to see fully digital amps. So staying with a digital path from source to amp is something I might aspire to for a future setup.
Currently I'm experimenting with using a raspberry Pi4 in USB-Gadget mode - so a Host PC will see it simply as a USB playback device; it is early days, but it seems to have a lot of potential. In the past I've used various kinds of network streaming with servers, control points and clients, but for use in the same room I'm greatly enjoying the simplicity of playing direct to a USB device. Arguably it might be better to do this all on one PC and omit the Pi, but I like that the Pi is dedicated to this one task, so then any source PC or laptop (maybe even phone) could play to it without needing special setup.
I believe g_audio might be able to offer the USB gadget in more than one rate, and there is scripple's IO plugin to make CamillaDSP responsive too. Though previously I've been quite happy using a fixed rate between input and output, and have so far taken that approach here too; letting the (much more capable) Host PC upsample its various sources to that rate; in my case 96K 32-bit, which is well above what I'd ever need. But many audiophiles would likely cringe at the very idea, so auto-switching to the source's native rate and maintaining this throughout could be a more saleable approach.
I have a DM7 as the DAC, but in the past have had good results with more modest interfaces and even USB soundcards (e.g ASUS Xonar 7.1). I lost interest in I2S (for practical reasons; I find USB so much more generic and flexible) so haven't really gone there recently. However my belief is that DACs should ideally become unnecessary at some point, in this kind of PC-based setup. For a long time now my sytem's signal path would have been purely digital were it not for the last stage, the power amp(s), and now we are starting to see fully digital amps. So staying with a digital path from source to amp is something I might aspire to for a future setup.