no confusion between the two
Is that an oxymoron? Surely a decent system would eliminate jitter? But truth has it that jitter is only audible when the timing errors are significant. Actually by significant I’m referring to jitter of maybe 1 or 2μs (millionths of a second.) Take the afore mentioned Allo DigiOne and it has jitter 0.4ps (million millionths of a second.)
Anyway, I’m reliably informed that tapping your feet while listening to music means there’s no jitter. 
Thanks, I think I understand this better. I think the “latency” referred to is the tendency of a busy operating system to have to wait a millisecond or two to switch a new task into ‘running’ because all of its threads are busy doing something else. Reducing the number of things the OS is doing should reduce that tendency. So, sort of a commercial alternative to ROCK, as I understand it. Be interesting to hear more.
And the “distortion” resulting from too much “latency” would be non-linear snaps, crackles, and pops, I assume.
Most of the threads are suspended most of the time. A super-duper OS that supposed eliminates threads and thereby improves sonics, is unnecessary. Any modern CPU has more than enough juice to process audio files without resorting to eliminating threads that aren’t going to be executed most of the time.
Oh yeah, the time penalty wouldn’t be milliseconds, but nanoseconds. How much would depend on the clock, since that is what’s timing the fetch and execution of instructions.
One would certainly think so. However, that rather busy AudioLinux web page has lots of measurements and graphs which may demonstrate otherwise. Can’t say that I saw that, in my admittedly superficial scan of the page. Don’t seem to be any head-to-head tests against ROCK, for instance. And the fact that they bundle a desktop into it makes me wonder.
One thing to remember is that lots of people in the world are not using modern CPUs. My Roon Core was recently running on a Core 2 Duo. So perhaps AudioLinux is aimed at not-so-modern CPUs.
1 Like
This is all immaterial with RAAT. Take a look at this:
Of course, you wouldn’t want to pipe TV Audio through a buffering scheme like this. But for music listening, streaming latency doesn’t matter because we are free to pre-fetch data out of your files–and we can solve user experience latency while keeping our large buffer sizes by buffering faster than real time, so even though we have 10 seconds of buffer in the chain, playback still starts in a few hundred milliseconds or less.
https://community.roonlabs.com/t/raat-vs-aoip-protocols/33573/6
1 Like
I think you described it well and better than I. I’d love to read a comparison between AudioLinux and ROCK and may have to try that myself. One of the benefits of AudioLinux is that you can run HQPlayer on it. This is not possible with ROCK.
You can strip down AudioLinux even further, and run it without the desktop as command line, and headless.
1 Like
If you are going to redefine the meaning of latency and distortion to suit your theory then anything is possible in your world. Those words have very specific meanings, as does the word buffer. As Martin posted above, use of appropriate transmission protocols removes any issues with ‘latency’, however you want to define it.
1 Like
Not my theory and I didn’t redefine the meaning of anything. I’m well aware of the meanings of these words.
The comment I made was that one thing caused another. I also said I could be wrong as I was re-stating what someone else said. You may be surprised about what you don’t know. How do you know for certain that latency doesn’t impact sound quality.
In discussions like this it is important to keep the apples and the oranges distinct.
There are two general ways for a computer to send audio information in Roon:
A direct connection, usually by USB or SPDIF; and
A network connection, usually via Ethernet. Roon supports a number of particular network protocols, but let’s talk about RAAT for current purposes.
A direct connection carries with it the possibility of the computer affecting SQ. There are discussions about the effect of the protocol, the power supply and other sources of interference including CPU activity. You can spend as much as you want tweaking and improving your computer to avoid or minimise the affect a directly connected computer has on SQ.
A network connection using RAAT transmits packets using TCP/IP. These packets are then buffered in the Output device (in my case a microRendu) which has a direct connection to the DAC.
The use of TCP/IP as the network protocol completely isolates the Output device from any timing issues in the Core computer. No one worries about the effect of latency of TIDAL’s servers on SQ because the file is streamed asynchronously using TCP/IP. You could, in theory, use carrier pigeons and smoke signals to transmit the packets. Sometimes I think TIDAL does 
.
So for a network connection using RAAT I would discount Core computer latency as a factor that could affect SQ.
What about a Roon Bridge device ? Well it is a computer and it is directly connected, so the possibility of influence exists. That is why people use minimal hardware and software in such devices. RAAT helps here by enabling the best clock in the system to control the timing. Using a minimal OS for such devices is conventional wisdom.
2 Likes
Thank you for the non derogatory, intelligent response. It’s refreshing.
To put some context around the latency discussion and link I shared, it was specifically regarding a Roon bridged device. The topic of discussion which most recently brought this about was a NUC with Audiolinux running Roon Bridge. The Roon Core server was a high powered device, also running Audiolinux.
1 Like
Because buffering and because this:
1 Like
I took statistics and I’m not talking about network latency. Did you read Andy’s response?
How do you know the processor’s buffers aren’t too small? How do you know whether interrupts aren’t impacting the processor? How do you know the drivers don’t impact access to the processor or maybe the buffers are too big? How do you know latency doesn’t impact sound quality?
OK. How would we be able to measure the impact an OS has on performance?
Your ears combined with input from others who hear similar benefits. Until someone with the right tools can conduct a scientific study and publish them.
You can use a Pi with a HAT that provides an SPD/IF output like the Hi Fi Berri Digi, or the equivalent IQ Audio (can’t remember the model that provides digital out).
I don’t see any advantage of using a full blown PC for just an endpoint, especially not one with Windows running on it, with lots of irrelevant processes going on in the background. That would probably apply almost as well to a full blown Linux desktop distro. ROCK would be overkill, if you’re just using it for an endpoint. If you want to run your core on the same box, different story.
1 Like
I just ordered a Canakit Pi 3 B+ to try as an endpoint. No hat. Just use the USB from the Pi out to my Mytek DAC, like this guy does. $61 including 32GB card.
Well, you could try a test setup like this one. Use different OSs on the Pi and see if the results change.
But is it possible?
To run ROCK as “only” roon endpoint?
I have a NUC with a Pentium N3700 with a very low TPD of 6 Watts waitung here to try.
Yes, it should be possible.
1 Like