Separate names with a comma.
Aurender if you don't use Roon. I need Roon so I went with Innuos with Lumin as a close second.
Innuos Zen or Zenith MK3
Hell Jan Tage,
nice to hear from you again and the Pro-Ject streamer you mention is on my list of options to try too.
You are not the first person to sing its praise .
It sounds promising with several reasonably priced gadgets that seem to be able to improve further on USB/MBP/HMS which I am currently using.
By the way did you get to hear the SSO live when you where in Singapore around New Year?
I stayed in KL where there was even more going on concert-wise than in Singapore at that time.
I'll be back in KL around mid March again after a couple of months in Thailand.
Much as I like my M ScalerQutest combo on a daily basis I am really looking forward to hear some live music in KL soon again.
I've got two interesting concert programs to go to on the 15/16th of March in KL to begin my concert season again. And I may decide to go to Singapore for Canjam at the end of the month. But Canjam collides with three tempting concerts in KL that very same weekend so I haven't made up my mind yet whether to go or not.
The only really tempting concert for me in Singapore during late March is Sabine Meyer performing Mozart's Clarinet Concerto with the SSO in Victoria Hall.
PS. really OT, are there any signs of Spring in Sweden yet?
Cheers Controversial Christer
I was having a talk with a hifi specialist about what can give me the best sound and DSD compatible to go with my HMS/DAVE.
I said i'm not interested in it having a cd ripper just good sound and can run roon.
Antipodes was the one he suggested i have one on order maybe worth a look?
It's interesting how much the digital source is able to change the sound. I suspect that latency and power hygiene have a big part to play.
I found that the Chromecast responded very well to improvements in power supply (I'm using a Sonore LPS) and the use of Ethernet connection (Wifi disabled). @ray-dude advised that optical out of an optimised NUC provides an improvement over Chromecast (I think he used a battery to power his Chromecast) in his experiments so I'll be giving that a go shortly.
Why should latency make any difference whatsoever? Latency is only an issue in a studio context, say when you are playing a digital keyboard. For replay of music that is stored on a hard drive and has been there for years, why should a few more microseconds make any difference? Chord DACs themselves have enormous, colossal, longest in the industry by far latency. A million taps mean massive latency. Doesn’t seem to do any harm!
No, we went to SSO but nothing available during our stay. Very nice city though. We’ve had some unbelievably warm and sunny days in late february but the spring ”kom av sig”. Now I am just waiting for Qobuz to be released in Sweden so can get use of my Roon Nucleus.
Envy your climate!
I’d like to hear someone knowledgable on latency explain its relevance. I know the guys who are into operating system optimisation believe it’s role is crucial.
Perhaps buffering is meant 8nstead of latency itself, though more buffering would cause more latency, but is. It’s the only cause.
I'm no expert but my experience with tweaking tells me it does. I've tried optimising PC process (via process lasso and also tried other 'audiophile' optimisers and they make a difference (albeit pre mscaler). There are so many variables in the chain that I can't be certain but my experiences tell me it does (did?) make a difference. When I configure my NUC endpoint I intend to use an optimised version of Linux that I understand focuses CPU resources on latency and timing.
I'll report back if the same source file and server sound different through the NUC Vs Chromecast. If not I'll stick with Chromecast - it would be good to get 192/24 support through Toslink from the NUC...
I've been spending a LOT of time on this lately. I don't have answers yet, only observations and an emerging hypothesis.
For me, the key issue isn't latency, it is reducing the variation in latency. If playback had a latency of 1sec +- 0.00000000001sec, that is preferable to a latency of 0.001 sec +- 0.0001 sec.
The trend is that a system that can minimize end to end latency generally has less variability in latency, but I think that is correlative rather than the key attribute.
I am using a NUC running AudioLinux in RAM as my end point, connected to HMS by USB. Here is a 20k foot view the things I've been trying consistent with this variability in latency hypothesis:
By using a NUC with highly integrated SoC, SQ is better (tighter integration on chip)
By going with a stripped down in memory linux with everything else disconnected and disabled in BIOS, SQ is better (less contention and closer to real time processing)
By configuring linux to give the highest real time priority to the end point software (Roon Bridge or Squeezelite), SQ is better (more real time processing)
By configuring linux to give the highest real time priority to the IRQ for the USB port, SQ is better (more real time processing)
By removing the USB boot stick so the only thing on the USB bus is the DAC, SQ is better (fewer IRQs for USB storage)
By configuring the music server to bridge ethernet traffic to the NUC end point, SQ is better (isolating ethernet traffic and interrupts)
By increasing network buffer for Squeezelite so that all the ethernet traffic is front loaded and the current song and next song are loaded into memory within a second or so, SQ is better (fewer ethernet interrupts during playback)
By increasing the buffer from SqueezeLite to the Linux ALSA driver, SQ is better (less variability on feeding the USB driver)
By having a higher powered NUC (7i7 vs Celeron), SQ is better (able to be closer to near real time since it has more horse power)
By configuring linux to dedicate a CPU core to the USB IRQ, SQ is better (more real time processing)
By configuring linux to dedicate a CPU core to the end point software, SQ is better (more real time processing)
By turning off all the CPU turbo mode and energy saving features so CPU runs at a constant clock rate, SQ is better (less variability in processing)
(Anecdotally) By swapping out the clocks in the NUC and use an ultra high quality master clock like the Ref10, SQ is better (I have not heard this nor confirmed this personally, but I trust the ears of those that have)
None of these seem like they are RF related. These are all computer/OS/software configuration tweaks. What they all seem to share is the impact of reducing variability in the latency of the signal from the end point to the DAC, and (presumably) making the life of the PHY interface of the USB chipset a lot easier.
I have a long list of additional experiments and tweaks to try. A bunch are in the realm of power, but the USB signal chain ones are driven by the following hypothesis:
Every component in the USB signal chain should minimize the "effort" the next component in the USB chain needs to do at the PHY layer (the DAC PHY should be laziest of all)
I'm not drawing conclusions yet nor pointing at a core root cause. However, I'm finding that any change I make that is consistent with reducing variability in the latency of the digital signal seems to have a positive impact on SQ. (and I'm really enjoying that SQ Also impactful is power stability and noise, RF, etc.
Great post dude
If you are using the WAVE cables between HMS and DAVE, then perhaps the WAVE cables are not doing their job. But, to be sure, I would recommend putting lots of ferrites on your DAVE mains cable - see my signature. DAVE is sensitive to noise through its mains input, but it's not a massive difference. Once this is done you'll be able to compare Innuos and DAP and know for sure whether the WAVE cables are strong enough in their RF filtering.
If there's still a difference then you can try 30+ of the ferrites per cable and simple BNC cables I wrote about here:
Very unlikely because the server is just a computer and computers produce a lot of RF noise. The Innuos Zenith SE, for example, does not have a good track record as a low RF noise source.
Your colleague is correct. Qutest, like all of Chord's current DACs, runs the DAC itself at about 100MHz. To get there from 705.6KHz or 768KHz, it goes into a second WTA upsampler (to 256x sample rate) and then into a final upsampler (to 2048x sample rate). The noise shaper follows these 3 upsampling stages to convert the PCM at 2048x into the signal that drives the pulse array DAC. These upsampler stages (HMS included) and their low-pass filters are all about getting cruddy old CD format into the format that the pulse array needs.
1M taps is where the magic happens, it's the mystery that Rob hasn't fathomed...
Your motherboard optical output is extremely like to support 176.4 or 192KHz, but the driver might need to be updated. In Windows you have to configure the sound device to actually support these higher sample rates (you have to click through settings into "Additional device properties"). The optical cable that comes with HMS should support 192KHz. In general 2m or longer optical cables are marginal at 192KHz and you will need to get a $20+ "premium" 2m optical cable to get this working.
Come on Ray, don’t spoil you’re good post count with the above as 90% + of the above is pure BS.
I like and read your posts Ray, but that ^ one just spoiled the good post run that you were on.
I’m sorry that I was the bearer of bad news Ray, but you’ll recover and will manage to climb the chord donkey kong ladders again.
So this evening I was briefly sat not listening to music and I could hear hiss from my speakers! That's not right I thought, DAVE driving my speakers (91dB/W/m at 1.6m listening distance) is absolutely silent. Why is there hiss? OK, so I've got the volume a bit louder than normal, but DAVE never gave me hiss before I got HMS.
So then I played with inputs and discovered that HMS being active is causing the hiss! If I stop the audio to HMS then the hiss disappears and I'm back to blissful silence from DAVE.
So, remembering that Blu 2 has a dither option switch which can be used when connecting Blu 2 to a non-Chord DAC, I thought about bit depth. With Blu 2 the dither is used to create a 16-bit output that is compatible with an old type of DAC.
So on my computer I changed the bit-depth to 24-bit, instead of the default 16-bit. Now, there's no hiss from DAVE even when "silence" is playing through HMS. So it seems that HMS detects that the input is 16-bit and it outputs dithered 16-bit audio (at 705.6 KHz). The dithering is what I was hearing as hiss with HMS feeding into DAVE.
This seems to be a problem though: anyone who is using a CD transport into HMS is feeding HMS with 16-bit data. HMS then adds dither. The dither is completely pointless if you have a Chord DAC. And worse than that, the dither is audible!
@Rob Watts is this behaviour by HMS intentional? This seems like a bug to me. It's easy for me to solve this problem, but anyone using a CD transport into HMS seems to be stuck! Also I suspect anyone using a streamer that outputs 16-bit audio will have the same problem. In my setup I'm using optical. Perhaps this problem only affects S/PDIF audio (optical and electrical), so USB is fine?
Now playing: Stephen Cleobury, Choir of King's College Cambridge etc. - Lassus: Choral Music