Hi,
I am designing a prototype for an audio board using the xmos startkit.
I need one stereo channel output, one mono output and 3 stereo channels input. Sample rate should be fixed, 96kHz or 192kHz. I am using the CS42448 audio codec. I do NOT need any USB audio. Additional there is an external bluetooth chip with SPDIF or I2S output, 48kHz sample rate. The software should then mix all the inputs and the signal from the BT chip in some way and route the audio signal to the outputs. I have finished all the analog parts, the supplies and so on, but now I have troubles to understand requirements for the clocks. I looked at the 8soundusb board, they use a CS2300 PLL, but how do I get the SYNC_OUT, is it enough to simply generate a clock in source code, or is it derived somewhere from the USB audio? I also looked at the USB Audio 2.0 Ref Design XS1-L1 schematics, I think using a single oscillator with appropriate frequency for 96 or 192kHz would be the simplest solution?
The bluetooth chip has a SPDIF and an I2S interface, sample rate is fixed at 48kHz. I would like to use the SPDIF output and simply connect it to a port on the XMOS of the startkit and decode it with the SPDIF receiver api available on github. Is it necessary to provide some clock for this to work?
Using the I2S interface of the BT chip would require another clock for the 48kHz?
Thank you for your help,
wil
audio clocks
-
- Junior Member
- Posts: 5
- Joined: Mon Jan 27, 2014 4:12 pm
-
Verified
- XCore Legend
- Posts: 1164
- Joined: Thu May 27, 2010 10:08 am
It all depends.. If you have a bluetooth audio source that is the clock master, your system will need to be synchronous to that, unless you want to mess around with asynch sample rate conversion, which is messy and expensive (although probably doable with XMOS - no IP off the shelf though today).
The key question is whether your bluetooh module can be the I2S slave or not. If it can be slave, it's easy to have the media clock master locally to XMOS (no PLL needed) and produce 48/96/192 or whatever locally.
If there is no MCLK pin available on the module and you only have SLCK (I2S clock), then you'll need a PLL to re-generate the MCLK. You can then divide down to get whatever you want (eg. 96 or 192). In this case you'll need a task to count SCLKs and drive the SYNC_OUT for the PLL. In the ref design, it's driven by XMOS at 300Hz (from interal osc if no SPDIF in, or 300Hz derived from SPDIF in if present). It uses a pretty high multiplication ratio (81920 or 75264)
All of these possibilities are fairly easy to implement in XMOS, so you're covered with your choice of IC, although it's likely you'll need to change your hardware (clock lines to ports).
Without a datasheet for the bluetooth, that's about all I can say! This topic probably belongs in the forum as it's not a simple Q&A.
The key question is whether your bluetooh module can be the I2S slave or not. If it can be slave, it's easy to have the media clock master locally to XMOS (no PLL needed) and produce 48/96/192 or whatever locally.
If there is no MCLK pin available on the module and you only have SLCK (I2S clock), then you'll need a PLL to re-generate the MCLK. You can then divide down to get whatever you want (eg. 96 or 192). In this case you'll need a task to count SCLKs and drive the SYNC_OUT for the PLL. In the ref design, it's driven by XMOS at 300Hz (from interal osc if no SPDIF in, or 300Hz derived from SPDIF in if present). It uses a pretty high multiplication ratio (81920 or 75264)
All of these possibilities are fairly easy to implement in XMOS, so you're covered with your choice of IC, although it's likely you'll need to change your hardware (clock lines to ports).
Without a datasheet for the bluetooth, that's about all I can say! This topic probably belongs in the forum as it's not a simple Q&A.
Engineer at XMOS