• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

New low-cost DSP platform in development

Progress update! I have now tested all the candidate DACs, the PCM5102, UDA1334, and CS4344, for their basic SINAD performance. And fortunately for us, none of them are horrible except for possibly the CS4344. It looks like the PCM5102 might be a real winner for our analog output!

IMG_20241218_201315167.jpg


Screenshot_20241218-195559-999.png
Screenshot_20241218-200309-773.png

Screenshot_20241218-201011-173.png
 
Consider Github, I like most function it offers. Good for tracking issues/requests too.

#team aes/ebu in/out :D
#useable DAC on board

PS: What SINAD they got? Graphs are with fundamental at -16 dB and noise is importand too.
 
Is there a project tracker/website/blog we can follow the progress from?
Consider Github, I like most function it offers. Good for tracking issues/requests too.
Oh I already have a Github repo and several others including one with 5K stars, I just don't feel this one is presentable enough yet (but will be soon!)
#team aes/ebu in/out :D
#useable DAC on board
Does TOSLINK count? Because that would likely be what's available
PS: What SINAD they got? Graphs are with fundamental at -16 dB and noise is importand too.
I'm not sure, so let's calculate it manually for the PCM5102. We have the 1st harmonic at -120dB but since the fundamental is -16dB, it's really at -104dB. Then, we have the second harmonic at -102dB. The coefficients of distortion for those are 10^(-104/20) = 0.00000631 and 10^(-102/20) = 0.00000794 respectively, and added together they're 0.00001425. That equals 20log(0.00001425) = -97dB THD. However, our distortion is not just the 1st and 2nd harmonics, so let's subtract 4dB as an approximation. That would give us about 93 SINAD, which happens to be exactly what the PCM5102 datasheet says is typical!
 
Last edited:
TI is recommending TAD5242 instead, that costs the same and seems to perform a bit better.
 
TI is recommending TAD5242 instead, that costs the same and seems to perform a bit better.
I can't actually order them anywhere so that's not an option. However, you CAN get the PCM1794 which offers much better performance than even the TAD5242, but it requires some extra supporting characters (opamps) to use. I have a couple of them plus the opamps so I'll have to try those out sometime.
 
I can't actually order them anywhere so that's not an option.
TI sells directly, not to where you are? to my country 13 euros shipping that is very reasonable if you factor in the huge price difference with digikey and mouser in many items.
 
It turns out they are out of stock on the TI website, but on Mouser, it looks like they have thousands. For some reason, I only saw the EVM board in a search.
 
Performance update! I have spent tons of time optimizing the assembler and it now crushes GCC's version in performance: a 4K instruction file gets converted to machine code 3.5x faster and a 16K one 2x faster, all while being half the size.
 
Please what is the purpose of focusing on fast conversion of assembler into RISC-V instructions for the DSP project?
 
Please what is the purpose of focusing on fast conversion of assembler into RISC-V instructions for the DSP project?
Every DSP effect program will convert to RISC-V assembly, and then the assembler will convert that to machine code. Making this conversion fast lets us hedge against situations where there aren't many resources available or if there is a huge amount of code to process. For example, one such situation could be if you imported a set of effects with a huge amount of code while there's already other effects running. Another would be if you changed an effect while the CPU load is almost at 100%. Yet another is if you wanted to use this assembler elsewhere because it's good not just for this project but also as a replacement for the typical ones from GCC/LLVM.
 
Why not converting the effect to the machine code in advance (i.e. the compilation time is not critical) and store it locally? What's is the reason for converting the effect on-the-fly when loading to the CPU, IIUC?

I am not sure many users would be willing to use assembler for the effects. CamillaDSP has a very simple configuration format, yet quite a few users can only click in CDSP GUI and cannot even copy/paste the config to their posts here, instead taking screenshots of the GUI in the browser.

Also many effects are quite complex and using assembly for their preparation is rather unlikely, IMO.
 
I think the confusing thing on this thread is that there is little word about DSP functionality. Pros and cons of RISC-V, check. Different DAC options, check. 3-D printers for cases, check. Assembler optimization, check. But how about DSP working?
 
Last edited:
Why not converting the effect to the machine code in advance (i.e. the compilation time is not critical) and store it locally? What's is the reason for converting the effect on-the-fly when loading to the CPU, IIUC?

I am not sure many users would be willing to use assembler for the effects. CamillaDSP has a very simple configuration format, yet quite a few users can only click in CDSP GUI and cannot even copy/paste the config to their posts here, instead taking screenshots of the GUI in the browser.

Also many effects are quite complex and using assembly for their preparation is rather unlikely, IMO.

Yeah, code gen directly to memory, and maybe that eventually evolves into an internal API. Assembly though still means sprintf’ing all the code to text, fork/exec an assembly, ld to create a .so?, loading it.
 
Back
Top Bottom