While I share your overall skeptisim about the “problem”, software jitter does appear in some literature. Here’s a (locked) IEEE paper that mentions it.
Is there any sound quality improvement with the new Roon 1.8? What are the improvements, if any?
Can you find a single definition of it? Let alone a way of measuring it? Or even proof that were it to exist, it would resist well-understood and implemented techniques of buffering.
When I turn my tap on, the water comes out at the same speed whether or not it is raining at the reservoir 40 miles away. This is because “weather jitter” has been competently dealt with.
The problem is that the two ideas are being misconstrued. I’ll grant software jitter exists in the context of response times, cpu context switching, resource contention etc. The spinning wheel is a form of jitter if you like.
But that doesn’t mean that any of those things can affect sound quality. If I am building software on a pi at the same time as playing music, the music may “skip” because the bus is overloaded and it is unable to pass the bits to the sound card in time before its buffer runs out. But its not going to be more or less airy, or any other amazing descriptor. Its either going to be playing or not. A very small buffer on the endpoint entirely takes care of this, permitted you aren’t doing stupid things on said endpoint.
The first paper both defines and proposes a method of measurement, but it’s in a very different domain where I’m out of my depth experience wise. Believe me I’m of similar mind to yourself, in this case I’m just the messenger and I don’t have a bullet proof vest.
I genuinely couldn’t agree more, it’s only the existence of the term I was been a little pedantic about.
OK, you got me. I’m on thin ice right now.
I would say Nagra know what they do.
But for me that would be the moment to grab the oscilloscope and start researching.
So I have performed one objective test that showed measurable variance between commodity USB cables. The test didn’t concern data, it was simply the time different cables take to charge a set of rechargeable IMR batteries for a vape. Certain cables take longer, much longer, to charge a battery from flat. We’re talking 2 hours that turns into 6-8 hours, same batteries, same charger and just different cables. I suspect that these were just VERY cheap, bordering on faulty. A quick Google search reveals that I’m not the first to observe this and there are a few explanations.
Indeed - and that is why I used the term “objectively”, thus removing option C from my scenario - after all, there is always the possibility of confirmation bias either way.
Yes, as soon as something on the DSP side of Roon is active or upsampling is active, the test fails.
What do I need to try Squeezelite?
From memory cables aren’t just bits of wire anymore, usb C / lighting actually have chips in them and the chips can negotiate different voltages / protocols, eg usb 2/3 or fast charge etc.
Aside from bandwidth** difference between usb 2 / 3, the same bits will get there in the end.
** Mb/s not audio bandwidth before anyone tries to pull that thread.
@Peter_Bruderer, having read @CrystalGipsy’s response, this might help as well:
These were old school mini USB and I chose the IMR battery example as those cheap Nitecore chargers don’t worry about adaptive charging, they just get on with it. Phones can be very fussy. Also agree that it’s not data. It does show that not all USB cables are created equal, but I’d be surprised to find differences in cables costing $5 upwards.
No one is denying that, which i exactly in line with my previous reply concerning the possibility of ANALOGUE, outside bit-perfection factors.
I will have to say on some tracks when I compare The Roons setup. SGC ST -->Bryston BDP Pi–>Wadia DAC (marrow cables) VS just running the MPD on the Bryston Pi , The MPD sounds more robustisized. The Roons appear to flatten the sound stage. High Rez Qobuz (>redbook) as the source.
Safe bet that if they introduce something that negatively affects the SQ of peoples current system this community gonna to light up like a pinball machine.
Exactly my point as well.
Its not just Squeezelite it’s LMS Logitech Media Server as using this I heard a difference, via Roon I didnt. If you have a pi you can install Squeezelite via Ropieee XL or dietpi which will also run LMS as well. I ran LMS on my Vortexbox server as this is what I used before switching to ROCK and used Ropieee for playback to the same DAC.
That sounds like a project.
I have a few unused pi and some Catalina Macs. On Big Sur I cannot launch it. I give it a try.
I am sure it’s bit perfect. I can also check it as I have an RME it’s not hooked up to a pi though but thats easily remedied.
I’ve noticed roon sounds better with dark mode v light mode. Also, limiting the queue to 50 or less tracks improves sq. I can’t explain it.
Actually a prime number of queue entries is best, for the obvious reason that prime numbers cannot resonate.