WM8805 upgrade board (cs8414 pins) - dissapointed

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
I hoped not - but I wasn't sure what you were describing because I don't have much technical experience with logic controls etc.

If so, then the spdif signal will be sent to two devices and they will probably need a buffer before them. I would also prefer to avoid this unless the buffer can also improve the signal.

I've seen the lengths that IanCanada has gone to in his fifo project to clean up an i2s signal, so I know it's not simply a case of paralleling two different devices and them not affecting each other.

So I'd go for a simple selection menu using up/down keys:

>------ to 96
88.2
>
48
>
44.1
>
32
>
AUTO
>
192
>
176.4
>
96-------to 88.2

...but I don't think this is easy to do either. Anyway, just my 2 cents. I don't see this as a defeat - I love cars that have a manual and an automatic gearbox; be lazy or take charge :)

Actually, all I'd like is 1) a better xo, 2) a better pcb. But damn, they made it tricky. I saw elsewhere that someone contacted Wolfson abiut this and got a - read the datasheet - answer. Perhaps they think it's simple !
 
Last edited:
since the wolfson can take 'dirty spdif' and clean it up, I would not worry too much about whatever front end 'damage' you do ahead of it. I doubt any buffering would matter, if their design does what it says. now, after the chip, that's perhaps another matter. that's the 'clean side'.

but a splitter (in buffer form) seems harmless enough to me.
 
Linuxfan - what will trigger the re-write ? Is there anything in the wm8805 that can be exploited so the re-write is done automatically ?
Yes - the "INT_N" flag. The INT_N flag indicates that any of several status modes (including samplerate) has changed. The controller should then read the Interrupt Status Register (INTSTAT) to learn which mode changed. We're only concerned with samplerate change, so the controller could go ahead and reassess the incoming samplerate, but I think it's also necessary to read the INTSTAT register, if only to clear the INT_N flag. If the INT_N flag is not cleared, no further samplerate changes can be flagged.


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 think this is a clever solution! I suspect you would need to pay some attention to isolation of the S/PDIF signal between the WM8805 and CS8416 - since they would be seeing the incoming signal in parallel.


another idea I had: take the RAW spdif stream, divide it down and freq count it, with its data and clock NOT decoded ...
...
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.
Urgh, that's messy. But I think you're on the right track - get the controller+WM8805 to do some probing/analysis of the S/PDIF stream.
As I look again at the datasheet, I think the "TRANS_ERR" flag might be what you need -
When the REC_FREQ flag indicates 192kHz, the appropriate N and K values should be (re)written for this samplerate ...
but of course the stream might be 176.4, so the controller should then immediately check for success/failure - by reading the "TRANS_ERR" flag. If errors are detected, then write N and K values for 176.4 (or better still, keep the same N/K values, and change the XO !)
then check for success/failure again.
If errors are still detected, I suggest the controller should recheck both rates again, before aborting with an error on the display.
 
I'm seeing quite some resistance to the idea of dual XO's, so let me recap why I understand this to be beneficial:

1. DACs benefit from using an XO which is most compatible with the source samplerate; 45.1584 MHz (and multiples/divisors) for 44.1 kHz family, 49.152 MHz (and multiples/divisors) for 48 family.

2. Though not widely acknowledged, there are some reports that sharing a common XO between a S/PDIF transport device (WM8805 in this case) with its associated DAC yields an audible improvement over the same setup with the two devices connected to separate and independent XO's.

So the dual-XO concept is mainly to benefit the DAC, not S/PDIF receiver, but if the two devices are sharing their XO, then obviously the S/PDIF receiver needs to switch XO when the DAC does.
This synchronous clocking regime is popular with the current crop of high end USB receivers.

3. Even though the WM8805 will reconstruct the external clock with its internal PLL, it's feasible (!!) that the PLL might work a little better if it only has to multiply by a neat factor (8) without any fractional component.

This latter point is what I was seeking clarification about in my first post ...
 
I feel I'm shooting quite blind, on this chip, since I don't really know what's going on INSIDE.

does the 'system freq' you run the chip at matter? I have a feeling it does not, but I don't have firm data either way. in fact, its one thing I'd like to confirm via experiment. we can change stuff and see if the result generates cleaner audio.

back to the dual-receiver idea; I don't see why isolation is needed between the 2 receivers. you could have a bunch of 'listeners' plugged into a bus: not sure why that would mandate any isolation between them. they are listening, not doing anything TO that signal. what happens downstream is none of any (other) input's business ;)

in terms of the freq counter part being messy, yes, and no. yes, its an extra stage, but no, its less work (for me) since the cirrus chip is run in pure hardware mode. there's nothing to get incorrect, there ;) you put it in hw mode, watch its word clock and that's the definitive Fs that we need to use in the 'real' receiver chip. the trick is whether I can do the freq counter stuff in the same arduino or if I'd need another one (maybe an 8pin attiny for that).
 
improved version of Wolfson convertor

It appears the infamous Hui Raindrop has an improved version of their converter that may or may not work .
It would be decent of this person to offer this improved version (that is of course if it in fact works) at a considerable discount due to the numerous unhappy customers they have scammed .

(WM8805 ת CS8412 ÒôƵ½ÓÊÕÄ£¿é-ÌÔ±¦Íø)
 
Hi,

An externally hosted image should be here but it was not working when we last tested it.

CCHD-957 US$30 ~15 to 20dB better
An externally hosted image should be here but it was not working when we last tested it.

Tent Labs US$40 similar to XO91 but with a lower noise floor
page20_4.jpg

hi,

You cannot simply compare phase-noise plots of oscillators with different base frequencies.

best,
=
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.