You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
convert i2s audio to usb output stream using 24-bit 192khz on both ends using teensy 4.1
- Thread starter beaker152
- Start date
I'm sure it has, *somewhere*, but not documented anywhere that I've seen. The official audio library is hardcoded for 16-bit 44.1kHz. Not #defined, but actually hardcoded throughout, so that's a no-go. (*) I found that out with one of my projects that needs some custom DSP work. Looks like, if you have to use a Teensy, and you can't use 16-bit, 44.1k, you're writing your own everything including USB. Good luck!
The rest of this is mostly a question of whether you really want what you say you want. I don't think you do. From what you've said so far, I think you're running on some common misunderstandings and common holes in understanding.
TL;DR: I think there's a pretty good chance that a double-blind test in your application (after getting everything working in the first place, for both versions) won't show any difference at all between the standard library and what you're asking for. Technically there is, with a pretty big difference in some of the numbers, but *both* are already beyond perception, so no one's actually going to notice without being told.
(*) Hardcoding the sample rate makes the processing itself a LOT easier to code, because ALL of the math has to be translated from absolute frequency into some fraction of the sample rate. So if the sample rate changes, *everything* has to be recalculated! For a capable library, that's a lot of work! So it's understandable to see a general-purpose thing make a statement of non-consideration by hardcoding it throughout.
For my project with the custom DSP, I switched to XMOS. (links at the end) 24-bit I/O, with deeper processing so the cumulative roundoff error gets truncated away at the end. (**) 96kHz for live latency, analog to analog, the vast majority of which comes from the converters (***), not the single-sample communication with them or the single-sample (per parallel thread) DSP code. USB for me is only for monitoring/debugging/recording: as soon as you have USB's buffers in the *primary* signal path, plus an operating system's buffers, there's no longer a point in going any faster than 44.1k or 48k, depending on which standard you're going to interface with later in the process.
(**) 16-bit I/O is *probably* okay, but I wanted to leave no excuse. It's difficult but possible to make an analog circuit outperform a 16-bit conversion. (having seen inside some pro analog consoles, they probably don't, even new) But 24-bit? Forget it! Physically impossible. The bottom few bits of a 24-bit conversion will *always* be analog circuit noise, no matter how good you are as a designer or what parts you use. No more concern about digital quantization noise, because the guaranteed analog noise dwarfs it.
(***) Regardless of sample rate, *the converter itself* always rolls off at 20kHz. That's a function of how the conversion works in the first place: shallow mid-MHz analog sampler with added high-frequency "wiggle" to guarantee that the shallow samples have some variation, then digital lowpass to simultaneously anti-alias to the final rate and convert the wiggle into more depth, then pick out full-resolution samples at the final rate to send out and throw the rest away. That digital lowpass *always* rolls off at 20kHz, only more gradually for higher sample rates, and that shallower rolloff produces fewer samples of latency in addition to less time per sample. But it's still physically sampling at the same mid-MHz rate (same cheap analog anti-aliasing), and it's still rolling off internally at 20k. No flat ultrasonics, regardless of *any* settings, from the converter chip.
I still have a Teensy involved in that project, but it handles everything *else* and not audio, and communicates with the XMOS to change how the processing works and get some summary answers back. XMOS is weird as microcontrollers go: hardly any peripherals, but a TON of identical cores with good communication between them, so you can bit-bang your own peripherals, or do parallel processing, or whatever. They also have excellent documentation, unlike most, so it shouldn't be too hard to get your own thing going on a dev board, and then copy and modify that design to spin your own PCB.
The rest of this is mostly a question of whether you really want what you say you want. I don't think you do. From what you've said so far, I think you're running on some common misunderstandings and common holes in understanding.
TL;DR: I think there's a pretty good chance that a double-blind test in your application (after getting everything working in the first place, for both versions) won't show any difference at all between the standard library and what you're asking for. Technically there is, with a pretty big difference in some of the numbers, but *both* are already beyond perception, so no one's actually going to notice without being told.
(*) Hardcoding the sample rate makes the processing itself a LOT easier to code, because ALL of the math has to be translated from absolute frequency into some fraction of the sample rate. So if the sample rate changes, *everything* has to be recalculated! For a capable library, that's a lot of work! So it's understandable to see a general-purpose thing make a statement of non-consideration by hardcoding it throughout.
For my project with the custom DSP, I switched to XMOS. (links at the end) 24-bit I/O, with deeper processing so the cumulative roundoff error gets truncated away at the end. (**) 96kHz for live latency, analog to analog, the vast majority of which comes from the converters (***), not the single-sample communication with them or the single-sample (per parallel thread) DSP code. USB for me is only for monitoring/debugging/recording: as soon as you have USB's buffers in the *primary* signal path, plus an operating system's buffers, there's no longer a point in going any faster than 44.1k or 48k, depending on which standard you're going to interface with later in the process.
(**) 16-bit I/O is *probably* okay, but I wanted to leave no excuse. It's difficult but possible to make an analog circuit outperform a 16-bit conversion. (having seen inside some pro analog consoles, they probably don't, even new) But 24-bit? Forget it! Physically impossible. The bottom few bits of a 24-bit conversion will *always* be analog circuit noise, no matter how good you are as a designer or what parts you use. No more concern about digital quantization noise, because the guaranteed analog noise dwarfs it.
(***) Regardless of sample rate, *the converter itself* always rolls off at 20kHz. That's a function of how the conversion works in the first place: shallow mid-MHz analog sampler with added high-frequency "wiggle" to guarantee that the shallow samples have some variation, then digital lowpass to simultaneously anti-alias to the final rate and convert the wiggle into more depth, then pick out full-resolution samples at the final rate to send out and throw the rest away. That digital lowpass *always* rolls off at 20kHz, only more gradually for higher sample rates, and that shallower rolloff produces fewer samples of latency in addition to less time per sample. But it's still physically sampling at the same mid-MHz rate (same cheap analog anti-aliasing), and it's still rolling off internally at 20k. No flat ultrasonics, regardless of *any* settings, from the converter chip.
I still have a Teensy involved in that project, but it handles everything *else* and not audio, and communicates with the XMOS to change how the processing works and get some summary answers back. XMOS is weird as microcontrollers go: hardly any peripherals, but a TON of identical cores with good communication between them, so you can bit-bang your own peripherals, or do parallel processing, or whatever. They also have excellent documentation, unlike most, so it shouldn't be too hard to get your own thing going on a dev board, and then copy and modify that design to spin your own PCB.