New low-cost DSP platform in development

[bachatero]

One more page for now:

 

[EJ3]

Alt version of the login screen:

View attachment 412469

I like this look better but I am not always a part the majority when it comes to things like this.

 

[Tell]

Of course, because otherwise anybody could just mess with it if it's on a shared network.

Here is a mockup of the home screen:

View attachment 412468

Any thoughts on it?

Ah so it is going to be node based, nice
Though personally I prefer having it horizontal since my screen is horizontal.

 

[phofman]

Looking at the https://milkv.io/duo-s - I could not find any I2S for multichannel audio HW I/O, any USB-device HW for a USB DSP box.

For comparison - Radxa Pi-S bare 256MB RAM (usable for a custom linux build) costs 16USD, 512MB RAM with Wifi/BT + 4GB NAND (512MB usable for standard debian apt with no memory swap) costs 30USD - 4 A53 cores clockable at 1.3GHz, independent USB-device and USB-host ports (ideal for USB DSP), 8 I/O 384kHz I2S channels on the pinheader (extra optionally synchronous 8 I/O I2S channels when using Pi-S core board - 512MB + Wifi/BT for 20USD), powered through the USB-gadget port. Runs 10 -> 16 I2S channels (max. combination available) CamillaDSP OK.

 

[bachatero]

Looking at the https://milkv.io/duo-s - I could not find any I2S for multichannel audio HW I/O, any USB-device HW for a USB DSP box.

This is actually the biggest problem with the Duo S, it looks like multichannel might be "womp womp" but there is in fact a USB port driven by its single USB controller. I'm hoping that once this initial model gets off the ground, I can make a "plus" version with a better SoC and multichannel support.

 

[phofman]

but there is in fact a USB port driven by its single USB controller.

USB host port is quite common. However IMO a DSP device should have a USB device port (as handled by linux usb gadget drivers) , so that it can be easily connected to any USB host providing the data for DSP.

 

[bachatero]

I see what you mean, but it's possible to have that and a host port in this case by connecting a USB -> I2S chip and simply using that as the "device" that your host sees. That would unfortunately take up a full I2S slot of which there are only 2, so the input would need to be switchable to support both optical and USB in while retaining an I2S output.

 

[bachatero]

How about this?

Inputs:
- stereo analog in (through built in ADC)
- switchable stereo optical/USB in

Outputs:
- stereo analog out (through built in DAC)
- stereo optical and analog out (duplicated)

This setup is basically pushing the Duo S to the limit but is still better than miniDSP's cheapest option!

 

[olieb]

This setup is basically pushing the Duo S to the limit but is still better than miniDSP's cheapest option!

Why would that be better?
Cheaper yes, but so is a Tinysine (20-40$). Only missing digital out, but not so much because of price, but probably because of little customer interest.

 

[bachatero]

Why would that be better?
Cheaper yes, but so is a Tinysine (20-40$). Only missing digital out, but not so much because of price, but probably because of little customer interest.

You still have to use that total rat clown SigmaStudio piece of garbaj which is a total nonstarter for people like me who hate fussy proprietary Windows-only junk, AND you still need to make a case to hold it in!

 

[olieb]

You still have to use that rat clown SigmaStudio software which is a total nonstarter for people like me who hate fussy proprietary Windows-only junk, AND you still need to make a case.

Well the case is necessary anyway and about the price of a finished product, we will see. The tiny sine is already there and it is already low cost. MiniDSP is not the reference.
Sigma Studio IS rather painful, I agree, but it has the advantage of existing, where so far I only saw a login screen with comments on font choice. Again, we will see how a finished software, that can do all sorts of things ("any DSP effect I want"), will look like and when. All I needed for Sigma Studio (I used it yesterday for the first time) was a working template, which I modified to my needs.

 

[TunaBug]

I think you should build what you find useful for yourself. Then announce it. Then figure out what additional things to add to satisfy other people. Otherwise you risk spinning your wheels analyzing everybody's requests.

But as long as what you're listening to what other people are interested in
* I would like for it to be a "filter" ala a Unix command line utility in a pipe. Neither side need be aware.
* USB

That means:
* USB device port. Call this "IN". The computer, or whatever currently drives my DAC, plugs in here. A USB-B receptacle (assuming you're not doing USB-C).
* USB host port. Call this "OUT". This has another USB cable to the DAC. A USB-A receptacle (assuming you're not doing USB-C).
* The USB device exposed on IN should look almost exactly like the DAC. To wit, any requests that are not audio to be played should be forwarded to the OUT, and responses returned back to IN. For example, if the host (connected to IN) tries to adjust volume, or balance, or update the settings on my DAC, then that should continue to Just Work. Or, when the host connected to IN is querying the capabilities of what it thinks is a DAC, then it should be talking to the DAC, through you.

Note: that overall idea, a filter, has nothing really to do with USB (although the implementation does). E.g. if you want to have AES IN and AES OUT then any non-PCM audio commands sent over the AES cable would be forwarded the same way.

That also implies that you are NOT a converter between interfaces, otherwise you would need to be jumping down the rabbit hole of understanding and converting entire command sets, and not just filtering PCM samples.

 

[phofman]

I see what you mean, but it's possible to have that and a host port in this case by connecting a USB -> I2S chip and simply using that as the "device" that your host sees. That would unfortunately take up a full I2S slot of which there are only 2, so the input would need to be switchable to support both optical and USB in while retaining an I2S output.

Or using a single SoC with all the features inside, controlled by the linux kernel - that's what I would call a simple low cost Such SoCs have been commonly available for a number of years. Personally I have no problem with ARM, thus no problem with such very inexpensive SoCs.

 

[phofman]

How about this?

Inputs:
- stereo analog in (through built in ADC)
- switchable stereo optical/USB in

Outputs:
- stereo analog out (through built in DAC)
- stereo optical and analog out (duplicated)

Building a new DSP from scratch with only two output channels seems a bit limited to me, to be honest.

 

[phofman]

The USB device exposed on IN should look almost exactly like the DAC. To wit, any requests that are not audio to be played should be forwarded to the OUT, and responses returned back to IN. For example, if the host (connected to IN) tries to adjust volume, or balance, or update the settings on my DAC, then that should continue to Just Work. Or, when the host connected to IN is querying the capabilities of what it thinks is a DAC, then it should be talking to the DAC, through you.

I have been thinking about such a USB audio filter for a while. Mirrorring controls of any DAC is actually quite non-trivial. Often these devices do not follow the UAC2 standard (which is in some parts not strictly defined) and quirks in the driver are required for the specific device (as easily seen in the linux uac driver). Then there are non-uac2 functions of the DACs, like special modes for firmware upload - that is very difficult to make universal. But just passing standard features like volume should be quite viable. Although the question is why the DAC should handle volume better than the DSP itself when vast majority of the DACs use digital volume anyway...

Nevertheless the first step in implementation in linux is adding multiple alternate settings to the UAC2 gadget, which still has a long way to go to the mainline https://patchwork.kernel.org/project/linux-usb/list/?series=893626&state=*

 

[bachatero]

Check out this datasheet for a potential USB input candidate:

https://www.ti.com/lit/ds/symlink/pcm2706.pdf?ts=1733936324159

 

[bachatero]

Or using a single SoC with all the features inside, controlled by the linux kernel - that's what I would call a simple low cost Such SoCs have been commonly available for a number of years. Personally I have no problem with ARM, thus no problem with such very inexpensive SoCs.

Check this one out: https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3 It's a lot more expensive though.

 

[phofman]

Check out this datasheet for a potential USB input candidate:

https://www.ti.com/lit/ds/symlink/pcm2706.pdf?ts=1733936324159

Yes, there are a number of options for a standalone USB UAC2 -> I2S receiver - these ancient 16bit ones, STM32 projects discussed on diyaudio.com, XMOS/Savitec/ComTrue/CMedia chips, etc. etc. But they add HW cost and complexity to a presumably low-cost DSP. Also, if they are to be part of some DSP bridge, their USB configuration/features reported to the USB host must be fully under control of the DSP controller which is either impossible or very complicated with these standalone chips, unlike a linux kernel module.

Check this one out: https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3 It's a lot more expensive though.

Yes, that's a full-blown SoC with RISC-V instead of ARM, why not. Honestly I personally do not see any advantage of limiting the options to RISC-V when these peripherals for a real-world audio DSP are necessary and comparably-equipped ARM SoCs are easier to source, cheaper, and very likely better supported in linux. But that's just my view.

 

[TunaBug]

I have been thinking about such a USB audio filter for a while. Mirrorring controls of any DAC is actually quite non-trivial. Often these devices do not follow the UAC2 standard (which is in some parts not strictly defined) and quirks in the driver are required for the specific device (as easily seen in the linux uac driver). Then there are non-uac2 functions of the DACs, like special modes for firmware upload - that is very difficult to make universal. But just passing standard features like volume should be quite viable. Although the question is why the DAC should handle volume better than the DSP itself when vast majority of the DACs use digital volume anyway...

Nevertheless the first step in implementation in linux is adding multiple alternate settings to the UAC2 gadget, which still has a long way to go to the mainline https://patchwork.kernel.org/project/linux-usb/list/?series=893626&state=*

Re where volume is handled: perhaps that's a suboptimal example on my part, as yeah, why couldn't the DSP do volume control. But volume control isn't the point: it's stay out of the way and pass things you cannot do. Let's say I want to send a command to change the color of the display on the DAC. The filter shouldn't know these things, instead just pass them along silently.

But I'm not familiar with the USB linux architecture. It might make things harder than I am imagining. Nevertheless, that's what I want

 

[phofman]

Let's say I want to send a command to change the color of the display on the DAC. The filter shouldn't know these things, instead just pass them along silently.

It's a very logical expectation. Yet AFAIK no such device, even just a simple USB DSP filter with configurable input samplerates and channel combinations, is on the market. Far from passing proprietary protocols further downstream I can imagine the DSP getting in way of the UAC2 protocol/function and just passing all the other functions (HID, mass storage, etc.).

Kernel has raw usb-gadget https://github.com/xairy/raw-gadget for which usb-proxy projects exist https://github.com/AristoChen/usb-proxy https://github.com/patryk4815/usb-proxy . I have never played with this stack, but I am not sure it's possible to combine the specific kernel handler for UAC2 function and the raw usb gadget handler for all the other functions, and the same on the host side (i.e. user-space libusb for the raw access combined with kernel UAC2 driver). These things are rather complex.

There is another question - a DSP often has different number of channels on input and output. E.g. a USB DSP would take 2 channels in and output 2x3 channels out (xover). Now if the original proprietary driver is to be used (to send the color command), it's designed for the original device and likely supports only its parameters. If the DSP starts reporting 2 channels instead of 6, the proprietary driver may be confused, or even crash the host OS. The DSP can keep all the params identical, but then it may miss quite some useful features (like offering only 2 channels input and doing xover internally to 6 channels).

I am afraid this IMO very interesting discussion gets rather off-topic to this thread.