Whats the point of an enable pin being there if all you have to do is turn it off? i'm well aware that it 'works' having done it myself for years. but how exactly does leaving it off remove the output from being in parallel? this is definitely a last 1% solution, but as I see it, its a real phenomena.
thats the whole point of having a tristate clock/buffer, otherwise the output of the buffer is left hanging there in parallel with the input clock, rather than being put into a hi-Z state. not applying power does not correct this, the buffer is still there. the effect is bound to be minimal, but its there and I believe it was of some significance in Ians testing
thats the whole point of having a tristate clock/buffer, otherwise the output of the buffer is left hanging there in parallel with the input clock, rather than being put into a hi-Z state. not applying power does not correct this, the buffer is still there. the effect is bound to be minimal, but its there and I believe it was of some significance in Ians testing
Last edited:
i'm sure it allows faster cycling/reaction than switching it on and off, probably starts up quicker, but is that really it?
no enable pin? what? whats the E/D (Enable/Disable) then? yes, exactly, the E/D pin puts it into a hi-Z state so it does nothing ...
no enable pin? what? whats the E/D (Enable/Disable) then? yes, exactly, the E/D pin puts it into a hi-Z state so it does nothing ...
Last edited:
ahh sorry Brian, you are still using a variant of the 950 yes? the 957 have an enable pin. not sure what impact that has on the internal structure though.
what I meant was, in a situation where you might have 2 clocks sharing a line, say with dual clock operation here in audio; if you simply used power cycling to turn them on or off, then there is a good chance it would take longer to switch on/off vs waking a disabled clock from a sleep state. would probably be less predictable too
I was providing counterpoint, another reason for an enable pin being there if switching it off had the same effect. I do wonder if the fact it doesnt have one, really means its effectively not there if not on. Are the internal structures that different with 950 vs 957? to me, if its not to do with the waking up bit, I dont know another explanation for them putting an enable pin on the clocks that are similar to 950, but designed for situations where they might share a clock line. (as they are only available in audio clock speeds for 44.1/48x)
what I meant was, in a situation where you might have 2 clocks sharing a line, say with dual clock operation here in audio; if you simply used power cycling to turn them on or off, then there is a good chance it would take longer to switch on/off vs waking a disabled clock from a sleep state. would probably be less predictable too
I was providing counterpoint, another reason for an enable pin being there if switching it off had the same effect. I do wonder if the fact it doesnt have one, really means its effectively not there if not on. Are the internal structures that different with 950 vs 957? to me, if its not to do with the waking up bit, I dont know another explanation for them putting an enable pin on the clocks that are similar to 950, but designed for situations where they might share a clock line. (as they are only available in audio clock speeds for 44.1/48x)
Last edited:
Reponse of Kingwa (Designer Audio GD)
The DSP1 jitter control have not contact with the source clock frequency.
Usually high frequency is better.
Kingwa
comments?
Last edited:
My understanding from talking with Crystek is that the enable pin has both advantages: ability to keep the oscillator powered and stabilized, and to revert the output to high impedance (I have not confirmed this second point, but it would make sense).
From the CCHD-957 data sheet:
It also features a “Standby Function”, that is, when placed in disable mode, the internal oscillator is completely shut down in addition to its output buffer being placed in Tri-State.
It also features a “Standby Function”, that is, when placed in disable mode, the internal oscillator is completely shut down in addition to its output buffer being placed in Tri-State.
So, opposite of what I said. Hi guys,
can somebody please enlighten me - should my setup be able to play above 192kHz?
Amanero - FIFO KIT & Si570 - sync to Buff II
I'm only getting loud crackling noise at 352 and 384kHZ. Not sure if I've overseen something or if there's a natural limitation in this setting.
Thanks!
can somebody please enlighten me - should my setup be able to play above 192kHz?
Amanero - FIFO KIT & Si570 - sync to Buff II
I'm only getting loud crackling noise at 352 and 384kHZ. Not sure if I've overseen something or if there's a natural limitation in this setting.
Thanks!
what firmware version and board revision of fifo have you got?
could you have accidentally changed the Si570 frequency range from the default: Group 4?
Amanero has not always proven to be the most cooperative in sync mode with the highest resolutions (are you using ackos reckock?) we need pics
how have you connected to BII?
are all the connections from fifo to BII the same length?
how long are they?
have you definitely disabled the power for the onboard clock on the BII?
what frequency indicator LED on the Si570 board is lit?
could you have accidentally changed the Si570 frequency range from the default: Group 4?
Amanero has not always proven to be the most cooperative in sync mode with the highest resolutions (are you using ackos reckock?) we need pics
how have you connected to BII?
are all the connections from fifo to BII the same length?
how long are they?
have you definitely disabled the power for the onboard clock on the BII?
what frequency indicator LED on the Si570 board is lit?
qusp, thanks for your input!
what firmware version and board revision of fifo have you got?
- newest, from GB IV
could you have accidentally changed the Si570 frequency range from the default: Group 4?
- just checked, it's on 4
Amanero has not always proven to be the most cooperative in sync mode with the highest resolutions (are you using ackos reckock?) we need pics
- no, straight from Amanero to FIFO with under two inch cable
how have you connected to BII?
- see pics
are all the connections from fifo to BII the same length?
- yes
how long are they?
- 6 inch, from Ian
have you definitely disabled the power for the onboard clock on the BII?
- yes
what frequency indicator LED on the Si570 board is lit?[/QUOTE]
- 90khz when playing 352khz and 98khz when playing 384khz files
So apparently the signals leaves the Si570 intact, then something might be wrong from there on. Maybe you can spot something!?
what firmware version and board revision of fifo have you got?
- newest, from GB IV
could you have accidentally changed the Si570 frequency range from the default: Group 4?
- just checked, it's on 4
Amanero has not always proven to be the most cooperative in sync mode with the highest resolutions (are you using ackos reckock?) we need pics
- no, straight from Amanero to FIFO with under two inch cable
how have you connected to BII?
- see pics
are all the connections from fifo to BII the same length?
- yes
how long are they?
- 6 inch, from Ian
have you definitely disabled the power for the onboard clock on the BII?
- yes
what frequency indicator LED on the Si570 board is lit?[/QUOTE]
- 90khz when playing 352khz and 98khz when playing 384khz files
So apparently the signals leaves the Si570 intact, then something might be wrong from there on. Maybe you can spot something!?
Attachments
Have you tried slow roll off mode?
When my synchronous FIFO and BII picked strange noise at DXD 352.8khz playback, slow roll off solved that.
And, changing DPLL bandwidth under sharp roll off mode also changed the noise behavior.
However, this might not to be the kind of solution you want...
When my synchronous FIFO and BII picked strange noise at DXD 352.8khz playback, slow roll off solved that.
And, changing DPLL bandwidth under sharp roll off mode also changed the noise behavior.
However, this might not to be the kind of solution you want...
Have checked power supply voltage while trying 352.8k or higher SR playback?
At least, 1.2V supply of ES9018 consume more current as SR increase.
At least, 1.2V supply of ES9018 consume more current as SR increase.
Dual clock board question
Please excuse my ignorance. To use the u.fl connectons out of the dual clock board I don't have to do anything extra (i.e., output is always available at both J3 & J7/J8/J9)? I could not get a dac to work using u.fl and J7-8-9 but it works fine with J3 and regular cables. I am pretty sure it's the dac, but just wanted to verify I did not miss anything obvious. I didn't use MCLK from the dual clock board.
Please excuse my ignorance. To use the u.fl connectons out of the dual clock board I don't have to do anything extra (i.e., output is always available at both J3 & J7/J8/J9)? I could not get a dac to work using u.fl and J7-8-9 but it works fine with J3 and regular cables. I am pretty sure it's the dac, but just wanted to verify I did not miss anything obvious. I didn't use MCLK from the dual clock board.
Subbu/JP ES9023 V3 beta, I populated the dac side (nothing on the spdif side) and used the u.fl connectors to J7-8-9 but never got any sound, works fine with pins and cable to J3. Probably something I did wrong on the dac side. Thanks for the quick answer qusp.
no problem,
got pics? I remember their u.fl connections were a bit like an afterthought, grounding looked odd, the shells of the connectors are definitely grounded at the DAC end?
got pics? I remember their u.fl connections were a bit like an afterthought, grounding looked odd, the shells of the connectors are definitely grounded at the DAC end?
Thanks a lot wktk! You've nailed it with this one!
The 1.2V Trident just goes on it's knees on everything over 192khz, it goes down to 0,86V. Had to raise the voltage on Placid all the way to 6V to get around 1V out of Trident - just to confirm it playing.