I'm using a ADAU144x eval board to convert an SPDIF input to an I2S output.
The SPDIF input is a proprietary format with 3 data channels, each with left and right subframes. The data in each subframe contains 2 channel bits that indicate which channel it belongs to. This effectively creates 6 data channels, indexed by the 2 channel bits and the LRCLK. Some of these channels contain control data (volume, mute, etc.), and the others contain audio data (22 bits).
I would like to demux these data channels by extracting the channel bits. I also want to use the control bits to mute and change the volume of the audio channels.
Is there a way for me to directly access the raw bits of the SPDIF/I2S stream?
No, there is no way to get to the raw bits of the SPDIF data stream. The ADAU1452 family of parts have a little more capability but I am not certain it is enough for you.
Is the channel bits and control bits residing in with the 24 bit audio data in the SPDIF stream? I am not 100% certain from your description. If it is then in SigmaStudio you can manipulate the sample to extract these bits.
Thanks for the reply.
The channel bits are present in all 6 subframes, to define which subframe it is. The control bits are only present in I think 2 of the subframes, I'm waiting for some documentation on how to handle these bits.
I actually just figured out how to do this. I realized that the SPDIF input on the block diagram is already converted by the DSP into I2S format. I split that stream and did a bitwise AND to extract the channel bits. I then ran the channel bits into a demux block to route the SPDIF-I2S stream into different parts of my block diagram. It doesn't look pretty but it seems to work, I can listen to the individual audio channels.
Great, that is what I was going to suggest as long as the data is in the audio portion of the SPDIF stream. It is the user bits that you really can't get to.
Now you may run into an issue if you use the ASRC. It will change the data if the sampling rates drift apart and they will. In the Sigma300 you can bypass it but we removed that feature from SigmaStudio for several reasons. In the Sigma200 that you are using you can still bring in the SPDIF data directly into the core. Then I suggest you set the Core Start Pulse to be from the SPDIF receiver. This should help prevent the clicks and pops but the down side is that when the SPDIF goes away the core stops in its tracks. This part has no way of monitoring the state of the SPDIF input to switch to another clock when there is no SPDIF signal. This would have to be done with a controller.
Don't think I'll need the ASRC, my input is just routed directly to the SPDIF receiver.
My start pulse select used to be an internally generated 48 kHz. I've set it to sync with the SPDIF stream, it didn't make a noticeable difference.
On the topic of sampling rates, each data channel has an odd sampling frequency of 39.0625 kHz, this seems to be part of the proprietary format. I can still hear the audio, but it's really distorted. Is there a way I can set the SPDIF sampling frequency to this value?
The sampling rate of the SPDIF is set by the incoming SPDIF signal. The SPDIF receiver in the DSP has a PLL to recover and lock to this incoming rate. If the source of the SPDIF signal is not locked to the Master Clock source for the DSP then they will be running at different rates. This will cause the occasional click and pop when a word or two of data is missed or gets corrupted. This is why the ASRC is needed to convert the SPDIF rate to the DSP rate. If you use the start pulse from the SPDIF then the core will start running the program at the start of the new frame. Then the serial port data will be correct and it works without the ASRC. The number of instructions per frame may vary slightly but you should not get the clicks and pops.
In this core we don't have a lot of options for the sampling rate. The ADAU1452 has several clock generators that you can setup to run at a custom rate. Then you can use the serial ports to go out and back in through the ASRC. In this part you would have to use an external clock to drive the serial port. Then that would clock the data out at the 39.0625 rate. Then connect that port back to an input serial port and run it into the ASRC to get the rate up to the core rate. The trick will be getting the 39.0625 clocks. It still will not be perfect because the rate that the data is being updated is at the core rate of 48kHz and that is not evenly divisible by 39.0625.
So thinking about this, right now what is happening is that the data changes every 1.229 samples at 48kHz. So it is changing every other sample, roughly. So the data is holding the value for two samples. This gives you harmonics at the 39kHz sampling rate. So try a low-pass filter at 19.53kHz and see if that helps. It would have to be a rather steep rolloff.