I don't know about the ESS - does it share a clock or run of the wm8805 mclk ?
For the wm8805, the datasheet says the best performance is when r = 8, and iirc my calculations got r as 8.35374 and 8.7075 for 44.1/48 input with a 22.5792 xo , so I decided this was the best xo freq, not least because it means you can use a cchd-957 xo.
I'd need to re-study that datasheet to work out if this is in fact 100% the best choice, and I don't have time for that. All my projects are on hold as I have no spare time.
For the wm8805, the datasheet says the best performance is when r = 8, and iirc my calculations got r as 8.35374 and 8.7075 for 44.1/48 input with a 22.5792 xo , so I decided this was the best xo freq, not least because it means you can use a cchd-957 xo.
I'd need to re-study that datasheet to work out if this is in fact 100% the best choice, and I don't have time for that. All my projects are on hold as I have no spare time.
Generally, no. But forum member EUVL reports a benefit from the WM8804 S/PDIF receiver sharing the same external clock as the ESS DAC. In EUVL's implementation, the XO is 48 MHz, divided down to 12 MHz for the WM8804.
But with a software-controlled WM8805 we are not limited to 12MHz, and I'm asking if we can use more suitable clock-rates for both the S/PDIF receiver, and the DAC? This would be taking the "synchronous" concept to its optimum.
And of course, the samplerate of the source material must also be considered when applying a "synchronous" regime.
Let me apply some numbers, and hope I understand this correctly -
For 44.1 kHz material (and 88.2), I'm thinking that a 22.5792 XO would be the best to share between the WM8805 and a DAC;
- PRESCALED to 11.2896, you could use an N-value of 8, and K-value of 0. This lets the WM8805's PLL do a straightforward multiplication to 90.3168 MHz (within spec) for its S/PDIF RX, and this is a neat multiple of optimal clock rate for 44.1 kHz material.
- and the 22.5792 XO is a also a suitable clock rate for the DAC, when dealing with 44.1 kHz material.
For 48 kHz material (and also 96), a 24.576 XO would be best;
- configure the WM8805 to PRESCALE to 12.288, PLL_N "8", PLL_K "0".
The f2 value is then 12.288 x 8 = 98.304 (within spec) and suitable for 48 kHz / 96 kHz sources.
Am I right?
For 44.1/88.2/...khz it is common to use 22.5792Mhz because there is no rounding for the multiple; it is an integer (512, 1024, ..), and for 48/96/... it is usual to use 24.576 for the same reasons.
Some devices (like the Via pci receivers in some sound cards) can have two external xo's, which to me seems like the best solution, but then they are not great receivers. I wonder if it would be possible to configure the wm8805 to do this ? I don't think so.
So which clock to choose ? I guess it depends on what most of your material is. Mine is mostly CD and SACD with only a few DVD-A, so for me I think this is why I preferred the 22.5792Mhz to 24.576, but I have a nagging thought that the maths told me I'd get closer to 8 with 22.5972 and that's what the wm wants. What does the ESS want ?
Anyway, I honestly can't remember if the pll in the wm8805 works the usual way above. I seem to remember it does something unusual so I'm afraid I'm not able to say if you are 100% correct. Have you checked the data sheet for this ?
Also consider - who's writing the code ? If you're doing it yourself then of course you can try both, and measure/listen to decide. If not you, what does the programmer say ? Also, IIRC the wm8805 is a bit of a pig for 88.2khz, 192khz material as it requires a reset (or something like this - my memory is fuzzy), so going with the programmers advice would make sense to me.
Some devices (like the Via pci receivers in some sound cards) can have two external xo's, which to me seems like the best solution, but then they are not great receivers. I wonder if it would be possible to configure the wm8805 to do this ? I don't think so.
So which clock to choose ? I guess it depends on what most of your material is. Mine is mostly CD and SACD with only a few DVD-A, so for me I think this is why I preferred the 22.5792Mhz to 24.576, but I have a nagging thought that the maths told me I'd get closer to 8 with 22.5972 and that's what the wm wants. What does the ESS want ?
Anyway, I honestly can't remember if the pll in the wm8805 works the usual way above. I seem to remember it does something unusual so I'm afraid I'm not able to say if you are 100% correct. Have you checked the data sheet for this ?
Also consider - who's writing the code ? If you're doing it yourself then of course you can try both, and measure/listen to decide. If not you, what does the programmer say ? Also, IIRC the wm8805 is a bit of a pig for 88.2khz, 192khz material as it requires a reset (or something like this - my memory is fuzzy), so going with the programmers advice would make sense to me.
hey all
yes, its true, I am not looking forward to doing software for this chip. but I do PLAN to. I even bought a few more samples to burn^Htry.
I also do have this ebay/hongkong kit. its assembled and waiting for my code, in fact. I can switch between the included PIC controller and my own LCDuino, but I just have not finalized a few details of the code, so its not runnable yet.
if I get into trouble, I got myself a logic analyser and so, worst case, I could i2c-sniff what the 'factory firmware' does and see if I can at least do the same in my code.
has anyone confirmed that the factory code DOES actually lock-in and work at all samplerates?
one of the detours I took was wanting to get some source of all the samplerates. I got into the Audio Widget project, then created an spdif transmitter for it using the wolfson chip, but in hardware mode. it sends all samplerates if you give it i2s. I've personally confirmed that. but its the other way that we want: we want spdif IN and i2s or spdif OUT. in that mode, hardware won't support all the samplerates (as we all know). but I wonder if the ebay board in software mode DOES work in all rates?
update: I just tried playing every samplerate other than 32k. this is what I see from the ebay firmware and the wolfson chip:
44,48,88,96: all ok
176, I -think- gets passed thru (spdif meter says 176k but my dac does not play)
192 seems to get stopped and even mapped to 44k!
so, that's a first pass, informally, testing this ebay unit. I'm not convinced they have done a good job with firmware at all. unless I did something wrong, they did not support 176/192 properly.
44,48,88,96: all ok
176, I -think- gets passed thru (spdif meter says 176k but my dac does not play)
192 seems to get stopped and even mapped to 44k!
so, that's a first pass, informally, testing this ebay unit. I'm not convinced they have done a good job with firmware at all. unless I did something wrong, they did not support 176/192 properly.
linuxworks, there's Arduino code for WM8805 here -
https://github.com/kabturek/WM8805
Does this help?
https://github.com/kabturek/WM8805
Does this help?
yes, I did see that and I saved it away.
looking at it again, I see:
uint8_t WM8805::frequency(){
if(!is_locked()){
return 0;
}
//frequency is the 5:4 bits of pll6, we use the mask 48
uint8_t freq_bits = (this->spdstat & 48) >> 4;
if(freq_bits == 0){
return 192;
} else if( freq_bits == 1){
return 96;
} else if( freq_bits == 2){
return 44;
}
return 32;
}
unless I'm missing something, he's also leaving out 176. isn't that the 'thorn' in everyone's paw?
I also don't see 88k in there. I'll have a better look at the code to see what's going on. anything that compiles is a good start, isn't it?
looking at it again, I see:
uint8_t WM8805::frequency(){
if(!is_locked()){
return 0;
}
//frequency is the 5:4 bits of pll6, we use the mask 48
uint8_t freq_bits = (this->spdstat & 48) >> 4;
if(freq_bits == 0){
return 192;
} else if( freq_bits == 1){
return 96;
} else if( freq_bits == 2){
return 44;
}
return 32;
}
unless I'm missing something, he's also leaving out 176. isn't that the 'thorn' in everyone's paw?
I also don't see 88k in there. I'll have a better look at the code to see what's going on. anything that compiles is a good start, isn't it?
Yes, this is what I was really suggesting. That's how the Audio-Widget works - its microcontroller detects the source samplerate, then activates either of two XO's which is most suitable. This activation logic is via the "enable" pins on the XO's. Apparently the inactive XO has also has its outputs shorted.
So the big question is: can the WM8805 detect the samplerate of the incoming S/PDIF stream, and properly report this to a controller (such as Arduino) -
then the controller can be programmed to do the necessary enable/disable function for the two XO's.
Yes ... there's no "48" listed, either.
As I read the WM8805 datasheet, the "Recovered Frequency Flag" (REC_FREQ) cannot differentiate between 44.1 and 48, neither between 88.2 and 96.
To determine the exact samplerate, I'm guessing you would need to read from a different parameter of the WM8805;
possibly "Original Sampling Frequency" (ORGSAMP)
or "Indicated Sampling Frequency" (FREQ)
I see a danger with "Indicated Sampling Frequency" - it would rely on the incoming S/PDIF source to have properly implemented this flag in its transmitted stream.
But in the case of the Arduino code from kabturek, differentiating between 44.1/48 and 88.2/96 might not actually matter. It just depends on what he is using the "freq_bits" variable for.
In our case, however, we're aiming to use optimised XO's, and possibly dual XO's as I described in my previous post. In this case, determining the correct source samplerate is critical.
I don't think it can can have two xo freq because each freq requires different code in the register. But perhaps it is possible to re-write the register ? Seems like another added level of complexity that may not bring any benefit due to the way the pll works. But maybe not, if the register has to be changed to handle 192 ? Or is there simply a mode change to get 192 to work ?
One thing I remember reading is that the device is pre-configured for a 12Mhz xo and that this will work for 32-96 khz, but if I wanted anything else the device register has to be changed. So of course, this is why the ebay boards use 12mhz and probably explains why 192 doesn't work.
On that tack, wouldn't a 24.576mhz clock be the best choice for 192khz material ? It might be the only rate that gives N and r as 8, and thus, best performance ?
IIRC wm8805 won't do 176.4 ?
One thing I remember reading is that the device is pre-configured for a 12Mhz xo and that this will work for 32-96 khz, but if I wanted anything else the device register has to be changed. So of course, this is why the ebay boards use 12mhz and probably explains why 192 doesn't work.
On that tack, wouldn't a 24.576mhz clock be the best choice for 192khz material ? It might be the only rate that gives N and r as 8, and thus, best performance ?
IIRC wm8805 won't do 176.4 ?
Last edited:
Sure. Since we have a microcontroller on hand, make it work! Otherwise the microcontroller is not really doing much - just initialising the WM8805 with preconfigured settings at each power-up.
So the WM8805 should inform the uC of any change of samplerate, then the uC should change the XO if the new samplerate requires it.
There just remains the issue of how the WM8805 detects and reports incoming samplerate.
That's exactly what I was suggesting/asking in my earlier post.
According to the datasheet, the WM8805 definitely supports 176.4. The problem is that it cannot discern between 176.4 and 192 - this is worse than the previous situation I explained where the "REC_FREQ" flag does not differentiate between 44.1 and 48, 88.2 and 96 - those are simply how the chip outputs samplerate information. But in the case of 176.4 and 192 kHz, the chip literally cannot identify one from the other - see page 29 of the datasheet.
One solution is user intervention - I imagine you would need to have some form of LCD display connected to the controller, and be programmed to display something like:
"176.4/192 kHz
Please select
1. 176.4
2. 192"
Kludgey? Yes. But I don't see any other way. We're limited by the capabilities of the WM8805.
Oh, I should mention that I'm not desperate for a dual-XO solution, myself.
My main interest in S/PDIF is for feeding audio (stereo, not multichannel) from DVD/Blu-Ray/media-decoders into a hifi.
This is all either 48 or 96 kHz - so a WM8805 with 24.576 XO will be fine for me.
I just imagine that others who want a high quality S/PDIF receiver would want optimised clocking for both 44.1 and 48 kHz samplerate families.
My main interest in S/PDIF is for feeding audio (stereo, not multichannel) from DVD/Blu-Ray/media-decoders into a hifi.
This is all either 48 or 96 kHz - so a WM8805 with 24.576 XO will be fine for me.
I just imagine that others who want a high quality S/PDIF receiver would want optimised clocking for both 44.1 and 48 kHz samplerate families.
let me throw this out there, just for grins:
how about using 2 receivers? a cirrus one (that works in hardware mode, perfectly) and the wolfson. one would be there to 'help' the cpu know what the real freq is. the other would actually pass traffic thru.
I have half of it working, kind of. an 8416 chip in hardware mode that locks onto ALL the samplerates. it gives me a word clock output and that is fully trustable. from that, I can run a software freq counter on the arduino and display (or at least know) the SR. this much work today. my code for that much is here:
http://www.diyaudio.com/forums/digi...b-interface-audio-widget-177.html#post3125474
note, that there are 2 conceptual ways to know the samplerate. there's what's on the wire (in terms of real word clock freq) and then there's what's in the payload of the data packets (there's a samplerate that the sender encodes in the bitstream and also a word depth, iirc). problem is, I believe those are not fully trustable. I have heard of bad transmitters who don't encode the right 'rate' in the data but the data still 'works'. it might be cool to have a tool that shows the real and sensed rates. but the real rate is the only one we need and care about to decode audio thru the wolfson.
the cirrus is supposed to have higher jiitter and be a lower quality part than the 8805 but I don't mind having it HELP the cpu get the bit rate correct. its not a super expensive part and does not take up too much space (its a lot bigger than the wolfson but at least its lead pitch is easier to solder, lol).
another idea I had: take the RAW spdif stream, divide it down and freq count it, with its data and clock NOT decoded. yes, the freq will 'wander' a bit but it will be close to something that we can ID as 44,48,88,96, etc. a freq to voltage converter can do a rough approx and the cpu (arduino) can do an a/d and get a general idea of what the rate is. certainly it would know what rates its NOT at (if it gets a very low freq, it can't be the 96-192 rates, etc). it might be an accelerator for the processor that way.
still, I like the 8416 idea in that it works and works well. no hackery needed, just get the word clock, freq-count it and you're done. you then KNOW, for sure, what rate you are at, on the wire.
then simply set the wolfson given the info we learned 'out of band'.
not sure that multiple xo's is the direction I'd go in. sounds expensive, more pcb routing hassle, more clocks 'in the vicinity' that I don't really want and this isn't a dac and should not need multiple xo's.
I don't fully understand all the implications of selecting clock freq's in software mode, though. so I'm not the one to comment on that, per se.
how about using 2 receivers? a cirrus one (that works in hardware mode, perfectly) and the wolfson. one would be there to 'help' the cpu know what the real freq is. the other would actually pass traffic thru.
I have half of it working, kind of. an 8416 chip in hardware mode that locks onto ALL the samplerates. it gives me a word clock output and that is fully trustable. from that, I can run a software freq counter on the arduino and display (or at least know) the SR. this much work today. my code for that much is here:
http://www.diyaudio.com/forums/digi...b-interface-audio-widget-177.html#post3125474
note, that there are 2 conceptual ways to know the samplerate. there's what's on the wire (in terms of real word clock freq) and then there's what's in the payload of the data packets (there's a samplerate that the sender encodes in the bitstream and also a word depth, iirc). problem is, I believe those are not fully trustable. I have heard of bad transmitters who don't encode the right 'rate' in the data but the data still 'works'. it might be cool to have a tool that shows the real and sensed rates. but the real rate is the only one we need and care about to decode audio thru the wolfson.
the cirrus is supposed to have higher jiitter and be a lower quality part than the 8805 but I don't mind having it HELP the cpu get the bit rate correct. its not a super expensive part and does not take up too much space (its a lot bigger than the wolfson but at least its lead pitch is easier to solder, lol).
another idea I had: take the RAW spdif stream, divide it down and freq count it, with its data and clock NOT decoded. yes, the freq will 'wander' a bit but it will be close to something that we can ID as 44,48,88,96, etc. a freq to voltage converter can do a rough approx and the cpu (arduino) can do an a/d and get a general idea of what the rate is. certainly it would know what rates its NOT at (if it gets a very low freq, it can't be the 96-192 rates, etc). it might be an accelerator for the processor that way.
still, I like the 8416 idea in that it works and works well. no hackery needed, just get the word clock, freq-count it and you're done. you then KNOW, for sure, what rate you are at, on the wire.
then simply set the wolfson given the info we learned 'out of band'.
not sure that multiple xo's is the direction I'd go in. sounds expensive, more pcb routing hassle, more clocks 'in the vicinity' that I don't really want and this isn't a dac and should not need multiple xo's.
I don't fully understand all the implications of selecting clock freq's in software mode, though. so I'm not the one to comment on that, per se.
Attachments
Last edited:
what I'm hoping to use this chip for (8804/5), is the switch 'fabric' in an i/o selector box. there has to be a cpu there anyway, and also an lcd, IR receiver and serial back-end for remote web control. the 8805 does not even have to select inputs, for me; I'm happy enough handling the pure switching outside the chip. I mostly wanted the chip as a reclocker. its advertised as such, isn't it?
and I do absolutely need to support every valid sample rate. I don't have a lot of each, in my collection, but there are actually files out there and people are going to want to -play- them and not convert them to play them.
I've sent every valid rate into the 8416 and its word clock locks on, well, every single time. I know it sounds funny to leverage one part like this, but hey, it -will- give you a very fast and trustable 'this is whats on the wire' Fs. no need to talk to it, either! you could, if you want; but what I have working now is a 2-step, where the 8416 runs in unattended hw mode, it just locks on, I sniff its wordclock with an arduino and that counts freq in software (part of its 'sketch'). you then know the currently playing song's Fs.
and I do absolutely need to support every valid sample rate. I don't have a lot of each, in my collection, but there are actually files out there and people are going to want to -play- them and not convert them to play them.
I've sent every valid rate into the 8416 and its word clock locks on, well, every single time. I know it sounds funny to leverage one part like this, but hey, it -will- give you a very fast and trustable 'this is whats on the wire' Fs. no need to talk to it, either! you could, if you want; but what I have working now is a 2-step, where the 8416 runs in unattended hw mode, it just locks on, I sniff its wordclock with an arduino and that counts freq in software (part of its 'sketch'). you then know the currently playing song's Fs.
Attachments
Last edited:
here's what I'm using (or, was using, just as I paused this project several months ago) for a test bed.
I was not going to use i2c to talk to the wolfson. my plan was to go SPI and use opto couplers to level-convert and also fully isolate the arduino junk from the wolfson (junk). that's what the lite-on chip is on the perf. the other 8pin chip is an rs diff line driver so that I can send something like aes3 out of a rear jack (TRS). this is going to my behringer dcx2496 and so I wanted something closer to 5v than half a volt.
to put the wolfson into spi mode vs i2c mode, you have to init the chip and hijack some of its pins, then give them back to normal use. sigh. I hate that. but I think its easier to set the chip into spi mode and I'm all setup to do that, anyway.
I did actually find that arduino wm8805 code and I did convert it (enough) so that it fits inside my existing arduino infrastructure. but I didn't yet translate the i2c calls to my own spi calls. I think that's the last thing that I left off on, before I went and got side-tracked on a bunch of other things
I was not going to use i2c to talk to the wolfson. my plan was to go SPI and use opto couplers to level-convert and also fully isolate the arduino junk from the wolfson (junk). that's what the lite-on chip is on the perf. the other 8pin chip is an rs diff line driver so that I can send something like aes3 out of a rear jack (TRS). this is going to my behringer dcx2496 and so I wanted something closer to 5v than half a volt.
to put the wolfson into spi mode vs i2c mode, you have to init the chip and hijack some of its pins, then give them back to normal use. sigh. I hate that. but I think its easier to set the chip into spi mode and I'm all setup to do that, anyway.
I did actually find that arduino wm8805 code and I did convert it (enough) so that it fits inside my existing arduino infrastructure. but I didn't yet translate the i2c calls to my own spi calls. I think that's the last thing that I left off on, before I went and got side-tracked on a bunch of other things
Attachments
There is nothing to gain using a fancy oscillator with a frequency that is a multiple of the expected sample rate. The bit and word clocks output by the WM880x are always synthesized to match the incoming S/PDIF sample rate.
I recently considered the Wolfson part for a DAC I am designing but rejected it because the DPLL must be reprogrammed to switch between 192K, 176.4K, and other sample rates when the chip is in software control mode. Instead I will use a CS8416 in slave mode. I have two XOs, one for each sample rate group, but only one will be powered-on at a time. A synchronous counter will provide all the DAC clocks and export a word clock to the PC. A micro will read the sample rate from the S/PDIF channel status and select the appropriate XO and divider.
I recently considered the Wolfson part for a DAC I am designing but rejected it because the DPLL must be reprogrammed to switch between 192K, 176.4K, and other sample rates when the chip is in software control mode. Instead I will use a CS8416 in slave mode. I have two XOs, one for each sample rate group, but only one will be powered-on at a time. A synchronous counter will provide all the DAC clocks and export a word clock to the PC. A micro will read the sample rate from the S/PDIF channel status and select the appropriate XO and divider.
Hi guys,
Linuxfan - what will trigger the re-write ? Is there anything in the wm8805 that can be exploited so the re-write is done automatically ? I thought that the mcu only writes at start-up (I'm pretty sure that is what happens with these ebay boards), so we would have to disable the wm and then start it up again to write from a different mcu ? Have I missed something ?
Also, I'm pretty sure the PLL is not straightforward, so the ONLY frequency when R is an integer (8, the same as N, so K =0) is 192khz with a 24.576 xo. There's a table in the datasheet that gives suitable values for 22.5792 and 24.576 xo's. I remember looking at that and thinking that the best xo is not necessarily any particular freq, but simply the one with the lowest phase noise etc. If the cchd-957 was available in 12Mhz, I'd just go with that.
Anyway, I'm still undecided about this so I'd like to get some input from a programmer and/or someone with experience about this .... anyone ? Little help ? 2 xo's or one ? Which freq(s) or doesn't matter ?
For the 192/176.4 issue, well it looks to me like we need two options - auto select and manual select. When auto select doesn't work, we can just manually select any of the possible incoming freq from 32 - 192. Hopefully the manual select can be used as a trigger to re-write.
Linuxworks - I've made a great effort to avoid parts like the cs because of their high jitter. I would probably not be interested in any solution that adds jitter and then later tries to take it away, unless it can be shown that this is fully effective. What do you think ? Will using the cs degrade the spdif signal in any way ?
cheers
Linuxfan - what will trigger the re-write ? Is there anything in the wm8805 that can be exploited so the re-write is done automatically ? I thought that the mcu only writes at start-up (I'm pretty sure that is what happens with these ebay boards), so we would have to disable the wm and then start it up again to write from a different mcu ? Have I missed something ?
Also, I'm pretty sure the PLL is not straightforward, so the ONLY frequency when R is an integer (8, the same as N, so K =0) is 192khz with a 24.576 xo. There's a table in the datasheet that gives suitable values for 22.5792 and 24.576 xo's. I remember looking at that and thinking that the best xo is not necessarily any particular freq, but simply the one with the lowest phase noise etc. If the cchd-957 was available in 12Mhz, I'd just go with that.
Anyway, I'm still undecided about this so I'd like to get some input from a programmer and/or someone with experience about this .... anyone ? Little help ? 2 xo's or one ? Which freq(s) or doesn't matter ?
For the 192/176.4 issue, well it looks to me like we need two options - auto select and manual select. When auto select doesn't work, we can just manually select any of the possible incoming freq from 32 - 192. Hopefully the manual select can be used as a trigger to re-write.
Linuxworks - I've made a great effort to avoid parts like the cs because of their high jitter. I would probably not be interested in any solution that adds jitter and then later tries to take it away, unless it can be shown that this is fully effective. What do you think ? Will using the cs degrade the spdif signal in any way ?
cheers
if you have to resort to manual select, it seems like an admission of failure
has anyone contacted wolfson and found out how its -supposed- to work? I have not done that yet but I would not be shy in doing so once I've run out of ideas.
my first idea was to examine the ebay board and watch what it does. sadly, it seems it 'punts' and does not support all the rates, anyway. studying it won't help me at all, I don't think.
I still have not dived deep enough into the specs, but I wonder - would a strategy be to scan between the 'confused' rates (if you can't tell between A and B, at least you know its one of those 2 and not any other) and watch for errors? one would be swamped with errors and the other would not. no?
has anyone contacted wolfson and found out how its -supposed- to work? I have not done that yet but I would not be shy in doing so once I've run out of ideas.
my first idea was to examine the ebay board and watch what it does. sadly, it seems it 'punts' and does not support all the rates, anyway. studying it won't help me at all, I don't think.
I still have not dived deep enough into the specs, but I wonder - would a strategy be to scan between the 'confused' rates (if you can't tell between A and B, at least you know its one of those 2 and not any other) and watch for errors? one would be swamped with errors and the other would not. no?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.