[Birdboy01]

So what's the best " DACless" music streamer to get in the 4K range that would play nice with DAVE/HMS -especially to enjoy DSD? Aurender? Moon?

Appreciate the replies ..

 

[koven]

So what's the best " DACless" music streamer to get in the 4K range that would play nice with DAVE/HMS -especially to enjoy DSD? Aurender? Moon?

Appreciate the replies ..

Aurender if you don't use Roon. I need Roon so I went with Innuos with Lumin as a close second.

 

[onlychild]

So what's the best " DACless" music streamer to get in the 4K range that would play nice with DAVE/HMS -especially to enjoy DSD? Aurender? Moon?

Appreciate the replies ..

Innuos Zen or Zenith MK3

 

[Christer]

On the subject of Roon endpoint. I used to play my music from mbp via USB to HMS and Hugo 2. Excellent sound. Just for fun I got myself a Chromecast audio connected to HMS by optical. I had the impression that SQ was not as perfect with that little cheap thing, but just to check how it worked without cables. Then I got the Roon Nucleus to prepare for future Hi-Res storage and found out it worked best connected to the router in the office. So I had to rely on the CCA for music in the livingroom and thought it was OK. Enter a pure streamer as a Roon endpoint - the affordable Pro-Ject Stream Box S2 Ultra. Today I unpacked the diminutive box but Wow - what a difference! Unbelievable that such fantastic high fidelity music can travel unseen in my house, enter the little box and go into HMS, H2 and FU to make my that happy. This is the best clean beautiful SQ I have ever heard, can’t stop going through my music again. So those of you who are looking for a very good and affordable streamer witch is Roon ready, look no further. I do not know to what extent the improvent is due to Roon Nucleus superiority over the laptop if there is one, or if it is due to the magic little S2 Ultra. Who cares, the end result is superb.

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

 

[naynay]

So what's the best " DACless" music streamer to get in the 4K range that would play nice with DAVE/HMS -especially to enjoy DSD? Aurender? Moon?

Appreciate the replies ..

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?

 

[apmusson]

On the subject of Roon endpoint. I used to play my music from mbp via USB to HMS and Hugo 2. Excellent sound. Just for fun I got myself a Chromecast audio connected to HMS by optical. I had the impression that SQ was not as perfect with that little cheap thing, but just to check how it worked without cables. Then I got the Roon Nucleus to prepare for future Hi-Res storage and found out it worked best connected to the router in the office. So I had to rely on the CCA for music in the livingroom and thought it was OK. Enter a pure streamer as a Roon endpoint - the affordable Pro-Ject Stream Box S2 Ultra. Today I unpacked the diminutive box but Wow - what a difference! Unbelievable that such fantastic high fidelity music can travel unseen in my house, enter the little box and go into HMS, H2 and FU to make my that happy. This is the best clean beautiful SQ I have ever heard, can’t stop going through my music again. So those of you who are looking for a very good and affordable streamer witch is Roon ready, look no further. I do not know to what extent the improvent is due to Roon Nucleus superiority over the laptop if there is one, or if it is due to the magic little S2 Ultra. Who cares, the end result is superb.

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.

 

[AndrewOld]

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!

 

[Jan Tage Holmber]

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

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!

 

[ZappaMan]

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!

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.

 

[jarnopp]

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!

Perhaps buffering is meant 8nstead of latency itself, though more buffering would cause more latency, but is. It’s the only cause.

 

[apmusson]

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!

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...

Ade

 

[ray-dude]

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.

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.

 

[ZappaMan]

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

 

[Jawed]

it is annoying how easily my AK380 (connected optically to M Scaler) still outperforms my Innuos Zenith SE/tX-USBultra setup.

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:

https://www.head-fi.org/threads/hug...official-thread.885042/page-367#post-14769777

I'm really just looking for a server with no DAC function to feed the MS like a digital transport - using my 380 for this is just bypassing the DAC function - when I look at a big hifi sized box of tricks compared to the small AK player I think 'surely the big box must sound better'(!)

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.

These questions may have been asked before - if so apologies beforehand but there are a lot of previous pages to read through!

I recently listened to a colleague’s M-Scaler connected by dual BNC to my Chord Qutest DAC (using its ‘inclusive neutral’ filter). I heard useful improvements from the M-Scaler with x2 to x8 upsampling output from a Redbook CD but there seemed to be a ‘magic’ quantum-leap improvement at x16 upsampling from the M-Scaler.

I thought this sudden ‘magic’ improvement at x16 may have been due to it obviating further upsampling in the Qutest but I am told by a digital engineer colleague that the Qutest even then has further 2nd & 3rd stages of upsampling for noise-shaping etc. However do these later upsampling occur a such a high rate/fine time detail that it does not cause significant errors in the M-Scaler’s output impulse response?

therefore is the ‘magic’ improvement at x16 upscaling from the M-Scaler due solely to the Qutest itself upsampling the lower x2 to x 8 input rates to x16 with fewer taps than the M-Scaler so does not improve the sound as much? Whereas with the M-Scaler doing all the upsampling to x16 times it only occurs with 1M taps and this alone causes the ‘magic’ improvement?

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...

I did A/B comparisons going from PC to Mscaler with USB and Optical. Optical was the clear winner, and brought more life out of my Meze Empyreans which I felt the soundstage was distant and a bit boring on USB.

So my question is where do I go from here. Do I invest in a quality optical cable and which one? I'm unable to stream 192khz content over optical it seems. Is there a workaround for that? I can only do 96khz.

Just going optical out of an Asus Z97-PRO motherboard. Perhaps I should look into a sound card that does 196khz.

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.

 

[Amberlamps]

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.

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.