DSP 01, part 7: (totally working) SPDIF audio

in my last post, i established that the CP2114 doesn't work. so how are we going to solve the synchronous clocking problem, and build a working digital input for the DSP 01?

there's always the brute-force approach - use a high-fidelity asynchronous sample-rate converter. this is a circuit which doesn't care what sample rate (and sample clock) the source is using - it will resample the signal to match the DSP 01's internal clock. after more internet research, i decided to use the CS8422.

the CS8422 is a 24-bit Asynchronous Stereo Sample-Rate Converter. it will accept a digital audio signal at almost any sample rate and resample it to exactly match the DSP 01's fixed 48kHz sample clock. while the CP2114 has a USB input, the CS8422 uses SPDIF, which i have certainly played with before.

so here's what we've got:

now the digital input should be resampled to match the DSP 01's internal clock (clock2), but does it really work? let's build a board to connect them!

PCB layout: front (left) and back (right)

..i didn't even take a photo of that one. but whatever, it worked. which allowed me to make a much better one, as you shall see.

time and time again, i have found that connectors are the bane of my existence. they're bulky, expensive, ugly and time-consuming. even the first DSP 01 project used 3.5mm-to-RCA audio cables & connectors for internal hook-up, and that doubled the size of the chassis. how could i entirely purge ugly internal connectors from my next project?

the objective - to connect a DSP 01 board to a 6-channel power amplifier and a front-facing instrument panel. instead of RCA jacks, i'd link everything with 0.1" headers. they would go together like this:

the amplifier & DSP 01 would connect to a horizontal backplate, but the controls & inputs needed a vertical front panel. i'd have to build two boards and connect them at right-angles.

time for 3D PCBs!

PCB layout: control panel front (upper) & back (center), orthogonal backplate (lower).

the small box on the left is a 5V switching regulator. this lets the DSP 01 run on the same 24V supply voltage as the 6-channel amplifier.

and now to put it together.

i think it's quite pretty.

next update: a moment of art & industrial design.

Tshen2 2015

DSP 01, part 6: (a total lack of) USB audio

if you're playing music from your computer, and it's coming out of amplified speakers, the signal chain probably looks like this:

the music is stored digitally in your computer. it gets converted to analog audio by the digital-to-analog converter (DAC) which is in your soundcard (or external). the analog audio is embiggened by the amplifier, which then pushes your speakers.

When you stick a DSP in the middle, the picture looks a bit more stupid.

the main problem is synchronous clocking - both the transmitter and receiver must be using the same clock. here, the source is using clock1 and the DSP is using clock2. you cannot simply force the DSP to use clock1, because all the DSP's frequency filters are controlled by its clock, and clock1 can be very inconsistent! if clock1's frequency shifts by 2%, the DSP's frequency filters will shift by 2%. if clock1's frequency is 44.1kHz when the DSP is expecting 48kHz, things could get very, very broken.

while journeying through the intertubes, i found a potential solution - the CP2114 by Silicon Labs. it is a 'USB-to-I2S Digital Audio Bridge', i.e. a chip which connects to your computer's USB port, and speaks a digital audio protocol (I2S) which the DSP understands. how does this solve the 'different clocks' problem?

the CP2114 is an 'asynchronous' USB audio device. this means a few things:

• it uses its internal clock (clock2) which is shared with the DSP.
• it tells the source (e.g. computer) to prepare data for a fixed sample rate (48kHz).
• due to clock mismatch, the source will send data too rarely or too often. the CP2114 can tell the source to 'send more/less data' as necessary.

in this scheme, it doesn't matter that the source and DSP don't share the same clock. the source is forced to resample and transmit the data at 48kHz, and if its clock doesn't match up exactly with the CP2114's clock, the CP2114 can tell it to slow down or speed up.

as for bit-depth, the CP2114 only supports 16-bit audio, which is rather low. however, it also supports sending 'volume control' information as a separate 8-bit signal. since the main advantage of 24-bit audio vs. 16-bit audio is having more bits to throw away for dynamic range, that separate 8-bit volume control makes the low bit-depth more palatable.

so - let's make a board to plug the DSP 01 into a CP2114.

PCB layout - front (left) & back (right).

USB connector is in the bottom left.

and a DSP 01 board at the back!

does it work? nope.

the DSP 01 wants a 24.576MHz clock signal. in order to produce that clock, i put a 49.152MHz clock on the CP2114 board (pictured above) and tried to use the CP2114's internal clock dividers to halve that clock to 24.576MHz for the DSP 01. the problem is, the CP2114's clock dividers only work when the CP2114 is connected to a computer's USB port. the DSP 01 wouldn't be able to run at all if no USB source was present.

so i redesigned the board, this time with an external clock divider (using a D-flipflop):

PCB layout - front (lower) & back (upper).

does it work now? still nope.

but why?

as i've mentioned, the CP2114 is supposed to be a 'USB-to-I2S Digital Audio Bridge'. the DSP 01 accepts digital audio input through an I2S bus, so I assumed they'd be able to talk to each other. the thing is.. the CP2114 does I2S wrong.

here is a screenshot from the I2S spec:

let's pay attention to these two points:

1. the serial clock (SCK) must be continuous.
2. the 'transmitter always sends the MSB of the next word (on the SCK) one clock period after the WS (Word Select) changes'.

now, let's compare this to actual SCK and WS signals from the CP2114.

CP2114 I2S bus: SCK (upper) and WS (lower)

the CP2114 fails on both listed criteria:

1. the SCK is obviously not continuous - instead it appears in bursts, with an inconsistent time-delay after each WS clock edge.
2. the MSB of the next word (on the serial data line, not shown) appears when the SCK appears. but the SCK doesn't start one clock period after the WS changes. so the MSB of the next word doesn't appear at the right time either!

rest assured that i have used the CP2114 correctly, and tried every conceivable setting which might get it to work.

i contacted Silicon Labs about this obvious deviation from the I2S spec, and got this reply:

“It is possible that the device you are using has requirements outside the I2S specification, you would need to ask the manufactures (sic) of that device if this is the case.
It’s also possible that this has nothing to do with that delay, but from the scope shots you sent there are no obvious issues. ”

this is after they'd linked me to the same I2S specification which i used to debug the problem!

so, i presume they are aware of the problem, but are unable or unwilling to fess up to it, or do anything about it for the time being.

either way, it doesn't really matter. unless big changes are made, the CP2114 is dead to me.

moving on..

UPDATE: Silicon Labs got back to me! this is what they said:

“The CP2114 actually implements I2S with a SPI, some firmware, and a few other things. Because of that you get some artifacts like this.
Unfortunately the (sic) are limitations of the hardware and I don’t see a way to work around them in the device firmware. I will run it by the the firmware guys just to be sure.”

either way, i still can't use the CP2114. it seems like an easy fix in hardware - add a bit of logic to buffer the serial data, and output it synchronously during the next sample clock. you'd get a one-sample delay but who cares. of course, you can't do that in firmware..

next update: i use resampled SPDIF to get a working digital input!

Tshen2 2015