Who is doing Linux / DSP / multi-amplification (multi channel) ?

[jmf11]

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 5SBC) similar to RaspberryPi, but with TDM), CamillaDSP (for ex) and multi-channel Class D amplifier modules.

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.

Additional question: are the amplifiers boxeed together near the streamer? Or more an "active speaker topology" with amplifiers near each speaker?

My case:
- 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.

Hope to hear from you.

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

 

[arvidb]

In essence, what you're proposing is a multichannel DAC, I2S/TDM in and balanced out?

I'm all for open source/hw things, but if you want to make it a group effort, I think some things need clarification:

• You mention DSP; so do you want to use it instead of e.g. CamillaDSP? If so, what format for the filters, how to update them etc.
• Quality/price/flexibility compared to any alternatives: what SINAD are you aiming at? For okay-ish SINAD there are a lot of cheap alternatives in the RPi hats, e.g. Raspberry Pi DAC Pro. A set of these also allow mix-and-match of SE/balanced/SPDIF(?) outputs at different SINAD levels (e.g. a cheaper, SE DAC for the subs and a higher quality balanced one for the mains). There might not be a "one solution fits all" solution?

Somewhat related: I followed the link in your signature to your TAS3251 thread where I saw you mention an STM32-based USB-in, I2S out board. That could be exactly what I've been looking for! I even tried my own version based on a BBB which I guess I have de-facto given up on by now. A Nucleo based solution would be much neater! No boot-up/shutdown, up to five I2S outputs, and built-in FPU for some DSP makes those boards a very nice find indeed!

Do you have a project thread on that board somewhere? Some further searching led me to this code repo. Is that your code for that board, and is it up to date?

I was almost ready to throw money at the problem, but I like your STM32 solution a lot better!

 

[jmf11]

Hello,

Yes, this is my repo. The code was fine 7 years ago, and allowed me to drive my LX-Minis, doing the DSP and controlling 2x stereo channels. From what I have seen, ST released posssibly a new library that addresses "natively" Async USB.

I had the false understanding that USB UAC1 was limited to stereo. In fact, from an XMOS paper, it seems that you can with Full Speed USB and UAC1 deal with up to 8 channels (4x stereo channels) at 44.1/48kHz. This could be sufficient for many projects... and supported by nucleo boards.

To clarify my above thread, the idea is to do DSP in CamillaDSP (or EqualizerAPO on Windows).

Performance: the target would be something similar to https://motu.com/en-us/products/gen5/ultralite-mk5/ (about 700€) but in a simplified package (no UI, only USB in => multi balanced out). Not top SINAD, but OK for 99.9% usage.

The Single Board Computer <=> DAC combo did not ring many bells (I also checked here https://www.diyaudio.com/community/...lification-multi-channel.399355/#post-7353660). USB in is much favoured.

Also there seems to be some stm32 code for UAC2: https://www.diyaudio.com/community/...ition-difficulties.399260/page-2#post-7349910. So one possibilily would be to fit a correctly implemented AK4458 or ES9026PRO as nucleo HAT, or dedicated board stm32+DAC board.

But this does not raises sufficient interest to spend a lot of time on...

JMF

 

[arvidb]

I'm thinking that for projects such as these, the driving force should be self-need, mostly. Of course it's a great bonus if others find it useful too! But if you do it mostly for others then there's a high risk of disappointment, I guess.

I cloned your code and I also found this guy doing something similar:

So that's a good start! Thanks! (For the idea and for the code!) If I get anywhere I'll report back here!

 

[voodooless]

Would it not be simpler to just get an Xmos and create a budget-minded USB DAC? This would make the applicability much wider and probably much simpler to implement.

 

[jmf11]

Would it not be simpler to just get an Xmos and create a budget-minded USB DAC? This would make the applicability much wider and probably much simpler to implement.

Yes, an idea would be a budget-minded multi-channel USB DAC, but based on a stm32 for the USB to I2S part. The Xmos is maybe more "polished" but out or reach of most hobbyists (at least from what I understand). Stm32 has all the hardware features, but mutli-channel software is not off the shelf.

JMF

 

[voodooless]

Yes, an idea would be a budget-minded multi-channel USB DAC, but based on a stm32 for the USB to I2S part. The Xmos is maybe more "polished" but out or reach of most hobbyists (at least from what I understand). Stm32 has all the hardware features, but mutli-channel software is not off the shelf.

Okay, got it. Nice idea to find a more approachable uC.

Maybe this will help:

GitHub - hathach/tinyusb: An open source cross-platform USB stack for embedded system

An open source cross-platform USB stack for embedded system - hathach/tinyusb

github.com

It seems to have UAC2 support already and supports a host of other uCs as well.

 

[MCH]

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...

1 or 2 years ago i would be very interested on this. I have since found a good deal for a motu ultralite and i am settled for many years, hopefully.

What i think could be something very neat to diy is a USB (or is2, tdm whatever) to multiple spdif outputs. Something like the minidsp udio-8. My reasons are the following:
- the udio 8 costs 425 eur where I live and is difficult to find used. The mch streamer 215eur and you don't even get a box, and the rme alternative is even more expensive.
- most people already own a stereo DAC. With such a device and a second cheap DAC for the subs or a third for 5.1, you are done, without having to get rid of what you already have
- the diy project stays in the digital domain, that seems more feasible for the non expert diyer and potentially cheaper or even very cheap if a microcontroller could do the job.

On the other hand, there are USB multichannel interfaces or soundcards that are relatively cheap nowadays, so one wonders what is the point...

Anyways, even without having a use for it, i would consider building such a usb->multiple spdif myself only for self satisfaction and learning, if the software part was available and the cost stay reasonably low.

Hope it helps.

 

[jmf11]

1 or 2 years ago i would be very interested on this. I have since found a good deal for a motu ultralite and i am settled for many years, hopefully.

What i think could be something very neat to diy is a USB (or is2, tdm whatever) to multiple spdif outputs. Something like the minidsp udio-8. My reasons are the following:
- the udio 8 costs 425 eur where I live and is difficult to find used. The mch streamer 215eur and you don't even get a box, and the rme alternative is even more expensive.
- most people already own a stereo DAC. With such a device and a second cheap DAC for the subs or a third for 5.1, you are done, without having to get rid of what you already have
- the diy project stays in the digital domain, that seems more feasible for the non expert diyer and potentially cheaper or even very cheap if a microcontroller could do the job.

On the other hand, there are USB multichannel interfaces or soundcards that are relatively cheap nowadays, so one wonders what is the point...

Anyways, even without having a use for it, i would consider building such a usb->multiple spdif myself only for self satisfaction and learning, if the software part was available and the cost stay reasonably low.

Hope it helps.

This would be a nice "first step"

For several years, I've driven my LXmini with a nucleo board, with USB input and with 2xSPDIF, arranged with simple resistor divider and cap. They were connected to a FX-Audio D802. The only difference was that it was stereo USB in, with multiple SPDIF. Next step would be Multi channel USB in => 4xSPDIF or 4xI2S (the stm32 can do both).

One limiting factor, is I don't see many Nucleo boards with used High Speed USB (most are only Full Speed USB).

 

[MCH]

Hi guys,

Came across this and thought of this thread. This is probably old news, but just in case someone finds it interesting

This is the comtrue CT7601 eval board:

It looks like it has 4x2 channel i2s with common LRCL and SCLK.

There is a driver that you can download, but might be not necessary:

google translate:

Don't know, i am probably missing something important, but it seems a feasible solution, doesn't it? (not for a noob like me though)

source:

https://www.comtrue-inc.com/index.php/download2/category/4-ct7601

 

[jmf11]

Seems that my new set up will need such USB to multi I2S. I will do some experiments with a stm32F4 discovery board, UAC 1.0 48kHz 16bits.

Expect slow progress

 

[arvidb]

Seems that my new set up will need such USB to multi I2S. I will do some experiments with a stm32F4 discovery board, UAC 1.0 48kHz 16bits.

I'm also looking at this at the moment. I've just started looking at the USB part, using a Nucleo-F411RE board. Like you, I will only be able to look at this very sporadically. Slow progress...

The biggest issue with STM's code IMO is the horrible license that explicitly forbids usage in any kind of open source software: "No use, reproduction or redistribution of this software partially or totally may be done in any manner that would subject this software to any Open Source Terms. “Open Source Terms” shall mean any open source license which requires as part of distribution of software that the source code of such software is distributed therewith or otherwise made available, or open source license that substantially complies with the Open Source definition specified at www.opensource.org and any other comparable open source license such as for example GNU General Public License (GPL), Eclipse Public License (EPL), Apache Software License, BSD license or MIT license."

TinyUSB, as linked by voodooless above, on the other hand is distributed under a very permissive MIT license. So while I started looking at the STM code, I will see if I can use tinyUSB instead.


What I did see while looking at the STM code is that they don't seem to implement asynchronous synch at all? (Although they claim to do so in the head of usbd_audio.c.) There are skeleton callbacks meant to be used by the I2S DMA engine (HalfTransfer_CallBack_FS(), TransferComplete_CallBack_FS()) in the auto-generated USB_DEVICE/App/usbd_audio_if.c file that calls the USBD_AUDIO_Sync() function in usbd_audio.c. This function in turn calls AUDIO_AudioCmd_FS(), again in usbd_audio_if.c, with a size parameter adjusted depending on the margins of the USB receive buffer. Leaving it entirely up to the user's implementation to adapt the consumption of data to whetever rate the host computer is transmitting at. This would correspond to the "Adaptive" synchronization as described in the USB UAC1 standard, then. I haven't seen anything related to Asynchronous synchronization?

This is using the current CubeMX v1.12.

 

[jmf11]

@arvidb : thanks to point to the license issue. This was not on my radar, and this is unfortunate. I'm not a license specialist, and I don't know if there is a work around to use the stm32 middleware core in open source projects. Would there be a license that would allow to build projects available to the community, based on ST USB stack without violation of:
5. No use, reproduction or redistribution of this software partially or totally may be done in any manner that would subject this software to any Open Source Terms. “Open Source Terms” shall mean any open source license which requires as part of distribution of software that the source code of such software is distributed therewith or otherwise made available, or open source license that substantially complies with the Open Source definition specified at www.opensource.org and any other comparable open source license such as for example GNU General Public License (GPL), Eclipse Public License (EPL), Apache Software License, BSD license or MIT license. ?

from: https://www.st.com/content/ccc/reso...4.txt/jcr:content/translations/en.SLA0044.txt

The HAL layer is 3-clause BSD license. There are proprietary licenses for fex components (including the USB stack ; ex for H7 https://www.st.com/content/ccc/reso.../en.Additional_License_Terms_STM32CubeH7.html)

 

[arvidb]

I am not a lawyer or a license specialist either.

To my mind, the clause in question really only says "you are not allowed to relicense this code under any other, more permissive license" - the key part being "subject this software". But that goes without saying already, so why did they add the clause? To remind us not to link against GPL-licensed code? Perhaps, but why then the very broad mention of open source licenses in general, including "non-viral" ones?

I'm guessing the clause is meant to spread fear, uncertainty, and doubt regarding the usage of the code in open source projects. STM probably prefers large customers that develop closed source products and then buys large quantities of their MCUs.

Given that, as you say, the HAL and BSP code is 3-clause BSD licensed, STM must have deemed it acceptable to link the USB middleware against such code, so that license might be safe to use also for your own code? That's probably my plan B, if tinyUSB won't work for some reason. But it would be annoying to then find e.g. a DSP/IIR library that I want to use that's GPL licensed... Also I would like the freedom to choose GPL for my own code too.

 

[JohanAR]

Sounds kind of similar to the stuff people created with FreeDSP. Personally I would love a FreeDSP Aurora, but it seems like they stopped making them a couple of years ago. Currently on the hunt for a moderately priced USB 8 channel DAC with DSP (for a Linux computer ofc).

Regarding the license it's a bit strangely worded, but IMO "any manner that would subject this software to any Open Source Terms" definitely sounds like "you're not allowed to re-license our code".

 

[jmf11]

Regarding the license it's a bit strangely worded, but IMO "any manner that would subject this software to any Open Source Terms" definitely sounds like "you're not allowed to re-license our code".

Would this mean in layman's terms, that the code is freely available for use in our hobby activities, and that we can build projects on it, as long as the ST USB code is used from their development environment, ie:

• I can license my code that I develop above the ST USB stack as Open Source (I can put on GitHub and share freely),
• I can't fork their code and embed in my code,
• Others will need to get the ST USB stack from ST directly, and then recompile,
• I'm however free to ditribute exe (compiled) code based on my code and the ST USB stack

Is this understanding correct ?

By the way, some projects piled ahaead of this project form me. I just bought Neumann KH80 and a SVS subwoofer. As of today, the subwoofer is doing the filtering but later I would like to go multichannel USB. 1) build speaker stands 2) tune the system with REW 3) finish some PhiDaCs I have since years (https://hackaday.io/project/27001-audiophile-sounding-dac-for-almost-no-money and DIYaudio) 4) build the multi USB2I2S interface....

 

[somebodyelse]

The Aurora (and some of the other related FreeDSP designs) used AKM ADCs and DACs which became unobtainable after their fire. I haven't checked back recently to see if the new AKM parts have helped the situation. I had hoped Topping's DM7 would be more moderately priced, but it's close to the Ultralite Mk5.

 

[JohanAR]

Would this mean in layman's terms, that the code is freely available for use in our hobby activities, and that we can build projects on it, as long as the ST USB code is used from their development environment, ie:

• I can license my code that I develop above the ST USB stack as Open Source (I can put on GitHub and share freely),
• I can't fork their code and embed in my code,
• Others will need to get the ST USB stack from ST directly, and then recompile,
• I'm however free to ditribute exe (compiled) code based on my code and the ST USB stack

Is this understanding correct ?

By the way, some projects piled ahaead of this project form me. I just bought Neumann KH80 and a SVS subwoofer. As of today, the subwoofer is doing the filtering but later I would like to go multichannel USB. 1) build speaker stands 2) tune the system with REW 3) finish some PhiDaCs I have since years (https://hackaday.io/project/27001-audiophile-sounding-dac-for-almost-no-money and DIYaudio) 4) build the multi USB2I2S interface....

I'm only trying to interpret the text as a layman, so I promise nothing My guess is that it's ok if your open source project has a third_party folder and you place the ST USB code there in its own folder there together with its license. If you want to be extra clear you can place a README.md in the third_party folder, where you explicitly state that these are third party libraries which have their own licenses and are not subject to whatever license your main project has. If you're *really* paranoid you can have your build script download the ST USB code, so that it is not distributed together with your main project code at all.

@somebodyelse I think the factory has been back in action for quite some time, and the required components are available from Digikey.

 

[arvidb]

Would this mean in layman's terms, that the code is freely available for use in our hobby activities, and that we can build projects on it, as long as the ST USB code is used from their development environment, ie:

• I can license my code that I develop above the ST USB stack as Open Source (I can put on GitHub and share freely),
• I can't fork their code and embed in my code,
• Others will need to get the ST USB stack from ST directly, and then recompile,
• I'm however free to ditribute exe (compiled) code based on my code and the ST USB stack

Is this understanding correct ?

Not quite. Depending on the open source license you use for your own code (and used by any other library you choose to include) you might not be allowed to distribute the executable. Specifically (but maybe not uniquely) you can not use any GPL code together with the ST USB code if you want to distribute the executable.

The GPL license requires you to make the complete source available - under the GPL license! - to anyone to whom you make the compiled code available, and that includes all linked code. So that would conflict with the ST USB license. It doesn't matter if you embed their code on Github or not - it's what's linked into the executable that matters.

You use the GPL license if you want to prevent others from "misusing" your code in projects that aren't fully open source. The MIT, BSD-3 etcetera are more permissive. Here's a list with comments on the different licenses: https://www.gnu.org/licenses/license-list.html

 

[JohanAR]

Not quite. Depending on the open source license you use for your own code (and used by any other library you choose to include) you might not be allowed to distribute the executable. Specifically (but maybe not uniquely) you can not use any GPL code together with the ST USB code if you want to distribute the executable.

The GPL license requires you to make the complete source available - under the GPL license! - to anyone to whom you make the compiled code available, and that includes all linked code. So that would conflict with the ST USB license. It doesn't matter if you embed their code on Github or not - it's what's linked into the executable that matter.

You use the GPL license if you want to prevent others from "misusing" your code in projects that aren't fully open source. The MIT, BSD-3 etcetera are more permissive. Here's a list with comments on the different licenses: https://www.gnu.org/licenses/license-list.html

Right, I forgot about GPL, I was thinking more about MIT and CC licenses. Good catch