Hi
Where does the jitter start when we have Multiple clocked devices between the HDD and the DAC chip ?
My system: NAS device -> cat6 cable -> Switch -> cat6 cable -> SqueezeBox Duet Streamer -> spidf chinched cable -> DAC (W8804 CRYSTAL XO hardmode and FOX CRYSTAL XO close to ESS Sabre DAC Chip
Is the switch with its own clock a jitter source ? Or does the jitter only beginn to start after a buffer in transmission lines between the streamer and the DAC ? If the streamer have a buffer, can we talk of injected jitter before it ?
As I can hear difference with cables between streamer and DAC, is the streamer XO the faulty component despite the recloking of the hardmode spidf in the DAC chip ?
In one word : where the jitter beginn to be dangerous for sound here ?
Sorry, a lot of questions here, but will be pleased to understand more when we ca talk of synchronous transmission and jitter when music is stored on a hard disk. Do I just need to change the bad crystal of my streamer and use BNC and short cable between the DAC ?
Where does the jitter start when we have Multiple clocked devices between the HDD and the DAC chip ?
My system: NAS device -> cat6 cable -> Switch -> cat6 cable -> SqueezeBox Duet Streamer -> spidf chinched cable -> DAC (W8804 CRYSTAL XO hardmode and FOX CRYSTAL XO close to ESS Sabre DAC Chip
Is the switch with its own clock a jitter source ? Or does the jitter only beginn to start after a buffer in transmission lines between the streamer and the DAC ? If the streamer have a buffer, can we talk of injected jitter before it ?
As I can hear difference with cables between streamer and DAC, is the streamer XO the faulty component despite the recloking of the hardmode spidf in the DAC chip ?
In one word : where the jitter beginn to be dangerous for sound here ?
Sorry, a lot of questions here, but will be pleased to understand more when we ca talk of synchronous transmission and jitter when music is stored on a hard disk. Do I just need to change the bad crystal of my streamer and use BNC and short cable between the DAC ?
Still the problem starts in the Duet. However, you'll notice that the specific DAC you mention is not that affected by incoming jitter.
Thanks,
Hard mode is the opposite of software mode, this SPIDF reciever W8804 if can be used without Crystal XO if I'm right : this is the software mode. SB Duet have toslink but not the SUbbu, but good idea, I saw someone maid it with the Subbu. In my mind Toslink was far behind 75 ohms wire but maybe it was ten years ago...
ok, that's what I thought, studies are fare away...Its not VOIP here, we don't need delay regularity between the frames with TCP between HDD and the Squeezebox because its "big" jitter buffer.
We just need than TCP do its job here : wait all the packets and make a checksum to verify if no packet are lost and rebuild in the good orders the sended packet in the SB Duet before its bufer and it beginns its sending tasks (spidf output).
As I can hear huge difference between two SPIDF cables and can not use the usefull SONY jitter free transport protocol between the squeeze box and the DAC: what can I do ?
Here the DAC is the excelent SUBBU with its own clock for spidf input and the biger fhz XO near the chip for the best low possible jitter than this dac chip can do, does it worth to replace the XO of the device which manage the spidf output in the SB Duet streamer(E.g with the same Fox crystal used for Wolfson reciever, or is it the layout of the SB (from the input of rj45 to the spidf output)
...Or I would be forget it and begining to think to an another streamer ? (and of course avoid the chinch conector with a simple good shelded 75 homs wire directly soldered on both PCBs ?
In my mind the XO Crystal of the spidf input in the DAC is the master clock for transport. What do I miss here about the understanding of jitter in the SB Duet ? Is the jitter beginn between the XO of the RJ45 input device and the XO of the spidf output device ?
Is it the only problem we can have with the "noisy" spidf cables and jitter or are there too another problems after than "datas" are debufered an then converted into time domain electric impulsion (i supose clock and data are multiplexed in time domain here because just one wire with spidf ?)... Well i think here about ground loops, thermal noise and all the things I don't understand as well.
Sorry for the confusion I'm lost here because my understanding after few readings is that in a good system spidf cable do not modify the sound : 2 ways : tweaking the SB (I have two), maybe add toslink to the Subbu Dac or change for a better LAN streamer... (the DAC itself is not the weak link of the both devices anymore since the arrival of the Subbu...)...
Hard mode is the opposite of software mode, this SPIDF reciever W8804 if can be used without Crystal XO if I'm right : this is the software mode. SB Duet have toslink but not the SUbbu, but good idea, I saw someone maid it with the Subbu. In my mind Toslink was far behind 75 ohms wire but maybe it was ten years ago...
ok, that's what I thought, studies are fare away...Its not VOIP here, we don't need delay regularity between the frames with TCP between HDD and the Squeezebox because its "big" jitter buffer.
We just need than TCP do its job here : wait all the packets and make a checksum to verify if no packet are lost and rebuild in the good orders the sended packet in the SB Duet before its bufer and it beginns its sending tasks (spidf output).
As I can hear huge difference between two SPIDF cables and can not use the usefull SONY jitter free transport protocol between the squeeze box and the DAC: what can I do ?
Here the DAC is the excelent SUBBU with its own clock for spidf input and the biger fhz XO near the chip for the best low possible jitter than this dac chip can do, does it worth to replace the XO of the device which manage the spidf output in the SB Duet streamer(E.g with the same Fox crystal used for Wolfson reciever, or is it the layout of the SB (from the input of rj45 to the spidf output)
...Or I would be forget it and begining to think to an another streamer ? (and of course avoid the chinch conector with a simple good shelded 75 homs wire directly soldered on both PCBs ?
In my mind the XO Crystal of the spidf input in the DAC is the master clock for transport. What do I miss here about the understanding of jitter in the SB Duet ? Is the jitter beginn between the XO of the RJ45 input device and the XO of the spidf output device ?
Is it the only problem we can have with the "noisy" spidf cables and jitter or are there too another problems after than "datas" are debufered an then converted into time domain electric impulsion (i supose clock and data are multiplexed in time domain here because just one wire with spidf ?)... Well i think here about ground loops, thermal noise and all the things I don't understand as well.
Sorry for the confusion I'm lost here because my understanding after few readings is that in a good system spidf cable do not modify the sound : 2 ways : tweaking the SB (I have two), maybe add toslink to the Subbu Dac or change for a better LAN streamer... (the DAC itself is not the weak link of the both devices anymore since the arrival of the Subbu...)...
Last edited:
One sound topology is to eliminate the streamers effect on jitter and earth contamination. This is made by making the clock/D/A combo the master in the clock solution. This means that the clock domain in the streamer must be completely separated from the D/A clock domain. One way to do this is to buffer the audio data in a memory (FIFO) and clock the data out from the FIFO with the DA clock. On the DA side, the DA should be driven by the DA clock synchronously i.e. no rate adaption - nothing just the straight (low jitter) clock into the DA. This is what the "Ian FIFO / clock" on this forum is all about.
In your constellation the DA and streamer is asynchronously related via a phase locked loop. ("rubber band") in the receiver chip in the Subbu. Its the tradition solution around a spdif i/f. So "In my mind the XO Crystal of the spidf input in the DAC is the master clock for transport." is not correct - it's the SB that holds the master clock.
In your constellation you will probably also hear a difference changing the power feed to the streamer. Here is where galvanic isolation (i.e. Toslink) comes handy.
spdif carries two information in one serial line. Data as well as clock. This is a solution that is unfortunate as actually, in practice, the content has impact on the extraction of a stable clock. But "we" didn't understand this at the time. But hey, we saved a pair of connectors - that would have saved a panda or two.
A DAC is no better than the clock and data topology it can support. Given its limitation, I think you hit the god ol "cul the sac". This dosent mean that you might be able to squeeze some more ot of it still.
Good luck!
//
In your constellation the DA and streamer is asynchronously related via a phase locked loop. ("rubber band") in the receiver chip in the Subbu. Its the tradition solution around a spdif i/f. So "In my mind the XO Crystal of the spidf input in the DAC is the master clock for transport." is not correct - it's the SB that holds the master clock.
In your constellation you will probably also hear a difference changing the power feed to the streamer. Here is where galvanic isolation (i.e. Toslink) comes handy.
spdif carries two information in one serial line. Data as well as clock. This is a solution that is unfortunate as actually, in practice, the content has impact on the extraction of a stable clock. But "we" didn't understand this at the time. But hey, we saved a pair of connectors - that would have saved a panda or two.
A DAC is no better than the clock and data topology it can support. Given its limitation, I think you hit the god ol "cul the sac". This dosent mean that you might be able to squeeze some more ot of it still.
Good luck!
//
Last edited:
Thank you TNT,
I understand more things about my problem, i was thinking that the wolfson 8804 reciever in hardware mode with crystal input was a sort of FIFO and in fact I maid a mistake with the understandood of it.
Well my understanding with what you wrote is :
1) with two devices stremaer + DAC, the main XO is the masterclock and near the DAC chip, the Xo has to inject its tempo in the FIFO, this last near to the streamer to avoid jitter (= if the fifo is near the DAC chip, the streamer would send jitter in the FIFO and we want to avoid it with FIFO near the sending device... - but multiple FIFO?- )!
It remains something read in the ECDESIGNS thread that I surely missunderstood too. By the way in this last case it's about I2S and the clock is already alone in its wire and not multiplexed in time mode or frequency mode like it is in a standalone SPIDF wire. With this last my understanding of what you wrote is it seems to be that the spidf has another problem as well with the differents size of datas between two clock impulsion informations... which seems to be nearer of the multiplexing in time domain than frequency domain. Here the electrics impulsion for data are not like with TCP protocol where the size of the data (MTU) can be setup and are always the same if I understand? And supose as well than frequency and time domain when we sent an information are close concept...different frequencies have different time impulse... my knowledge is too poor here to understand !
2) Seems to be a too much complicate task without acurate knowledge in my case. And replace the standalone crystals XO in the streamer Squeeze Box Duet with better ones and use true 75 ohms connectors or Toslink mode (maybe I will be to be able to do that in the Subbu with the copy of the work shown by some fellows in the Subbu construction thread) can be best but far to be enough to solve the problem !
Well let's listen music instead to think to the last drosophils' outrages, i will listen to the excelent T. Monk's Paris 1969 concert and live with what I have (... before the next DIY step, our hobby is strange and ambitious).
Thanks again TNT for this didactic answer in relation to the jungle of my questions.
I understand more things about my problem, i was thinking that the wolfson 8804 reciever in hardware mode with crystal input was a sort of FIFO and in fact I maid a mistake with the understandood of it.
Well my understanding with what you wrote is :
1) with two devices stremaer + DAC, the main XO is the masterclock and near the DAC chip, the Xo has to inject its tempo in the FIFO, this last near to the streamer to avoid jitter (= if the fifo is near the DAC chip, the streamer would send jitter in the FIFO and we want to avoid it with FIFO near the sending device... - but multiple FIFO?- )!
It remains something read in the ECDESIGNS thread that I surely missunderstood too. By the way in this last case it's about I2S and the clock is already alone in its wire and not multiplexed in time mode or frequency mode like it is in a standalone SPIDF wire. With this last my understanding of what you wrote is it seems to be that the spidf has another problem as well with the differents size of datas between two clock impulsion informations... which seems to be nearer of the multiplexing in time domain than frequency domain. Here the electrics impulsion for data are not like with TCP protocol where the size of the data (MTU) can be setup and are always the same if I understand? And supose as well than frequency and time domain when we sent an information are close concept...different frequencies have different time impulse... my knowledge is too poor here to understand !
2) Seems to be a too much complicate task without acurate knowledge in my case. And replace the standalone crystals XO in the streamer Squeeze Box Duet with better ones and use true 75 ohms connectors or Toslink mode (maybe I will be to be able to do that in the Subbu with the copy of the work shown by some fellows in the Subbu construction thread) can be best but far to be enough to solve the problem !
Well let's listen music instead to think to the last drosophils' outrages, i will listen to the excelent T. Monk's Paris 1969 concert and live with what I have (... before the next DIY step, our hobby is strange and ambitious).
Thanks again TNT for this didactic answer in relation to the jungle of my questions.
Last edited:
Eldam, I wish to be completely frank with you. Reading your reasoning efter 1), I don't think You fully get the concept - sorry. I think you actually need to study the basic process of A/D and D/A conversion to fully grasp the challenges involved. Once you do this, it will be clear to you that the TCP/IP has nothing to do with jitter i.e. timing error between converting two samples of digital information into it's respectively analogue levels. The timing shall be exactly the time corresponding to the sampling rate at A/D process (omitting any oversampling). To accomplish this when the source of data (streamer) and the converter (SB) in two different boxes tied tighter with a spdif connection which only can transfer data and clock in one direction, is not easy.
There are two basic strategies:
- Let the clock near the D/A be the master and feed back the clock (i.e. opposite direction of data) to be used for data fetching so that no over or unde-run occurs. (this should have been spdif in my opinion)
- Let the data fetching process accuracy be not critical (spdif) and when the data has been fetched from the source, store it in a memory. On the other side of the memory, read it out with an other much more accurate clock which is the same that drives the D/A process.
Supere aude!
There are two basic strategies:
- Let the clock near the D/A be the master and feed back the clock (i.e. opposite direction of data) to be used for data fetching so that no over or unde-run occurs. (this should have been spdif in my opinion)
- Let the data fetching process accuracy be not critical (spdif) and when the data has been fetched from the source, store it in a memory. On the other side of the memory, read it out with an other much more accurate clock which is the same that drives the D/A process.
Supere aude!
I am not sure to understand all...
As i wrote i understand now than there is no problem betweenn Hdd and Squeeze Box.
Because my understanding is than here with protocol like TCP two samples.of data will be reconstruct in the right order and we can not talk about jitter here if HDD can see the Squeeze Box i.e. if no packet is lost i.e. if the connexion is not break in the case of our little domestic network. Jitter can exist with Data transport but in a domestic network it doesn t exist in the sense: the only task here is to transfers DATA, music is not played yet and we don t talk about informatic packet with D/A, this is not the jitter we talk about for music which is here after. Same concept but our problematic jitter for music is between SB and DAC...this nit anymore informatic DATA transfer. That just what i wrote...sorry if my english is so bad... Hope i undetstood the basics of datas transport protocol in the informatic domain...and understand after this is nit TCP (IP is not concerned here). If ihave a doubt I have none anymore rightnow.
Thank you for the two points, you right i have to.beginn with A/D concept and oversampling. Synchronising two transmission is surely what .i have to learn.
As i wrote i understand now than there is no problem betweenn Hdd and Squeeze Box.
Because my understanding is than here with protocol like TCP two samples.of data will be reconstruct in the right order and we can not talk about jitter here if HDD can see the Squeeze Box i.e. if no packet is lost i.e. if the connexion is not break in the case of our little domestic network. Jitter can exist with Data transport but in a domestic network it doesn t exist in the sense: the only task here is to transfers DATA, music is not played yet and we don t talk about informatic packet with D/A, this is not the jitter we talk about for music which is here after. Same concept but our problematic jitter for music is between SB and DAC...this nit anymore informatic DATA transfer. That just what i wrote...sorry if my english is so bad... Hope i undetstood the basics of datas transport protocol in the informatic domain...and understand after this is nit TCP (IP is not concerned here). If ihave a doubt I have none anymore rightnow.
Thank you for the two points, you right i have to.beginn with A/D concept and oversampling. Synchronising two transmission is surely what .i have to learn.
Last edited:
I think you go it! (Oversampling has nothing to do with jitter - it may have positive impact on others aspects of D/A conversion i.e. filter requirement).
There are many things affecting sound. I would try to remove as much metal around cables (connectors) and electronics. This has big impact on sound. Maybe larger than chasing the last fs of jitter.
Good luck in the future.
//
There are many things affecting sound. I would try to remove as much metal around cables (connectors) and electronics. This has big impact on sound. Maybe larger than chasing the last fs of jitter.
Good luck in the future.
//
Thank you again,
I will beginn with that as it's an easy tip and start to learn the reason of differents frequencies with Crystal XO when we have 2 devices (streamer and DAC devices) and how to have a Masterclock and inject that from a DAC to a streamer.... maybe I will to test on a little DIY PCB to apply and not break the squeeze Box.
I will beginn with that as it's an easy tip and start to learn the reason of differents frequencies with Crystal XO when we have 2 devices (streamer and DAC devices) and how to have a Masterclock and inject that from a DAC to a streamer.... maybe I will to test on a little DIY PCB to apply and not break the squeeze Box.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.