Digital Audio can be the data (.WAV file). Is can be a bit stream of that data (the .WAV file sent over Ethernet). It can be an actual digital audio signal, like the I2S from a streamer to a DAC or the I2S from the USB Receiver board (in a DAC) to the DAC chip.
USB 1.0 did a terrible job with audio.
Yes, indeed, the U stand for Universal. That means we have an agreed upon spec that is easy to implement. It does not mean we have the best / most accurate method of getting a digital audio signal into the DAC chip (or FPGA).
USB for Audio today is not the best example of a thing being used for some other purpose. But, USB 1.0 was not built for high resolution / quality audio. People used it anyway. It has been improved. But you still need to do a fair amount of buffering, translating, unpacking and re-clocking in the DAC to get your hands on a signal that a DAC can convert to analog.
There’s a flaw in your logic: We already had Ethernet for
why did we need USB?
The DAC chip needs I2S (yes, I know that some DACs do not work internally with I2S)
The “Streamer” or “Endpoint” needs Ethernet.
Who needs USB? It’s unnecessary packing and unpacking, translating and translating back.
You keep mentioning “quality” when talking about USB. The only “quality” a digital transport can provide is data integrity and bandwidth. USB 1.0 high speed could go up to 12Mbps, which is, at least in theory, enough for 192/24.
USB is a standard, like Ethernet; that’s why we need it. It makes it possible to use a streamer or a PC or a Pi or anything that can send data through USB. Based on your logic, Ethernet is also unnecessary packing and unpacking, modulating and un-modulating back; why not just use a PCI sound card in the Nucleus?
Nope. It became a standard because enough people thought we needed it. Hardware manufacturers could have made their cameras and printers communicate over Ethernet, an existing standard at the time. But they opted for something better.
I2S is used to transmit a clocked digital audio signal.
You originally stated:
A DAC chip does not need data, a DAC chip needs a digital audio signal.
Since the USB clock is not used for audio. And master clock responsible for clocking audio is owned by the DAC, I don’t see any benefit in reclocking USB (or Ethernet for that matter either). These clocks have no relation to audio clocks, they just facilitate data transfer between two RAM buffers.
I don’t use DAC chips in my system, I use DACs. I don’t need to know if a DAC uses a chip or an FPGA or any other kind of discrete components, and I don’t need to know what I2S is. What I care about is the ability to plug it into my digital audio sources, all of which have USB ports. If a streamer DAC takes Ethernet, all the better, as long as it also takes USB. That’s as far as I will entertain a USB-bashing conversation.
2 Likes
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
154
I’m not sure you are understanding what I’m saying. When I say that the frequency of packets on the USB connection “doesn’t matter”, I mean that it matters to the sound just about as much as the number of stumps on a given acre of land in a wooded area of Alberta. That frequency isn’t involved in the sound. So it doesn’t affect it. So it doesn’t matter. Not everything one could possibly think of actually matters to the SQ.
Something else that is true: lots of things you never think of do impact the SQ. And just as a chain is only as strong as the weakest link, a digital audio reproduction system is only as accurate as the least accurate sub-component in the signal chain.
I’ve built streamers and DACs with off the shelf USB receive boards. I’ve designed and made I2S send boards. I’ve written kernel drivers to accept external clocks and create digital audio signals. I’ve built power supplies, clock routing circuits, galvanically isolated and non-isolated connections.
But, more importantly, I’ve listened (ABX tests) and had many other people do the same.
You and I are on different paths. Mine is right for me. It sounds like yours is right for you.
Why not just run Roon Core on a Dell Laptop and connect the USB output to a DAC?
I can’t think of any reason not to. My case is a bit different though: core is running on an HP laptop, not Dell, and there’s no DAC connected to it, as I am using 3 zones:
desktop PC with USB DAC
Pi/RoPieee on Ethernet with USB DAC
Pi/RoPieee on WiFi with USB DAC
I almost always stream red book and I’ve never had any issues with dropouts.
I am looking into building a DAC myself. The plan is to use an XMOS board (USB-to-I2S) and a discrete 4-bit D/A stage running at 64fs, driven by a software delta-sigma modulator. It’s just for fun, to try my hand at hardware for a change; nothing to do with SQ.
@Kevin_Welsh As a manufacturer and seller of equipment intended to solve problems of a somewhat subjectivist nature, your contributions to this thread can hardly be described as objective or unbiased. You’re pushing a profit-based agenda here which I suspect has not gone unnoticed by Roon’s management…
Reading these countless posts of very unscientific audiophile catch phrases one expression comes to mind: that wonderful marketing term of FUD, Fear, Uncertainty and Doubt
After all one doesn’t become very rich selling vastly overpriced cables and accessories without knowing a little something about marketing.
2 Likes
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
165
Well, maybe. But I think of lots of things. Chaotic mind, I’m afraid. So at best, I think, there might be a few things I never think of that do impact the SQ. Not lots. Maybe none.
