He sent us an email with no additional information. We’ve responded to him and asked him to publicly respond to my points here. He doesn’t seem interested in doing so for what he claims are “obvious” reasons. If he chooses to talk to us, we will make the results public – if we are truly at fault, I personally will let you all know.
We get a handful of these types of claims every time we release… we require compelling evidence before we spend resources investigating. I’m not saying there is anything nefarious going on with Emile or Taiko Audio, but it’s awfully convenient that:
“Roon got worse”
“you need to buy our closed systems for 24,000EUR to even tell the difference, that’s how good they are”
“we can’t measure the change, but we know it changed”
“we can’t tell you why, but we know that Roon is at fault for this change”
“we have a magic fix for this that protects our customers from your badness, and we are the only ones! but we won’t tell you about what we did to fix your software, especially publicly”
The idea that the graphical stuff is at fault (which runs on remotes and affects no aspect of what is going on the Core in the tiniest amount) casts further doubt here. Their server runs a headless RoonServer, right? If not, why not?
Anyway, the fact that I’m responding at all here should show that I’m interested in what Taiko Audio has to say (as well as others who make similar claims in the future), and these posts can act as a guideline on how we spend energy on such claims.
Hopefully he will reply by addressing the elephant in the room: what did he do to fix it and why does it work?
Nothing else, including the list above, matters. Let’s get down to the bottom of this by answering those 2 questions. As you pointed out “only the man himself knows…” I look forward to Emile’s response to those questions.
Edward here. I have volunteered to take questions, skepticism, arrows with humor and hopefully give insight and context.
Emile has e-mailed you earlier today, but he is very tied up rolling out the updates to Taiko Server owners to spend time on this thread
I have also been forewarned that I will be wasting my breath, but I do enjoy a challenge
I have been on this music server exploration with Emile for close to 5 years now. Michael Lavorgna is the guilty party who launched me on this journey.
There are some major takeaways, some of which I hope some of the readers can find credible because it’s consistent with their personal listening observations
The first takeaway, is that as far as bit perfect delivery of music data, the logical values of the zeroes and ones are exactly the same, no matter how cheap and simple, or heavy and expensive the server is when we are considering audio data delivery over asynchronous USB
The second takeaway is the RF environment of the listening room matters. Lots of people have notices SQ upticks from replacing SMPS with linear power supplies. Put a ferrite clamp on a power cord or data cable and most people will hear a difference, quite often a negative, the sound will be worse with a ferrite clamp on
The third takeaway, is that the audible influence of the of the RF environment to the perceived SQ increases as a system is more transparent and resolving as measured by SNR, THD IMD etc
Unfortunately, his email contained nothing other than citing how great Taiko Audio and their products are and how Roon developers are incompetent and uninterested in SQ. It had zero information on what the fix was or what the problem could be caused by. There was a tidbit about graphical vs command-line apps, but nothing concrete and nothing that should impact a graphics-less RoonServer installation.
That’s unfortunate, as I have all day to sit around and talk on this forum.
You want a challenge? Find out what Emile did.
Great! I hope that 5 year relationship helps wrangle out the relevant information.
Good luck!
yes, we all know about these takeaways… but what fixes were made? what measurements were taken to qualify and confirm the fixes? His fix is a software update, right? No new power supply or ferrite clamp was added in his “fix”, yah?
Emile did an extensive reallocation of the roon processes over the cores and also made some changes to BIOS settings which affect the RF signature of the subsystems on the Extreme to make a better match which the RF signature of build 537
You have IP, Emile has IP, I think it would be productive to email with each other directly
Some changes were made to get roon to album /track manage faster, and that had an audible impact on Inuos and Taiko servers
From the first version of Roon which we heard in 2016, to today’s versions, the SQ of Roon (as we have heard in our systems) has improved dramatically. RAAT was a major advance
The size of the buffer does effect the RF signature of the reading and unpacking of the data containers. There are some high end DAC’s which allow you to vary the size of the USB buffer. For a lot of these DAC’s owners, they will find a sweet spot, which sounds more pleasing than other buffer sizes. The best sounding buffer size is also somewhat system dependant. Tweaky but audible
but these changes did not impact previous builds? They only impacted 537? His claim is that something broke/changed in 537, right?
Super curious to hear what these changes are!
Let’s not change the subject, especially when we claim no SQ fixes were made over that time period (other than the DSD fix in 1.3… or was it 1.2?) As for RAAT, we have never claimed RAAT has any SQ benefit over UPnP, the protocol it was meant to replace.
Ok, if you say so… but does this have something to do with Roon build 1.7.537?
Let’s try to stay on topic… this thread is not about some general SQ goals… it’s about claims that 537 sounds “worse” and Taiko Audio has fixes for that “worseness”.
The Extreme has been optimized for bit perfect and moderate upsampling. It’s forte is not PCM to DSD conversion, which was the SGM Evo’s playback strategy.
Going from the Evo to the Extreme, Taiko moved from high CPU speed serial processing, to relatively low speed parallel processing.
2 cores or 20 cores, the zero’s and one’s are excatly the same, but the RF signature of the processing over multiple cores is very audibly different.
One of the consistently observable SQ data points, is that music servers with lower system latency sound better. The multicore implementation of the Extreme, is another data point that low latency is friendly to good SQ
Emile first listened to 537 on Monday, and posted on WBF asking Extreme owners for their opinion on any performance and SQ changes.
The initial reports were about album data being loaded significantly faster than before, and then came the negative SQ reports. There is a group of Extreme owners who are very critical listeners and they were reporting similar changes.
Emile took a deep dive in to the system after after several iterations was able to come up with a heavily revised process allocation and subsystem rework, that delivered a SQ that many feel is even better than before.
Expectation bias, could well be. When people are happy, they do hear differently. Red wine has a similarly positive effect
Danny, I am just reporting that build 537 was loading album data faster which is a plus, but that it had an unexpected negative impact on SQ, which Emile was able to mitigate by changing core allocation and other measures
This is sounding more and more like Emile did a bunch of changes to something on his server, and then felt it broke stuff, and then fixed the stuff he broke. I’m still not seeing how things broke in Roon 1.7.537 and how he fixed them.
I guess we won’t know more until he responds. Thanks for trying.
Using a Supermicro motherboard with a tweaked AMI BIOS?
3 Likes
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
90
How? The only way in which the SQ could change would be if the bits changed, so how did the change in speed of album data loading cause the bits of the music track to change? And what were the changes like?
Your claim was that buffer size affects the RF signature of the reading and unpacking of containers. The article you link to in support of your claim shows no measurements of RF whatsoever. It is about the merit of low latency in a studio, ie live, context. Low latency has obvious merit in the context of live music. But low latency is of questionable merit for music replay in a hifi context. Indeed it may be a bad idea as it precludes the use of complex DSP or long tap length filters. But in any case, you have not substantiated your claim that buffer size affects the RF signature of playback. So, once again, what is your evidence? Where are your measurements of RF produced by different buffer sizes?
"I’ve also mentioned in the past (notably in SOS June 2003) that the setting for audio interface buffers doesn’t only affect latency, but also CPU overhead. However, many musicians forget this as they struggle to achieve the lowest possible latency for their system.
The problem is that while the audio interface drivers take a negligible CPU overhead of their own to get started each time before the actual buffer filling and emptying takes place, and then to terminate afterwards, this small constant overhead can become increasingly significant at lower latency values. If, for example, your buffers are running with a sample rate of 44.1kHz and have a 12ms latency, they only need to be filled and emptied about 86 times per second.
But if you attempt to reduce buffer size to 64 samples at 44.1kHz, to achieve a latency of 1.5ms, you have to fill these buffers 689 times a second, and each time you do the drivers consume their little extra overheads."
