New low-cost DSP platform in development

[TSB]

1. How will the project be structured?
2. Do you plan to take outside help?
3. What inputs and outputs do you plan to support?
4. What formats do you plan to support?
5. Will the hardware design be open as well?
6. What software license do you plan to use?

 

[voodooless]

Stuck in dev and never completly finished.

Well, basically the AKM fire killed the project.

 

[MarsianC#]

Yeah that was quite unfortunate.
Still, software dev is a problem when no community is able to help/support.

 

[somebodyelse]

Digital in, digital out, with DSP in the middle, at much lower cost than the wiim mini, with config via a browser sounds great. But that sounds like a big ask, good luck.

Like camillaDSP with toslink in/out if using a Pi Zero 2 W?
Edit: I think we have tutorials for USB in/out on an Pi 4 too.

 

[LionIT]

Can I suggest a Toslink in/out interface?
In my opinion there are several use cases where it is convenient to simply add a pure DSP on an existing system, without having to go from analog to digital and vice versa.
Many already have an excellent performance DAC and just need a processor in the digital domain, without having to resort to a PC or Mac, or other expensive hardware.
For example, I would find such a DSP convenient to put between the streamer and the DAC. Or even between the TV and the soundbar.

I forgot one thing...
It would be essential to have the automatic switching of the DSP sample rate, according to the input signal.
Otherwise having to set it every time it changes is very very uncomfortable.

 

[JeffS7444]

Sounds awesome, particularly if high level of performance is possible. Hopefully the hardware will remain readily available.

I am aware of inexpensive DSP offerings from Wondom and Nvarcher, and have just ordered one of the latter.

 

[bachatero]

1. How will the project be structured?
2. Do you plan to take outside help?
3. What inputs and outputs do you plan to support?
4. What formats do you plan to support?
5. Will the hardware design be open as well?
6. What software license do you plan to use?

1. Library, supporting software, complete product
2. If you know C++, I'll accept anything but so far I can't find anybody who does
3. This could be anything, but I do know I want a barebones option with just a single stereo in/out and another with a single digital in/out
4. This could be anything too, but special codecs like DTS/Dolby are closed source so unless we make an open source equivalent, forget about those
5. Probably
6. Already licensed under MPL (Mozilla Public License)

 

[somebodyelse]

4. This could be anything too, but special codecs like DTS/Dolby are closed source so unless we make an open source equivalent, forget about those

A lot are already covered by ffmpeg. Cavern decodes a subset of Atmos, but that's .NET not C++

 

[bachatero]

A lot are already covered by ffmpeg. Cavern decodes a subset of Atmos, but that's .NET not C++

Might be irrelevant anyway, since this DSP platform won't be running either (at least not for the pure DSP stuff) but it is good to know that open source implementations exist

 

[voodooless]

Might be irrelevant anyway, since this DSP platform won't be running either (at least not for the pure DSP stuff) but it is good to know that open source implementations exist

These SOCs don’t have any dedicated DSP hardware, do they? The work needs to be done using the CPU? Does RISC-V offer any DSP libraries for efficient execution, like ARM cores with CMSYS? You could of course offload the DSP’ing to the ARM core, at 1Ghz it should be capable of plenty as well.

 

[bachatero]

Does RISC-V offer any DSP libraries for efficient execution, like ARM cores with CMSYS?

Nope, unless you count https://blog.segger.com/emvdsp-vs-cmsis-dsp/, which isn't free nor open source

You could of course offload the DSP’ing to the ARM core

Nope, since that would basically defeat the purpose of RISC-V which is to replace x86 and ARM as they are rapidly becoming legacy technology

 

[voodooless]

RISC-V which is to replace x86 and ARM as they are rapidly becoming legacy technology

I very much doubt that.

The fact that there is no standardized DSP library right now should tell you a lot about the early state this architecture is in. Don’t get me wrong, I think there are great things to come, but it’s not going to be very rapid.

 

[bachatero]

I don't know if you know just how fast RISC-V is coming to eat x86/ARM's lunch. 10 years ago, RISC-V didn't even exist outside of a lab. A few years ago, the fastest system available about as fast as the original iPhone. A year ago, a 64 core monster came out and I'm using one of those RIGHT NOW for a Linux build farm. In less than 60 days, Qualcomm's ARM license will be canceled in an effort to extract more revenue before ARM goes bust. In a few months, Android smartwatches will be using RISC-V, and you'll be able to get a PC board with performance comparable to x86 hardware, and you'll be able to get 128 core servers. And in a little bit, the cheapest and most flexible audio DSP platform will be using RISC-V.

 

[unpluggged]

RISC-V which is to replace x86 and ARM as they are rapidly becoming legacy technology

RISC-V is just another instruction set, not a magic wand.

 

[voodooless]

Yes, it’s going much faster than the legacy technologies ever did. But that’s just a things of the times. Technology is way more accessible than it was ever before. No doubt RISC V has a great future. But there is still a long road to go.

And in a little bit, the cheapest and most flexible audio DSP platform will be using RISC-V.

Why would they? Dedicated DSP cores are way more efficient and can be made with fewer transistors. For the cheapest stuff, that would be the way to go. So I’m talking about audio stuff where a simple DSP needs to be added, like digital input class D amps, simple EQ/filter chips, etc.

One you scale up, the story changes. DSP chips aren’t made at super large quantities, so while still more efficient, they can end up being more expensive anyway. So for the things that you plan on using your board, and consequently the things that most members here would be interested in, these kind of boards are definitely will cannibalize the market, and bring new products.

But the same can be said for ARM chips. Your board contains both types of cores, and still manages to be super low cost. It even contains another CPU core: a 8051 (which is effectively royalty free)

Anyway, for such boards significant cost goes into the codecs, as well as the development of the software stacks. It’s just orders of magnitude more complex than a simple DAC board.

And specific to audio processing, these RISC-V cores do not contain the V1.0 version of vector instructions that are very much preferred for audio processing. Compared to the ARM cores NEON instructions, they are not quite at the same level. So it could very well be that that ARM core will be faster and more efficient at processing audio. And it will be simpler to implement.

None of this should mean you should stop your project. Because the early bird catches the worm

For a next iteration maybe look for a SOC with RVV 1.0 support, and be prepared for some assembly instruction optimizations …. Or just wing it and hope the 1Ghz is enough for some inefficient DSP’ing. For sure it will run plenty of stuff before optimizations are needed.

 

[bachatero]

And specific to audio processing, these RISC-V cores do not contain the V1.0 version of vector instructions that are very much preferred for audio processing.

This is technically true, but after checking out what exactly the SG2000 offers it's not all bad news either. The "main" C906 RISC-V core actually DOES have vector support, just the draft 0.7.1 version that's common among other Chinese chips using the C906/C910 cores. This was unsupported by GCC for the last few versions but GCC 14 has support for it again, but for my DSP project that's irrelevant. 0.7.1 itself is nearly identical to 1.0 just with a couple minor assembly differences. However, the "minor" C906 core not only lacks that vector support but also a lot of the cache present in the "main" one, plus a clock speed that's a third slower.

So, as long as I can write the code to take advantage of the 0.7.1 vector capability, then we're still all set for speedy audio processing, so as long as we do it all in Linux. That could be a problem if the webserver and compiler/assembler have to run on the same core. So, to fix that, we'd need to offload those functions to FreeRTOS on the little C906, which might not actually be so bad because those ironically don't require realtime operation.

 

[voodooless]

0.7.1 itself is nearly identical to 1.0 just with a couple minor assembly differences

The lack of VLA (vector length agnosticism) isn’t exactly minor.

 

[bachatero]

Basically irrelevant when it comes to performance: https://arxiv.org/pdf/2304.10324 "Across most of the benchmark kernels Clang VLA (vector length agnostic) and VLS (vector length specific) settings provide very similar performance, exept for specific kernels such as ATAX, FDTD 2D and GEMVER."

 

[voodooless]

Basically irrelevant when it comes to performance: https://arxiv.org/pdf/2304.10324 "Across most of the benchmark kernels Clang VLA (vector length agnostic) and VLS (vector length specific) settings provide very similar performance, exept for specific kernels such as ATAX, FDTD 2D and GEMVER."

It's not so much about performance but ease of development and portability. You're going to develop assembly code for an instruction set that was obsolete before there even was real hardware I would, therefore, recommend a platform that uses the now out-of-draft RVV 1.0 spec. If you rely on the compiler, it's not such a big deal (although both GCC and Clang do not offer proper and full compatibility with RVV 0.7.1, and even threw it out of their main branch), but when handcrafting assembly, it is. They are not binary compatible. Using tools like those described in the paper you linked to convert RVV 1.0 assembly to 0.7.1 seems like an unnecessarily complex solution. On the other hand, it might be a way to start development using RVV 1.0 assembly and just have it run on an older spec CPU anyway. It will be tricky to optimize this properly, probably because of the translation layer, but that may be something to worry about later on. At least you'll have something that will work on RVV 1.0 spec CPUs from day 1 So, if not choosing an RVV 1.0 spec CPU, this is probably the next best thing for now.

Anyway, what's the status of the project right now? Any idea on what the software architecture should look like? A flexible, configurable, and fast-processing kernel would probably be the main starting point.

 

[KSTR]

In my limited experience as a DSP implementer my take is what's really needed is fast 64bit (or wider) floating point, notably trigonometrics and of course you typical multiply and add. At work we rely much on SIMD but currently only with 32bit floats which is really somewhat limiting.