I have been researching building (on a hobby level) a serious USB DAC. Upon trying to find a suitable USB Audio I2S bridge chip, which has proven a bit tricky, I realised that the Teensy has this functionality built in. As I have a Teensy LC lying around I decided to give it a try. 44.1Khz/16 bit is the target for this project, leaving higher resolutions for future improvements, or when Paul has the time to fix the support for these
Design goals is to combat jitter as much as possible, feed the I2S lines to a PCM1794A or 1792A DAC and mate that with a high quality analog stage for output.
Questions:
* Will I be able to get I2S data from the teensy as a USB Audio Bridge? The docs mentions specific codecs/DACS that are supported, but I assume any I2S-based DAC can be used? Docs are a bit unclear on that.
* Is the actual sample frequency now 44.1KHz and not still 44117.64706? Another thread mentions problems with Macs and a solution to this was (as understood) to correct the sampling frequency...
* Can the extracted MCLK line be used as a jitter "free" clock source, or do I need to reclock the data stream externally to actually reduce jitter problems?
* Will a Teensy LC suffice for this, or do I need a higher version?
One possible solution to create a higher quality bridge without dependency on the Teensy derived clock might be to use a FIFO queue between the teensy and DAC, as an asynchronous buffer (independent read/write), and clock the DAC from a local quarts oscillator with a "perfect" 44.1Khz rate. The DAC would then be able to chew its audio data from the fifo on its own, with jitter only depending on the quality of the local oscillator.
This scenario has the problem of buffer under/overrun over time if the clocks differ.
* Is there a possibility to ask the teensy USB audio bridge to slow down or speed up data transfer from host a bit, using it's adaptive feedback on the USB audio protocol? In that case we could let the teensy keep filing up the fifo just enough.
These ideas are specualative and theoretical at the moment, so much may change...
Design goals is to combat jitter as much as possible, feed the I2S lines to a PCM1794A or 1792A DAC and mate that with a high quality analog stage for output.
Questions:
* Will I be able to get I2S data from the teensy as a USB Audio Bridge? The docs mentions specific codecs/DACS that are supported, but I assume any I2S-based DAC can be used? Docs are a bit unclear on that.
* Is the actual sample frequency now 44.1KHz and not still 44117.64706? Another thread mentions problems with Macs and a solution to this was (as understood) to correct the sampling frequency...
* Can the extracted MCLK line be used as a jitter "free" clock source, or do I need to reclock the data stream externally to actually reduce jitter problems?
* Will a Teensy LC suffice for this, or do I need a higher version?
One possible solution to create a higher quality bridge without dependency on the Teensy derived clock might be to use a FIFO queue between the teensy and DAC, as an asynchronous buffer (independent read/write), and clock the DAC from a local quarts oscillator with a "perfect" 44.1Khz rate. The DAC would then be able to chew its audio data from the fifo on its own, with jitter only depending on the quality of the local oscillator.
This scenario has the problem of buffer under/overrun over time if the clocks differ.
* Is there a possibility to ask the teensy USB audio bridge to slow down or speed up data transfer from host a bit, using it's adaptive feedback on the USB audio protocol? In that case we could let the teensy keep filing up the fifo just enough.
These ideas are specualative and theoretical at the moment, so much may change...