I'm working on a project based on a powerful SBC. I want to make a closed loop and custom make a dac and adc for it. The board itself has a lot of great I/O including 2.5Gbps ethernet, USB3, and thunderbolt 4, as well as arduino. Which would be the easiest vs most worthwhile to implement for data transmission and collection? Or would it behoove me to choose one more than another for a specific use case?
Both. Trying to reduce latency as much as possible. Was even recommended to start looking into RTOS so I've been reading up on that as well.
I want to perform small signal analysis in real time on audio. I'll be sampling the signal directly from the speakers, sending the signal to the DSP, and sent back out via dac.
Typically audio ADCs and DACs are connected to controllers through I2S bus. If your DSP controller links these chips via I2S, the latency can be minimized as no other bus conversion (USB, Thunderbolt) is required (every conversion involves buffers => added latency).
We do not know how involved your DSP is. Typically the lowest latency is incurred by specialized DSP chips with I2S I/O (like those used in AVRs). MCUs with none or simple OS (e.g. FreeRTOS) would come next (e.g. STM32s with DAIs etc.). A full-blown OS like linux will incurr larger latency (hard to get IO latency below single milliseconds for a VERY optimized RT linux system) - provided the linux computer communicates with the ADC/DAC directly via I2S.
ARM linux SBCs have I2S bus natively, allowing minimum latency and cost.
x86 computers (like your board) do not feature I2S buses natively. Either PCI-e <-> I2S controller (internal soundcards, or Intel HDA bus for onboard integrated soundcards) or USB connection is required. USB has the largest latency because of the USB bus intermediary.
It all depends on your requirements, what other features apart of DSP are required (network connectivity, graphics, etc...)
We do not know how involved your DSP is. Typically the lowest latency is incurred by specialized DSP chips with I2S I/O (like those used in AVRs). MCUs with none or simple OS (e.g. FreeRTOS) would come next (e.g. STM32s with DAIs etc.). A full-blown OS like linux will incurr larger latency (hard to get IO latency below single milliseconds for a VERY optimized RT linux system) - provided the linux computer communicates with the ADC/DAC directly via I2S.
ARM linux SBCs have I2S bus natively, allowing minimum latency and cost.
x86 computers (like your board) do not feature I2S buses natively. Either PCI-e <-> I2S controller (internal soundcards, or Intel HDA bus for onboard integrated soundcards) or USB connection is required. USB has the largest latency because of the USB bus intermediary.
It all depends on your requirements, what other features apart of DSP are required (network connectivity, graphics, etc...)
I'm still at the planning stages so right now it's anyone's guess. You do bring up an interesting point though about HDA. On the back of the board, the 2 M keyed M.2 ports are PCIe. One at 3.0 and one at 4.0 speeds. Perhaps a microcontroller on one of those and connect that to the DACs/ADCs?It all depends on your requirements, what other features apart of DSP are required (network connectivity, graphics, etc...)
If you want to use this like a feedback loop to your audio gear, I think you will find a computer very poor for that application. IF that is the intended use for your project I recommend doing some rough calculations about the phase change caused by the I/O and processing delays before proceeding.I want to perform small signal analysis in real time on audio. I'll be sampling the signal directly from the speakers, sending the signal to the DSP, and sent back out via dac.
No I2S I/O. You might be better served by one of AD's DSP offerings.It's the Lattepanda Sigma 32GB model https://www.dfrobot.com/product-2748.html
I've been looking into RTOS for this. There are plenty of use cases out there for higher levels of compute in real time. One I've seen first hand is in radar.If you want to use this like a feedback loop to your audio gear, I think you will find a computer very poor for that application. IF that is the intended use for your project I recommend doing some rough calculations about the phase change caused by the I/O and processing delays before proceeding.
What about what @phofman recommending? Using HDA?No I2S I/O. You might be better served by one of AD's DSP offerings.
I guess all of this brings up another question: is I2S the best bus for analog signal data? I was thinking of using SAR ADCs as opposed to the usual sigma-delta.
The analogue data has to converted to digital for I2S. I2S or a similar format is standard for the audio dacs. SAR dacs often use SPI and the SBC does have one SPI port. Don't see any obvious digital access using HDA.
If you are committed to using the Lattepanda you might want to consider a digital audio USB interface like this one. Stll think it would so much easier with an AD DSP board.
If you are committed to using the Lattepanda you might want to consider a digital audio USB interface like this one. Stll think it would so much easier with an AD DSP board.
VXWorks ?I've been looking into RTOS for this. There are plenty of use cases out there for higher levels of compute in real time. One I've seen first hand is in radar.
Any reason SPI wouldn't do the trick?The analogue data has to converted to digital for I2S. I2S or a similar format is standard for the audio dacs. SAR dacs often use SPI and the SBC does have one SPI port. Don't see any obvious digital access using HDA.
This is neat! But wouldn't you be just adding one more link in the chain as opposed to going right to one of the data busses?If you are committed to using the Lattepanda you might want to consider a digital audio USB interface like this one.
AD was actually my first stop. I was looking into an audio DSP kit they make (https://www.analog.com/en/design-ce...valuation-boards-kits/sharc-audio-module.html) but I wanted to use higher sample/bit rates. It DOES have some spare I/O, but I didn't know if it would be enough for ex. 4 DACs and 4 ADCs.Stll think it would so much easier with an AD DSP board.
Nope. Completely proprietary from the ground up. Never even got documentation on it so if it failed the company that made it just said reinstall it. That or just replace the module entirely.VXWorks ?
Even a "real time" OS is not at all real-time like an analog circuit. There will still be buffering and processing delays that will be on the millisecond or two time scales at least. You cannot get better/faster than that AFAIK.I've been looking into RTOS for this. There are plenty of use cases out there for higher levels of compute in real time. One I've seen first hand is in radar.
Too true. That's why I made this post. I'm probably going to have a lot of processing overhead. All I have in mind for this is CamillaDSP on a RTOS, but I'm sure there's a lot of other things out there I can run with it. Maybe even something better than CamillaDSP! Don't know till you ask right? 🙂
Unless your requirements are specified (max latency, latency precision, samplerates, sampling precision, channels, etc. etc) this discussion makes no sense, IMO.
Every so often I build custom PCs for people. When I do, the first 2 questions I ask them are 1) How much do you want to spend? 2) What do you want it to do? For me, I'm looking to spend max 2k-3k total for my project. As for what I want to do? The best I can whilst maintaining the design philosophy of the simple closed loop (DSP>DAC>amp>speakers>ADC>DSP). From my experience, sometimes it isn't about shooting for the best/specific spec so much as asking what's possible and within my means, and going from there. I can build computers from simple office PC to server grade. But asking me to, for example, build you a miniature crypto farm with only $200? I don't think so. Conclusion: I'm going to do the best I can with what is feasibly available to me. I can always order parts, even build a board, or crack open a code book. My overall goal is to make something good enough that would rival much more expensive systems. People post things here all the time here DIY stuffs that can do better than mass produced. I figure, why not give it a shot and see what I can do? Worse comes to worst I made a really cool DIY project.
- Home
- Source & Line
- Digital Source
- Which I/O?