Trying to get things straight... Squeezebox VS DACs
Aug 31, 2007 at 6:23 PM Post #16 of 29
Quote:

Originally Posted by sejarzo /img/forum/go_quote.gif
Maybe I mistated my previous question/comment, and this would be clearer.

Because of the nature of ethernet protocols of any sort, the music data stream coming from the server would have to be buffered and then reclocked internally to get to the internal DAC too, wouldn't it?



True.

Quote:

Does the SB3 take in the data from the network connection, buffer and reclock, convert to and send it in parallel via S/PDIF to the digital output and to an internal S/PDIF receiver which in turn feeds it to the internal DAC....or what???


There is no S/PDIF conversion before the D/A chip. It is I2S inside directly to the D/A chip, just like most stand-alone DAC's. The S/PDIF output is just like most transports. The analog circuit is what is different. It is a simple circuit with single power supply, unlike most good stand-alone DAC's which use dual power supplies and are DC-coupled. In this small size, you cannot expect it to have all of the features of an expensive stand-alone DAC.

Steve N.
 
Aug 31, 2007 at 6:51 PM Post #17 of 29
Thanks for clearing that up. I wasn't trying to imply anything about the quality of the D/A-to-analog out circuitry in the SB3, one way or the other.

So now, what I don't get is this.....the 0404 USB, as you have noted, does essentially the same thing. Why does it matter what protocol or interface is used for the PC-to-buffer data interface, as long as it can reliably feed the data fast enough to the buffer, and the buffer can reclock the data correctly to the D/A chip? Why would the SB3 using ethernet inherently have an advantage over any USB implementation? Or did you mean an implementation within the standard Windows USB Audio Device category?

Thanks again!
 
Aug 31, 2007 at 7:41 PM Post #18 of 29
The SB uses (wireless) ethernet to send the data (music) from the Slimserver on your PC to the SB. Ethernet has built in error checking. What arrives is what was sent. The noise from the PC including EMI and RFI is left behind. Any PC issues from interrupts or the like do not affect the SB. The DAC in the SB can be modded to quite high quality but the PS is a low quality switcher and should be replaced.
Mr. Nugent offers a device to reclock the data and thereby lower the jitter to inaudible levels. Its said to work quite well, I wish I could afford it. I have 2 SB's with improved PS's and ouboard DAC's and am satisfied for now.
 
Aug 31, 2007 at 8:48 PM Post #19 of 29
Quote:

Originally Posted by sejarzo /img/forum/go_quote.gif
Thanks for clearing that up. I wasn't trying to imply anything about the quality of the D/A-to-analog out circuitry in the SB3, one way or the other.

So now, what I don't get is this.....the 0404 USB, as you have noted, does essentially the same thing. Why does it matter what protocol or interface is used for the PC-to-buffer data interface, as long as it can reliably feed the data fast enough to the buffer, and the buffer can reclock the data correctly to the D/A chip? Why would the SB3 using ethernet inherently have an advantage over any USB implementation? Or did you mean an implementation within the standard Windows USB Audio Device category?

Thanks again!




Here is the difference. for networked devices like the Squeezebox and Sonos, the streaming audio data is just like any other data. It is packetized and then sent to the destination whenever it can arbritrate cycles on the network, just like printer data or web data. There is error checking although errors are the exception. The timing information is added at the destination device.

The 0404 uses USB protocol and Windows/MAC audio drivers software and DSP. This is part of the audio infrastructure of PC and MAC. It is designed to do a lot more including DSP: volume control, mixing, sample-rate conversion etc.. It is also used to communicate system noises to the user as well as music and game noises. It is also designed to stream audio data to the PCI bus for add-in cards, or USB ports. This extra overhead and functionality can cause problems, like drop-outs or non bit-perfect data. The stream cannot be interrupted, so for USB it typically uses isochronous streaming, which has no error correction. The timing information comes from the computer clock/software. It is possible to have great USB streaming audio data, but is more difficult to get really low jitter than the networked case.

Steve N.
 
Aug 31, 2007 at 9:07 PM Post #20 of 29
Does using the 0404 USB (or another ASIO compatible device) via ASIO change that in any way?

Do you know if there anything proprietary about the way the SB3 or other Slim Devices products handle the whole conversion chain from ethernet to I2S in terms of hardware? Poking around their site didn't provide any ready answer to that.

I think you get what I am driving at.......there are a number of ways to get data in a speedy fashion from a PC into an external device, regardless of interface or protocol, and to a non-EE engineer who understands most of audio from more of a "block diagram" point of view, it seems the interface is not the issue--it's clocking to the D/A, right?

Are designers simply limited by what chips are out there for specialized tasks?

Is there a need for some other standard beyond ASIO for external devices that would allow there to be a more direct USB>buffer>I2S>DAC chip chain?
 
Aug 31, 2007 at 9:32 PM Post #21 of 29
The Macs have an optical output to feed a DAC. Which I've been told is better to use than USB. I have a MacBook and SB3. I've used it in a mid-fi speaker set up and have been very, pleased. I've also used the analog out to Hornet, HD600/Cardas with good results. I have yet to add a "higher" end DAC in the mix.
 
Aug 31, 2007 at 10:47 PM Post #22 of 29
Optical requires a conversion at both ends by less than optimal hardware. It does offer relief from interference generated by electrical devices.
Using a packet switched network to transmit the data removes almost all the noisy PC and hard drive issues.
Initially, I felt that USB devices offered the most advantages for playback quality for a reasonable outlay but gradually came to feel that getting the PC environmental noise remote was superior. Headphone listening however, serves to add its own measure of isolation. The pops and crackles generated by a PC in going from one interrupt to another seem to offer a large challenge that packet switched networking sidesteps entirely.
 
Sep 1, 2007 at 6:58 AM Post #23 of 29
So far I am led to believe that an Ethernet (wired and wireless) connection in effect offers "bit perfect" data as well as removing all noise related to the PC. So why is it still prefered to use USB on relatively expensive DACs and not Ethernet (which I think the Zhaolu D3 might have).
confused.gif


Here's a question of the Empirical Audio people.

In any case why not create an Offramp Turbo 2 equivalent that is an Ethernet to SPDIF connector ? (just a thought).

biggrin.gif
 
Sep 1, 2007 at 1:24 PM Post #24 of 29
The D3 has a TG-Link interface that just happens to use an RJ45 jack. It's not ethernet, but a special system that requires an interface card in the PC.

USB is not inherently "un-bit-perfect" or noisy. If it could not transfer data reliably and quickly, printers and external HD's wouldn't work. It's the use of the USB in isochronous mode that prevents proper error correction.

The noise on a USB bus, as far as I know, should only significantly impact a device that used strictly USB power to run the D/A and output stages. Again, all we really need from the USB connection is the correct data, and the balance of a high-quality USB audio device should run on external power supplies.
 
Sep 1, 2007 at 3:02 PM Post #25 of 29
Quote:

Originally Posted by Jigglybootch /img/forum/go_quote.gif
Well, I've never head the output of a Squeezebox, but I'd imagine pretty much all mid and hi-fi DACs would be better than the one in the Squeezebox.


It depends on how you would define those classes, but the SB3 is undervalued as a DAC around here, and I haven't seen it outclassed until you get near the 1K mark (and even then it's not a drastic defeat). I have one as a source in my secondary setup and have at times considered selling the Lavry to redistribute the money and use a SB3 on my primary.
 
Sep 1, 2007 at 4:47 PM Post #26 of 29
Quote:

Originally Posted by Audio Jester /img/forum/go_quote.gif
So far I am led to believe that an Ethernet (wired and wireless) connection in effect offers "bit perfect" data as well as removing all noise related to the PC. So why is it still prefered to use USB on relatively expensive DACs and not Ethernet (which I think the Zhaolu D3 might have).
confused.gif


Here's a question of the Empirical Audio people.

In any case why not create an Offramp Turbo 2 equivalent that is an Ethernet to SPDIF connector ? (just a thought).

biggrin.gif




I could spend time designing this, but why? There are already the SB3 and Sonos which allow wireless WiFi and have great user interfaces with a lot of engineering invested in them. SB3 is third generation now. Instead, I have spent my time doing the Pace-Car, which adds on to these to significantly reduce jitter.

Steve N.
Empirical Audio
 
Sep 1, 2007 at 4:49 PM Post #27 of 29
Quote:

Originally Posted by lextek /img/forum/go_quote.gif
The Macs have an optical output to feed a DAC. Which I've been told is better to use than USB. I have a MacBook and SB3. I've used it in a mid-fi speaker set up and have been very, pleased. I've also used the analog out to Hornet, HD600/Cardas with good results. I have yet to add a "higher" end DAC in the mix.


The Toslink may be better than some of the inexpensive USB converters and DAC's, but not the better USB converters with low-jitter clocks. My converters also provide the same galvanic isolation that you get with the Toslink.

Steve N.
 
Sep 2, 2007 at 8:23 PM Post #28 of 29
Quote:

Originally Posted by Audio Jester /img/forum/go_quote.gif
.......In any case why not create an Offramp Turbo 2 equivalent that is an Ethernet to SPDIF connector ? (just a thought).
biggrin.gif



Quote:

Originally Posted by audioengr /img/forum/go_quote.gif
I could spend time designing this, but why? ......Instead, I have spent my time doing the Pace-Car, which adds on to these to significantly reduce jitter.


I do understand that there is a lot to the other side of the solution......compatibility with various OS's, player software, user interface, etc. However, from a fundamental engineering viewpoint, not creating the problem in the first place is always preferable than fixing it later, isn't it?
 
Sep 3, 2007 at 4:48 AM Post #29 of 29
Quote:

Originally Posted by sejarzo /img/forum/go_quote.gif
I do understand that there is a lot to the other side of the solution......compatibility with various OS's, player software, user interface, etc. However, from a fundamental engineering viewpoint, not creating the problem in the first place is always preferable than fixing it later, isn't it?


The Pace-Car does much more than "fix" the jitter problem. It also generates an I2S bus, which keeps the jitter low until it reaches the D/A chip. This is superior to changing to S/PDIF.

Designing my own version of the SB3 or Sonos is simply not possible in my company. I do not have the financial or staffing resources to do this. It is a huge investment. Instead, I provide a device that accomplishes the same thing for a much lower investment, and I dont need to get FCC approval and licensing for it. The Pace-Car is also a more universal device that can be used with SB3, Sonos, Olive, AirPort Express, USB converters and even transports with word-clock inputs.

Steve N.
Empirical Audio
 

Users who are viewing this thread

Back
Top