I am interested in a project that would use the WM8804 as an SPDIF receiver. I need a particular combination of BCLK and MCLK rates that are not available through the hardware mode of the WM8804 so I need to implement this via software mode and an onboard 12.288MHz crystal. I have used the Arduino platform in the past and the WM8804 can be set up in software mode using the Arduino's I2C bus to set registers. The UNO is convenient because it is easy to program, has onboard power, they are cheap, and I happen to have a couple spares. A purist would come at this project from another direction, but I am just a DIYer trying to get something done, so this seems to be the best path for me.
This could serve as the front end of an SPDIF DAC, the D-to-A part being on another board. It seems that there are some good DAC boards with I2S input available these days.
Would anyone else be interested in this? I have seen numerous threads where WM8804 software control has been discussed but no project has actually come out of it.
This could serve as the front end of an SPDIF DAC, the D-to-A part being on another board. It seems that there are some good DAC boards with I2S input available these days.
Would anyone else be interested in this? I have seen numerous threads where WM8804 software control has been discussed but no project has actually come out of it.
Hi charlie,
What amount of final jitter will you expect please ? (in relation to the hardware mode alone of the WM8804 which is IIRC : 50 ps ? )
the problem is the jitter with SPIDF ! But in my last DAC which is the Subbu 3, it is not a problem for me but just asking because everybody seem to go with async usb/SD card or DSP todays... some with MCLK ! Like the one of HIFIDUINO (XMOS USB)
Interresting...
What amount of final jitter will you expect please ? (in relation to the hardware mode alone of the WM8804 which is IIRC : 50 ps ? )
the problem is the jitter with SPIDF ! But in my last DAC which is the Subbu 3, it is not a problem for me but just asking because everybody seem to go with async usb/SD card or DSP todays... some with MCLK ! Like the one of HIFIDUINO (XMOS USB)
Interresting...
The level of jitter is not really one of my major concerns. The functionality that I described is most important at this stage. But since you mentioned it, the WM8804 supposedly has pretty low jitter (e.g. 50ps) - for instance see: H I F I D U I N O: Programming the WM8804
I'd be interested in helping out.
I did see some arduino code, online, a few years ago. I was able to adapt it and compile it but I never tested it 😉
I think the stumbling block was the fact that 176/192 is 'hard' to do in software with that chip and its not clear how you tell what inbound freq is there to be able to lock-on to. the docs are not clear and they don't have pseudocode or flowcharts, either.
I suspect its just brute force; you try to assert one clock rate, give it time, see if 'lock' happens (valid flag). if not, try the next one. but it sure seems clumsy to do that.
there's also the AKM spdif receiver chips and those might be worth looking at, too. the wolfson is a bitch to solder (fine pitch leads, more than any other spdif chip I've seen). I can deal with it, but many would refuse to touch that kind of dense lead pkg.
I'd also like to see definitive proof that wolfson DOES reduce jitter. so far, I have their 'word' on it but I've not seen a bit of proof to support it. it would be nice, before spending a lot of time on this chip, to know that its worth it - vs some other chip.
I did see some arduino code, online, a few years ago. I was able to adapt it and compile it but I never tested it 😉
I think the stumbling block was the fact that 176/192 is 'hard' to do in software with that chip and its not clear how you tell what inbound freq is there to be able to lock-on to. the docs are not clear and they don't have pseudocode or flowcharts, either.
I suspect its just brute force; you try to assert one clock rate, give it time, see if 'lock' happens (valid flag). if not, try the next one. but it sure seems clumsy to do that.
there's also the AKM spdif receiver chips and those might be worth looking at, too. the wolfson is a bitch to solder (fine pitch leads, more than any other spdif chip I've seen). I can deal with it, but many would refuse to touch that kind of dense lead pkg.
I'd also like to see definitive proof that wolfson DOES reduce jitter. so far, I have their 'word' on it but I've not seen a bit of proof to support it. it would be nice, before spending a lot of time on this chip, to know that its worth it - vs some other chip.
I've been told (and it make sense, in a way) that the 50ps figure is a bit of a lie. its not the output jitter spec but an internal clock jitter spec, or something along those lines.
also, 50ps is somewhat HIGH for high-end audio use. you'd want 1/10 of that, really, if you are going to claim that you are attenuating jitter.
also, 50ps is somewhat HIGH for high-end audio use. you'd want 1/10 of that, really, if you are going to claim that you are attenuating jitter.
I hear you, but jitter is not a main concern for me with this project. The WM is a good starting point and the implementation seems pretty straightforward if I pair it up with an Arduino. I don't think that the AKM chips will work for me because I need BCLK=64*Fs and MCLK=12.288MHz when receiving 48kHz. Anything else I can wring out of the project will just be a bonus. If you want the full details I can fill you in via PM. Just drop me a line.
So : always hardware mode with a good crystal e.g. NDK, Crysteq... and good imunity : uf.l connector + wires for matching imedance between boards and a modern low noise PS.
Sorry for my lake of technical background : is it possible to buffered a spidf ? I can't understand if the spidf can be really improved because its input signal is already jittered from the source output and can't be cleaned after ?
Or go with async or slave the spidf input signal in the device with after a MCLK to fight the jitter more ? (to send the I2S from the device to the DAC chip) .
Sorry don't want to be OTor high jack : but why not something more modern lie a RJ45 device to I2S with an embeded linux SqueezeBox server or else. I see more and more (tele)comunicationembeded device on Mouser but don't know if one exist with multiple input like a bigger computer : SPIDF + USB + RJ45 plugs inputs ?
Sorry for my lake of technical background : is it possible to buffered a spidf ? I can't understand if the spidf can be really improved because its input signal is already jittered from the source output and can't be cleaned after ?
Or go with async or slave the spidf input signal in the device with after a MCLK to fight the jitter more ? (to send the I2S from the device to the DAC chip) .
Sorry don't want to be OTor high jack : but why not something more modern lie a RJ45 device to I2S with an embeded linux SqueezeBox server or else. I see more and more (tele)comunicationembeded device on Mouser but don't know if one exist with multiple input like a bigger computer : SPIDF + USB + RJ45 plugs inputs ?
What I am proposing is just one piece of a larger system. I am not interested in the kind of solution you are proposing.
OK, now I have a question. After reading over the data sheet a little more clearly the SPI specs that I mentioned above seem a little odd to me, or at least I haven't seen this before: BCLK=64*Fs at 24bit resolution. The SPDIF frame is 64 bits (32 left, 32 right) and whenever I have seen a timing diagram there are two BCLK transitions per data bit, that is to say it is the falling edge of the clock that is used for timing. For instance, see Figure 20 of the WM8804 datasheet. But for the particular application that I am working with, the spec is clearly for 64*Fs, which is impossible if the falling edge of the clock is used because this would require 128*Fs. This seems to mean that the data bits are aligned on a clock transition, but I have never seen this before. Or I am not understanding something here...
Can anyone comment on this?
Another tiny little problem that I discovered is found listed in Table 22: "Note: FREQMODE[1:0] bits are automatically set in SPDIF receive mode.". These bits set the BCLK to 128*Fs, meaning that I can't use the WM8804 to generate the 64*Fs that I need. Unless I can change the BCLK to 64*Fs, this project will be over before it's even started!
Could I use a logic IC like a flip-flop to generate the half-speed 64*Fs signal that I need from the 128*Fs signal? Would that be clean enough?
Help please.
Can anyone comment on this?
Another tiny little problem that I discovered is found listed in Table 22: "Note: FREQMODE[1:0] bits are automatically set in SPDIF receive mode.". These bits set the BCLK to 128*Fs, meaning that I can't use the WM8804 to generate the 64*Fs that I need. Unless I can change the BCLK to 64*Fs, this project will be over before it's even started!
Could I use a logic IC like a flip-flop to generate the half-speed 64*Fs signal that I need from the 128*Fs signal? Would that be clean enough?
Help please.
Last edited:
Actually, as usual you are right! The AK4113VF looks promising. I will need to read over the datasheet in detail but it looks like it would work and can be controlled via I2S or even hardware. Thanks for pointing me in the direction.
AKM is often overlooked. I have some AK spdif tx chips that I am planning on experimenting with. I might switch my tx chip of choice to AKM if my test works out.
otoh, the same wolfson chip can be a tx or an rx (that's kind of neat) and it can also be a repeater, taking in spdif and spitting it out again, supposedly de-jittered. its main downside is that software mode is 'funny'. hw mode is fine, and I don't think 176/192 is a problem, there.
if I have a good experience with AK's tx chip, I might look into their rx and see what that's about.
otoh, the same wolfson chip can be a tx or an rx (that's kind of neat) and it can also be a repeater, taking in spdif and spitting it out again, supposedly de-jittered. its main downside is that software mode is 'funny'. hw mode is fine, and I don't think 176/192 is a problem, there.
if I have a good experience with AK's tx chip, I might look into their rx and see what that's about.
Last edited:
Just to mention, I've got hold of a WM8804 evaluation board from here: WM8804 S/PDIF TOSLINK to IIS Converter I2S Codec Project integration DIY | eBay
In HW mode (no programming) it syncs up nicely with a 192k / 24 bit source. Here's the LRCLK and DOUT lines:
https://www.dropbox.com/s/hdycnlul0pmxirp/P1030496.JPG?dl=0
In HW mode (no programming) it syncs up nicely with a 192k / 24 bit source. Here's the LRCLK and DOUT lines:
https://www.dropbox.com/s/hdycnlul0pmxirp/P1030496.JPG?dl=0
- Status
- Not open for further replies.