No, but there is no error correction (parity bits, etc) in the digital streams. It is a question of syncing the clocks and data in a non-buffered system.
Yup,
Brian, I do not disagree with any of your statements here, I was just responding to Regi directly. Also, to be entirely clear, all the statements I have made are a matter of my opinion, based on my experiences (listening) and communication (theory) with a handful of digital engineers.
As far as reclocking twice, I can think of a number of reasons why someone might choose to do this, but primarily: not all reclocking ciruits produce the same results. A hardware based ASRC will not necessarily produce the same results as well managed large buffer which reclocks its output with fixed frequency clock(s), rather than a PLL. I do believe the "Pace Car" product is an Async re-clocker with high precision fixed frequency clock(s) at its output and no PLL circuit-this type of reclocker (subject to proper implementation of course) will outperform an ASRC/PLL type of circuit in terms of jitter.
I suspect (but do not know, I have yet to try a B-II, mine is coming later) that the B-II, like other DACs which use ASRCs, will benefit from being fed the lowest possible jitter data stream. I understand that ESS' ASRC implementation is different, (than "traditional" parts like the TI 4192) and accept that it may perform better than the other ASRCs I have experience with.
Brian, I do not disagree with any of your statements here, I was just responding to Regi directly. Also, to be entirely clear, all the statements I have made are a matter of my opinion, based on my experiences (listening) and communication (theory) with a handful of digital engineers.
As far as reclocking twice, I can think of a number of reasons why someone might choose to do this, but primarily: not all reclocking ciruits produce the same results. A hardware based ASRC will not necessarily produce the same results as well managed large buffer which reclocks its output with fixed frequency clock(s), rather than a PLL. I do believe the "Pace Car" product is an Async re-clocker with high precision fixed frequency clock(s) at its output and no PLL circuit-this type of reclocker (subject to proper implementation of course) will outperform an ASRC/PLL type of circuit in terms of jitter.
I suspect (but do not know, I have yet to try a B-II, mine is coming later) that the B-II, like other DACs which use ASRCs, will benefit from being fed the lowest possible jitter data stream. I understand that ESS' ASRC implementation is different, (than "traditional" parts like the TI 4192) and accept that it may perform better than the other ASRCs I have experience with.
I'm a noob with digital audio transmissions so pardon me if I state the obvious.
If we're talking asynchronus transfer from the source to the dac the transfer should indeed be jitter free since the dac is recieving a bit correct lump of data.
Since jitter is time dependent the only jitter source should be the D/A conversion and the dac's internal clock?
Am I missing something here?
If we're talking asynchronus transfer from the source to the dac the transfer should indeed be jitter free since the dac is recieving a bit correct lump of data.
Since jitter is time dependent the only jitter source should be the D/A conversion and the dac's internal clock?
Am I missing something here?
It is...
not actually truly asynchronous in this sense. A PLL is used to reconcile the rate of the incoming data with the rate of the DAC clock; therefore, the level of jitter present at the converter is somewhat dependent on the jitter level of the incoming data. A truly asynchronous interface would use a fixed clock and no PLL(s).
not actually truly asynchronous in this sense. A PLL is used to reconcile the rate of the incoming data with the rate of the DAC clock; therefore, the level of jitter present at the converter is somewhat dependent on the jitter level of the incoming data. A truly asynchronous interface would use a fixed clock and no PLL(s).
Would it be possible to implement a buffer to store the incomming data before actually sending it through the d/a?
Just pop the value at the top of the stack?
Just pop the value at the top of the stack?
Markus...
Yup. Like Russ said, the Ethernet based players work this way. Gordon Rankin's Streamlength async USB code is similar: it clocks out of an onboard buffer with fixed frequency oscillators, and the code manages the data transfer from computer to buffer to make sure there are no overuns or underuns. PS Audio's PerfectWave transport works the similarly, reading the spinning disc into memory (managed by the code) and clocks out of the memory with fixed frequency oscillators.
The key to getting the lowest jitter with these systems is to eliminate the PLLs, and manage the buffers so that fixed frequency clocks can be used on the output this results in jitter at virtually the inherent jitter of the clock itself. Without a big enough buffer, with proper management, timing errors will eventually add up and the buffer will overflow, or under run, resulting in lost samples and dropouts.
I assume (oops, should never do that...) the new USB receiver that TP is developing will work this way as well.
Yup. Like Russ said, the Ethernet based players work this way. Gordon Rankin's Streamlength async USB code is similar: it clocks out of an onboard buffer with fixed frequency oscillators, and the code manages the data transfer from computer to buffer to make sure there are no overuns or underuns. PS Audio's PerfectWave transport works the similarly, reading the spinning disc into memory (managed by the code) and clocks out of the memory with fixed frequency oscillators.
The key to getting the lowest jitter with these systems is to eliminate the PLLs, and manage the buffers so that fixed frequency clocks can be used on the output this results in jitter at virtually the inherent jitter of the clock itself. Without a big enough buffer, with proper management, timing errors will eventually add up and the buffer will overflow, or under run, resulting in lost samples and dropouts.
I assume (oops, should never do that...) the new USB receiver that TP is developing will work this way as well.
TPA XMOS USB Interface
Dear Russ,
please would you shed some light on the progress of your XMOS-USB 2.0 for the Buffalo II.
matthias
Dear Russ,
please would you shed some light on the progress of your XMOS-USB 2.0 for the Buffalo II.
matthias
Yes!
X2, I am very excited about the possibility of a sota USB-I2S interface for the B-II.
X2, I am very excited about the possibility of a sota USB-I2S interface for the B-II.
Just to clearify, the new USB module is not specifically for the Buffalo, though it will work perfectly well with it. It will also feed our other DACs, as well as anything else that will accept PCM (I2S).
Any chance it'll support multi-channel configurations for things like active multi-amping?
Cool. I *think* the Linux/Alsa driver is set up for multichannel, but I guess it's time to start looking into it.
Russ, could you enlighten us as to some proposed dimensions and power supply requirements for the USB-IS2 interface?
I'm headed to England shortly where it will be much cheaper for me to get a modushop case for buffalo/usb transport and need to know what sort of size to get.
Cheers,
Phil
I'm headed to England shortly where it will be much cheaper for me to get a modushop case for buffalo/usb transport and need to know what sort of size to get.
Cheers,
Phil
Hi,
I am new to DYI electronics, so help with the following would be greatly appreciated. Well, the first q is the part list. I plan to start with stereo version of Buffalo II and then move to the dual-mono version with an option of driving headphones. Here is the part list:
2x Buffalo II kit (assembled PCB + Placid PSU)
2x I/V-III Kit (assembled PCB + Placid PSU)
Volumine
Volumite Controller
Volumite firmware (stereo + dual mono)
2x (9+9V) transformer for DAC boards
2x (15+15) transformer for I/V boards
S/PDIF Transreceiver
Ballsie
What power supply should be ordered to feed S/PDIF transreceiver and Ballsie? Is one Placid BP sufficient to feed both?
/Dmitry
I am new to DYI electronics, so help with the following would be greatly appreciated. Well, the first q is the part list. I plan to start with stereo version of Buffalo II and then move to the dual-mono version with an option of driving headphones. Here is the part list:
2x Buffalo II kit (assembled PCB + Placid PSU)
2x I/V-III Kit (assembled PCB + Placid PSU)
Volumine
Volumite Controller
Volumite firmware (stereo + dual mono)
2x (9+9V) transformer for DAC boards
2x (15+15) transformer for I/V boards
S/PDIF Transreceiver
Ballsie
What power supply should be ordered to feed S/PDIF transreceiver and Ballsie? Is one Placid BP sufficient to feed both?
/Dmitry
- Status
- Not open for further replies.