Hi All.
I'd like to take the 48kHz/24b TDM8 outputs of two Cirrus 8-channel ADCs and serve them uncompressed via a TCP port on the Teensy. In theory, TDM8 serial data would be written to memory in a struct containing an incrementing 'sorting' value and a 1-16 'channel' value. Memory register will have a fixed size, and gracefully drop any packets older than "x" increments.
A client application will connect via the Teensy's IP address to request any available audio data. Any audio data in the register will be packetized and sent to the client, then dumped from the register.
The client-side app will include a configurable sample buffer, allowing the user to select a buffer size that produces least latency without audio drop-out. Received packets will be written to a playback register in the sequenced order and played back at 48kHz within the app.
All this would need to be built on top of/around a project like this one:
https://forum.pjrc.com/threads/56117-PoE-powered-OSC-controller-for-Reaper-DAW
Which would simultaneously transmit and receive OSC control data via the same Ethernet jack on separate UDP ports. OSC is latency-tolerant (or ought to be, as it is built on top of a standardized ethernet stack) and should never block audio processing tasks.
Still considering whether this would be possible on a single Teensy, or whether separate audio and OSC boards ought to serve preprocessed data to a third board acting as the network server. I'd think there are plenty of cycles on the Core to do both, but it may require extensive rewriting of the existing code which might be beyond my capabilities.
I don't really have the Microcontroller Dev chops for this project, but I'm a longtime follower of such projects and have deep background in electronic circuitry, digital audio, musical control protocols, programming, and ethernet... so I believe I'm game to try...
I welcome any and all comments from interested parties on whether Teensy is the right call here, and where to start. So far I've looked at the Teensy Audio project (which I believe is 44.1k/16b, so **no longer in the discussion.)
This project has also caught my attention:
https://forum.pjrc.com/threads/61942-Audio-bridge-to-Ethernet-is-it-possible?p=289856#post289856
Thanks to the creators of the linked projects for all their excellent work on the subject!
**Do note that 48k/24b/16ch is a hard-specified requirement, lest the conversation drift into "Why would you need THAT?"-land. I understand the arguments on both sides, but would rather not spend time on that discussion. (This project will interface with an extremely complex and extremely expensive existing audio/network system, which cannot be run at 44.1k/16b due to compatibility with existing hardware and software. The choice of sample rate and bit depth was made many months ago and doubled-down upon during system purchase/build.)
I'd like to take the 48kHz/24b TDM8 outputs of two Cirrus 8-channel ADCs and serve them uncompressed via a TCP port on the Teensy. In theory, TDM8 serial data would be written to memory in a struct containing an incrementing 'sorting' value and a 1-16 'channel' value. Memory register will have a fixed size, and gracefully drop any packets older than "x" increments.
A client application will connect via the Teensy's IP address to request any available audio data. Any audio data in the register will be packetized and sent to the client, then dumped from the register.
The client-side app will include a configurable sample buffer, allowing the user to select a buffer size that produces least latency without audio drop-out. Received packets will be written to a playback register in the sequenced order and played back at 48kHz within the app.
All this would need to be built on top of/around a project like this one:
https://forum.pjrc.com/threads/56117-PoE-powered-OSC-controller-for-Reaper-DAW
Which would simultaneously transmit and receive OSC control data via the same Ethernet jack on separate UDP ports. OSC is latency-tolerant (or ought to be, as it is built on top of a standardized ethernet stack) and should never block audio processing tasks.
Still considering whether this would be possible on a single Teensy, or whether separate audio and OSC boards ought to serve preprocessed data to a third board acting as the network server. I'd think there are plenty of cycles on the Core to do both, but it may require extensive rewriting of the existing code which might be beyond my capabilities.
I don't really have the Microcontroller Dev chops for this project, but I'm a longtime follower of such projects and have deep background in electronic circuitry, digital audio, musical control protocols, programming, and ethernet... so I believe I'm game to try...
I welcome any and all comments from interested parties on whether Teensy is the right call here, and where to start. So far I've looked at the Teensy Audio project (which I believe is 44.1k/16b, so **no longer in the discussion.)
This project has also caught my attention:
https://forum.pjrc.com/threads/61942-Audio-bridge-to-Ethernet-is-it-possible?p=289856#post289856
Thanks to the creators of the linked projects for all their excellent work on the subject!
**Do note that 48k/24b/16ch is a hard-specified requirement, lest the conversation drift into "Why would you need THAT?"-land. I understand the arguments on both sides, but would rather not spend time on that discussion. (This project will interface with an extremely complex and extremely expensive existing audio/network system, which cannot be run at 44.1k/16b due to compatibility with existing hardware and software. The choice of sample rate and bit depth was made many months ago and doubled-down upon during system purchase/build.)