Well...I dont have a final advice yet. My tendency is currently to try to keep digital signal path short and clean. A Rasb4 or a N5100 are very good. I am not yet clear about PC as there a linear PSU is really expensive. Input cache in MPD is great. You get a core back...as ethernet needs no isolation any more...but usb isolation is important...i will try raspb4 with ian q7 in the next days with ultracap and battery supply compared to the rest...
The input cache in mpd works now...meaning: It loads for 2sec the whole song into RAM and than ethernet is not going to be used anymore...If you have large RAM like i have 16gb on the Pink Faun type of PC...you will have like 10-15 songs in Ram, even in HD. You use the ethernet no longer for receiving any data to be played...all your songs are already in RAM locally.
On the PC thing...I need to play a bit further with this...SOC which have a direct USB out or I2S out on Gpios have an advantage not going through other chips/busses/clocks...so, I am not a big fan of first making stuff messy to later than spend xxx$ for a usb card with oxco clocks. "Just dont mess up my signal from the beginning " i like better.
On USB vs I2S...no, that is not automatically a nobrainer. i2s is not automatically better sounding as you need as well isolators and u have to look if you really have a good clock on the source side and a straight i2s line from the Soc va. some more chips in between. So far its a toss.
On the PC thing...I need to play a bit further with this...SOC which have a direct USB out or I2S out on Gpios have an advantage not going through other chips/busses/clocks...so, I am not a big fan of first making stuff messy to later than spend xxx$ for a usb card with oxco clocks. "Just dont mess up my signal from the beginning " i like better.
On USB vs I2S...no, that is not automatically a nobrainer. i2s is not automatically better sounding as you need as well isolators and u have to look if you really have a good clock on the source side and a straight i2s line from the Soc va. some more chips in between. So far its a toss.
Last edited:
Thanks for explaining that so clearly. I wasn’t aware that’s what caused the problem in the first place. I assumed it was just contaminated power being passed from one device to another.
As a cheap experiment, I picked up a device that converts rj45 Ethernet to optical to isolate the network from the pi. Based on what you just explained, my expectations are low, but I’ll report back my findings anyway.
Most stand alone DACs connecting via USB have their own power source. Only the very low end take power from USB.
With USB2/3 the data is asynchronous, meaning the DAC will reclock the received data anyways so there is no worry about PC/streamer/source clock jitter. Isolating the network datalink by FULLY storing the files into DDR and then metering them out via an USB interface is simply... useless... because by definition the maximum data rate in a 100 baseT network is greater than the audio rates in a USB2 to a DAC. And ultimately, the DAC is going to do the buffering, so even if the data being streamed from ethernet to USB to the DAC is bursty, it's irrrelevant. The DAC will do its own clocking from its own DDR.
Indeed, we want the datalinks, ethernet and USB, to be bursty, because that way they are the most efficient.
SOC means System On a Chip. Nothing to do with this. You don't go out and buy an "SOC".
DACs hooked up to a motherboard current use PCI or PCIe. USB is for external devices. You could build a box that holds both the 'PC' and the DAC wired together using USB and their own power supplies but they would be electronically separate devices.
In the past, when I used PCI DACs I i did notice that the software would make a difference, but nowadays it all has moved to the hardware.
So, just get a cheap PC or Raspberry and a good USB DAC. Everything else is just toying around, won't make any difference.
Last edited:
I am not a roon guy...is roon using mpd ? can you edit /etc/mpd.conf ? You need to enable inpu cache there and specify its size like 1gb before it is activated. Sorry for not.being clear wnough....when i said it works, i meant: there have been times like 2-3 years ago where it did not work. Buffer_before_play was used than, but is now hardcoded to 1.sec i believe
Last edited:
By SOC, do you mean using something like a Raspberry?
I've been telling you... you are looking at the wrong part of the equation. So long as your PC/Raspberry/Android device can feed the USB DAC, the money /effort best spent is on the DAC. A $200 Samsung Tablet running Tidal into an RME over USB will blow high priced, highly tweaked front ends with mid/cheap USBs.
Oh, the Roon... just a closed system. Why bother, IMHO?
@312elements: What is the network source? If it's standard streaming (i.e. the pace controlled by the sender approximately at the playback rate), then caching means waiting for the stream to build up. You certainly do want to wait several hours for 1GB of stream data. Logically if you disconnect the network, the stream will interrupt. There is no reason to do so.
Which stream?
If you are streaming from the network and then driving a DAC with a reasonably sized data cache in between, then you are SWITCHING and BUFFERING the data.
Such designs are meant to allow for bursty datalinks... meaning the upstream might shut off and on but the data is being read from the cache, hence, in this case, the music won't stop until the cache empties out.
Of course, this requires the player to be aware of the caching. It should NOT stop playing just because the upstream connection times out, ONLY when the data in the cache empties.
@312elements: Where is MPD's place in your setup then? Does not roon-bridge use alsa directly? At least it is linked to libasound2, alsa user-space library. What effect mpd.conf has on your setup?
I perfectly agree with you about the burst nature of audio playback, all the way down to the DAC clock (i.e. to I2S as HDA bus is bursty too). But many network streaming protocols are bandwidth-limited and having a large cache results in a large playback latency.
Something like this division applies:
* Network files (SMB/NFS/etc): no bandwidth limiting - cache can be filled fast, large cache does not increase latency considerably.
* Standard internet streaming: pace controlled by the sender at audio pace, recipient must resample to its audio clock (proper adaptive resampling as in CamillaDSP or netjack or pulseaudio - none of these are related to streaming though
, bit dropping/stuffing as in gstreamer) - cache filled at audio pace, i.e. larger cache = comparably larger latency* Local audio streaming (Slim/squeezebox protocols, Roon, DLNA): recipient has a feedback which controls the pace at which the sender sends data (similar to USB isochronous explicit async). Typically that feedback is directly related to the client audio clock. Theoretically a client could request a faster pace to fill up its cache, but I do not know if any of that is available. If not - again cache filled at audio pace, i.e. larger cache = comparably larger latency.
Even though most (if not all) USB-to-I2S devices have buffers USB audio definition does not require this. Isochronous USB audio is not supposed to be bursty.
Asynchronous USB is isochronous as well. It does not cater for bursty communication.
...y.
* Standard internet streaming: pace controlled by the sender at audio pace, recipient must resample to its audio clock (proper adaptive resampling as in CamillaDSP or netjack or pulseaudio - none of these are related to streaming though
* Local audio streaming (Slim/squeezebox protocols, Roon, DLNA): recipient has a feedback which controls the pace at which the sender sends data (similar to USB isochronous explicit async). Typically that feedback is directly related to the client audio clock. Theoretically a client could request a faster pace to fill up its cache, but I do not know if any of that is available. If not - again cache filled at audio pace, i.e. larger cache = comparably larger latency.
(1) I drive Tidal HiFi masters at 24/96 rates off the Internet with an i7 laptop into a Nuforce DDA-100. No drops whatsoever even though I'm also doing video, email and browsing on the same machine.
(2) Slim, Squeebox, Roon, etc... are all closed development products and based on four or more years old technology. Many of those devices were stuck on isochronous Red Book USB-1 for over a decade after USB-2 had come out. PC based players and DACs had bypassed those products eons ago. I just don't bother with them at all.
(3) High speed Internet is common nowadays. Streaming data from source brought is throttled by the receiver over TCP/IP. No resampling done by the receiver. Data is then sent to DAC where it gets sampled as needed. Mostly it is native nowadays. Latency and cache size are not necessarily coherent... it is possible to fill the cache at a higher rate than it is being drained for playback.
By bursty, I mean looking at the bus and watching how data is sent in big batches. A few large batches.
You put a bus analyzer on it and you can see the transmission set up, the long burst transmission and the close down handshake. There is a data link clock for the transmission of the data but the "type of data" driven "decoding" clock, ie: red book, 24/96, DSD, is not part of the clock used for the transmission.
Last edited:
In USB audio host sends about the same amount of data in every (micro)frame. This is regardless of whether the isochronous audio endpoint is synchronous, asynchronous or adaptive. In USB audio only small variations of data rate are possible.