• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Buffalo II

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Okay, this is somewhat of a loaded question but I thought I would post here.

Does the Buffalo II, have a single ended or differential I2S output? Does this change whether you are using it in a dual mono configuration or just a single configuration?

I'm trying to see if I can use a Squeezebox Touch with an Empirical Audio Pacecar II w/I2S outs into the Buffalo II dac. Info regarding the Pacecar II reclocker (and info on the USB version as well) is here. The Pacecar II I2S output has to be configured for the dac it is going to supply, hence my question.

Thanks fellas,

Anand.
 
Touch spdif out to BII

Hi

I use the SB Touch spdif out; removed rca contact and soldered a 75ohm coax direct on Touch pcb wired to Buffalo II spdif input.
Here is how the Touch spdif signal looks like into the Buffalo II (0.1V pr div):

TouchSPDIF.jpg

I think this combination is good.

Best
Tom
 
Last edited:
I assume you mean I2S inputs...

They are single-ended.

Not sure what benefit you hope to get from the reclocker, as the buffalo a) is asynchronous and b) reclocks the signal you send it

Yes, I meant input, thanks!

Not sure what I will benefit either. In fact, I might want to try it first to see if it actually makes a big difference. I'll check with the manufacturer, Steve Nugent, as the Buffalo II, as you stated, takes care of the issue internally. However, I would like to feed it an I2S signal.

Have you found the Buffalo II with an I2S signal at its input to be superior sounding to same source with an SPDIF signal? That's probably the question to ask.

Hi

I use the SB Touch spdif out; removed rca contact and soldered a 75ohm coax direct on Touch pcb wired to Buffalo II spdif input.
Here is how the Touch spdif signal looks like into the Buffalo II (0.1V pr div):

View attachment 183592

I think this combination is good.

Best
Tom

Tom, thanks for insight.



Anand.
 
Dual mono Buffalo II and Legato

Brian and Russ,

If I were to purchase and utilize dual mono Buffalo II's, would I also purchase a pair of Legato boards? Would I configure them similar to your Dual Mono + IVY III pdf file seen here? And I take it that the I2S input in this dual mono configuration is still single ended and not differential?

I really like the idea of a discrete output stage.

Thanks,
Anand.
 
Hi Bob,
Have patience, with Russ and Brian the manual always come after the hardware:)
Just bomb them with questions and they will know what to write in the manual.....
Nic

Thanks NicMac

Are the parts that have x's through them on the Legato board the optional filter? What is the filter type?

I want to start by providing a separate supply for each IV converter. How are the switch or jumpers set?

Thanks

.
 
I want to start by providing a separate supply for each IV converter. How are the switch or jumpers set?

For separation, use no jumpers, and install each side's power terminal block.

And I take it that the I2S input in this dual mono configuration is still single ended and not differential?

They are single-ended.

Are the parts that have x's through them on the Legato board the optional filter?

They are an optional output buffer. I would wait for the manual there...
 
BII, I2S, reclocking, and jitter

With the Squeezebox Touch I would definately recommend you try a properly configured Pace Car via I2S, and get Steve's advice on I2S cabling and termination.
The ESS 9018 uses an onboard ASRC to resample and reclock the incoming data. While most measurements show that hardware based ASRC does reduce jitter (often to very low levels) most listeners have found that DACs using ASRCs are still sensitive to incoming jitter, and sound better when fed a low jitter data stream. If one reads all the responses on the buffalo threads, one will find that most users who experiment find that the Buffalo DACs also sound better when fed from a low jitter source. Personally I have yet to try the BII (on order though), but I expect it will respond well to being fed from a low jitter source, and sound even better when fed I2S. My experience with other ASRC solutions (like the TI 4192) has shown that although ASRC does reduce measured jitter, the DAC still sounds better every time one reduces the jitter level at the input to the ASRC. Some digital engineers have tried to explain why this is, saying that the ASRC reduces (actually they say "filters") the incoming jitter, but really just chages the jitter to other artifacts that demodulate to noise in the output of the DAC. I do not fully understand the process, but my listening experience suggests that it is always wise to feed a DAC (reclocking or not) the lowest jitter data stream possible, and that DAC claims like: "immune to jitter" are generally not true.
Please post your findings; I would love to know if the Touch-Pace Car-I2S-BII improves on the sound of Touch-SPDIF-BII.
 
With the Squeezebox Touch I would definately recommend you try a properly configured Pace Car via I2S, and get Steve's advice on I2S cabling and termination.
The ESS 9018 uses an onboard ASRC to resample and reclock the incoming data. While most measurements show that hardware based ASRC does reduce jitter (often to very low levels) most listeners have found that DACs using ASRCs are still sensitive to incoming jitter, and sound better when fed a low jitter data stream. If one reads all the responses on the buffalo threads, one will find that most users who experiment find that the Buffalo DACs also sound better when fed from a low jitter source. Personally I have yet to try the BII (on order though), but I expect it will respond well to being fed from a low jitter source, and sound even better when fed I2S. My experience with other ASRC solutions (like the TI 4192) has shown that although ASRC does reduce measured jitter, the DAC still sounds better every time one reduces the jitter level at the input to the ASRC. Some digital engineers have tried to explain why this is, saying that the ASRC reduces (actually they say "filters") the incoming jitter, but really just chages the jitter to other artifacts that demodulate to noise in the output of the DAC. I do not fully understand the process, but my listening experience suggests that it is always wise to feed a DAC (reclocking or not) the lowest jitter data stream possible, and that DAC claims like: "immune to jitter" are generally not true.
Please post your findings; I would love to know if the Touch-Pace Car-I2S-BII improves on the sound of Touch-SPDIF-BII.

Wow! Thanks for the insight. I'm in agreement with you at least theoretically. It's just that the whole report of 'immune to jitter' has been repeated many times over by digital engineers. There is probably more going on here than just jitter.

I have a feeling that I2S is the better way to go and for that reason alone, I am planning on getting a Touch->Pace Car II. As long as the Buffalo II (dual mono) accepts a single ended I2S signal, we are game.

Anand.
 
Ahhh...

you must be posting over at CA as well! The B-II accepts a single ended I2S signal.
It is too bad that products like the Hiface Evo do not offer a differential I2S output, as this is a superior way to send I2S signals. If more folks used differential I2S, it would be more likely to be accepted as a better digital interface between components. Sorry for the OT rant...
 
you must be posting over at CA as well! The B-II accepts a single ended I2S signal.
It is too bad that products like the Hiface Evo do not offer a differential I2S output, as this is a superior way to send I2S signals. If more folks used differential I2S, it would be more likely to be accepted as a better digital interface between components. Sorry for the OT rant...

You mean AC.:eek:

Well originally, I wanted to see if the Pacecar II outputs a differential I2S signal. It doesn't :no:. Or else I would go with the RAKK dac Mk III (which only accepts differential I2S - yes a superior method). So I was off to plan B:bulb:...sorry for the OT post.

Anand.
 
Regarding Legato.

The parts with Xs are parts that would be omitted if you don't wish to use the output buffer.

There are 4 transistors with lines next to two pads. Those pad need to be jumpered together if you wish to omit the buffer.

The output impedance is very low even without the buffer. So unless you have a load < 4K or so You could omit the buffer. The circuit generates less heat because it uses less current without it.

I will get the manual done tonight. I just need to add some pictures etc.

Cheers!
Russ
 
Last edited by a moderator:
With the Squeezebox Touch I would definately recommend you try a properly configured Pace Car via I2S, and get Steve's advice on I2S cabling and termination.
The ESS 9018 uses an onboard ASRC to resample and reclock the incoming data. While most measurements show that hardware based ASRC does reduce jitter (often to very low levels) most listeners have found that DACs using ASRCs are still sensitive to incoming jitter, and sound better when fed a low jitter data stream. If one reads all the responses on the buffalo threads, one will find that most users who experiment find that the Buffalo DACs also sound better when fed from a low jitter source. Personally I have yet to try the BII (on order though), but I expect it will respond well to being fed from a low jitter source, and sound even better when fed I2S. My experience with other ASRC solutions (like the TI 4192) has shown that although ASRC does reduce measured jitter, the DAC still sounds better every time one reduces the jitter level at the input to the ASRC. Some digital engineers have tried to explain why this is, saying that the ASRC reduces (actually they say "filters") the incoming jitter, but really just chages the jitter to other artifacts that demodulate to noise in the output of the DAC. I do not fully understand the process, but my listening experience suggests that it is always wise to feed a DAC (reclocking or not) the lowest jitter data stream possible, and that DAC claims like: "immune to jitter" are generally not true.
Please post your findings; I would love to know if the Touch-Pace Car-I2S-BII improves on the sound of Touch-SPDIF-BII.

Hey hey, just wondering...
OK, let's assume that an asynchronous connection is inmune to jitter (Ethernet is in fact inmune to jitter. Otherwise it wouldn't be as reliable as it is). Brian clearly states in this quote that Buffalo II works asynchronous.
So one of both you is wrong.
Not sure what benefit you hope to get from the reclocker, as the buffalo a) is asynchronous and b) reclocks the signal you send it


And then I think to my self...why audiophile world has that jitter social drama? I mean, in telecommunications world digital links are widespread and nobody has corrupt transfer or detectable problems with them.
They are more complex protocols, but what makes it "jitter-resistant" is a very simple error correction protocol. I mean, if ethernet devices are cheap and easy to develop, why not develop a tenfold times simpler protocol for audio?
When I use a pendrive to transfer a file I have no doubt that it will remain intact, bitperfect (this word sounds funny in this area, because bitperfectness is asumed). Are "audio bits" different from picture bits or ascii bits?

Regards,
Regi
 
regi...

I think you may need to do a little researching into jitter in audio. A pen drive can indeed transfer all your data without bit errors, as does any reasonable digital audio interface. Jitter in audio has nothing to do with bit errors, it is the timing of the data at the converter. Jitter is a non issue for data transfers, as they are not time sensitive. A serial audio data stream is entirely time sensitive at the converter though.
There is no such thing as "jitter free" digital to analog conversion. One can only attempt to achieve the lowest possible level of jitter. I have been involved in listening tests where different audio interfaces were tested with the same DAC; the only differences were the level of jitter in the interface. Everytime a lower jitter interface is used, sonics improve. If one is attempting to achieve the best possible sonics in a digital to analog converter, jitter is an important issue, and it will pay sonic dividends to do everything possible to achieve the lowest jitter.
If one only wants to achieve "acceptable" performance, then one may choose to ignore jitter.
Assuming asynchronous transfer is jitter free is in error, as is stating a DAC is "immune" to jitter.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.