Chord Electronics Qutest DAC - Official Thread

[plsvn]

if we want to hear "a track", the streamer (which is not longer a "streamer") sends THE COMPLETE TRACK AT ONCE to the DAC (like a 100 % bit-perfect file transmission)

• let's put 1 GB of RAM into the DAC that it can store the whole track in a buffer

the above is what every streamer (and most software players) already do or... streaming DACs are already there too

 

[ATXKyle]

This post is interesting and caught my eye in the world of usb/computer based audio . it makes me think of what my Cyrus CD i implores technology wise . The Cyrus engineering way uses an information or data reading system called servos technology .Servos tech gathers up all the data from a CD all at once to avoid sound anomalies like timing issues and to avoid using the dreaded ' error correction' like found in many conventional CD players and Apple I tunes import disc settings .
All I want to say is that with a "gathering of data all at once" philosophy really does lead to much better audio, especially with the timing of your music .
Makes a huge difference so I think your post here, Tom is great!

I appreciate and love all kinds of audio set ups, but I am simply a purist.
I'm a CD guy and I use my Qutest with my CD i to get the best results for me of course.

+1 I’ve never understood why it isn’t done this way.

 

[nephilim32]

Also, a subject that has the horse almost flogged to death; PSU.

My upgraded Uptone LPS-1.2 replacement for a dead LPS-1 arrived yesterday.
Just out of curiosity, I plugged it to the Qutest today.

Results: My my my. I might have to get another LPS-1.2 or even consider the JS-2 for the SMS-200 and ISO Regen, but let's not get ahead of myself first.

Hey . The PSU subject shouldn't die . I spent the better part of a week learning about LPS and SMPS and after careful deliberation I decided to take the plunge. I went with a Zero Zone 12V 6.5a LPS .
Got it off eBay and should arrive in 2 weeks from now . I have a pretty heavy duty and unique power supply for my CD player and it makes a difference sound wise, so I decided to try the same with my Qutest .why not? Can't hurt.
Also . I will give my honest opinion weather this Zero Zone LPS makes a difference. I kinda doubt it will be substantial but given what I learned and read for the past week it really can't hurt to try .

 

[TomWoB]

the above is what every streamer (and most software players) already do or... streaming DACs are already there too

Maybe the streamer reads the whole track "at once", but it doesn't send it "at once" to the DAC!

The streamer generates "a nearly continuous stream of data" to the DAC. More or less the data you hear "now or in a few seconds", so let's say somehow "live data". "Nearly continuous", because the USB protocol defines "fix data-blocks" which must be deliver at once ... but that's for sure not "the whole track" !

 

[miketlse]

Yes, I know these points, summarized:

• USB transmission is never perfect
• in case of USB file transmission: the USB protocol allows to resend the failed packages, until file is 100% bit-perfect as the original
• in case of audio transmission: yes, we can have a problem, because in case of a "continuous stream" we maybe don't have enough time to resend failed packages

Fine that's clear ... but why do we handle USB Audio still with a "continuous stream" ???
He .. we have 2019, we have already USB 3.1!

Here is my proposal for a "new USB Audio Protocol"

• if we want to hear "a track", the streamer (which is not longer a "streamer") sends THE COMPLETE TRACK AT ONCE to the DAC (like a 100 % bit-perfect file transmission)
  
• let's put 1 GB of RAM into the DAC that it can store the whole track in a buffer
• USB 3.1 allows to transmit the "maybe few 100 MB of a classical track" in less then 1 second ... (USB 3.0 will be a little bit slower, so what)
• USB 3.1 allows to transmit the track bit-perfect, because failed packages will be resend (like storing a file bit-perfect on an USB-Stick)
• all our laptops run with SPS, but storing files bit-perfect on an USB-Stick is absolute no issue
• so "streamers" with SPS, which send complete tracks, don't have a power supply problem
  
• btw: the same will also work with Ethernet LAN connections

So again ... why we still "use continuous streams for USB audio" (or in general on digital side) ?

• radio stations need streams, that's clear but
• for all our music stored in files, I don't see longer any need for a continuos stream
• let's send the complete file/track "at once" to the DAC (1GB RAM in the DAC should be cheaper than a 1000$ USB cable)
  
• it will buffer the whole track
• a lot of problems are gone (transmission problems, clocks, jitter, ...)

Best regards
Tom

If you want the dac to receive all the data for a track, before starting to convert the data from digital to analogue, you will need a gap between one track finishing and the next track starting.
Have you seen the number of posters who do complain, if they cannot achieve gapless playback of tracks?

 

[GreenBow]

Stereophile review of Qutest.

STEREOPHILE QUTEST

The output graph of frequency and amplitude was of interest to me. It shows that the Qutest has a flat response, which to me is ideal. It means you have a reference source, and any bass or treble emphasis is coming from other components. Better to have at least one component as reference, for me, anyway.

However it also demonstrates what quite a few of us in the Hugo2 thread have been saying all along. That the Hugo 2 has a perfectly flat response. While some others have been trying to imply that the Hugo 2 is bright. I think they were trying to troll Chord, and or, are in denial about the rest of their partnering equipment.

Also reviews of the Hugo 2 and Qutest are off the charts in complementary terms. It's a shame that a few headfiers seem to be trying to spoil it for the rest of people.

I personally find the Hugo 2 rich in timbre. Not as rich as the TT2 will be, but the Hugo 2 is a fine DAC. Right away from the minute I plugged put music through it, I knew it was right and said so. I was initially outfaced by detail, and knew it would take time to adjust. It took a month. Still however, just over one year later, the Hugo 2 still surprises me every time I use it.

 

[TomWoB]

If you want the dac to receive all the data for a track, before starting to convert the data from digital to analogue, you will need a gap between one track finishing and the next track starting.
Have you seen the number of posters who do complain, if they cannot achieve gapless playback of tracks?

For sure, there are some problems, which have to be solved! But I think this can be done, that's why I was talking about a "new USB Audio Protocol". It should allow

• "an intelligent buffering" ... there is no reason why the next track shouldn't be in the buffer too
  
• there is also somehow a "2-way communication" necessary, because the streamer should show the actual "playing time"
  
• "fast forward/backward", handled by the streamer has also to be solved (again ... 2-way connection)
• playlist of the streamer has to be "in sync" with the buffer of the DAC
  
• but these "control commands" are only a few bytes via USB and not so much "time critical" as an audio signal

Yes, there are a lot of "open points", but I think we should have this "sometimes in the future", because it will solve "so many problems we have with audiophile streaming" !

 

[GreenBow]

I can give example.
Jitterbug make sound rolled off, lifelles all energy is sucked. This is when Signal integrity is compromised and timing is affected.
This mean slower, veiled, lifeless sound. Some people like reduced energy for some reason.
I have Ifi decrapifier too and this thing have something that fix signal integrity and it clearly shows... There is no slowing down or sucked out veiled sound.
Why do you think silver sound faster and leaner than copper? Because it is more conductive and signal reach faster gear thus presenting better timing.

I had Jitterbug on my Mojo USB. Nothing like that you describe. I will keep mine forever. It made USB sound like the optical input, which is as it should be.

On Hugo 2 and I suspect on Qutest, you don't really need Jitterbug, because Rob put in RFI filtering. However when I replaced Mojo with Hugo 2 I left the Jitterbug on the line from PC. NO WAY is the sound dull or lifeless. It's fast, furious and alive, and yet still subtle and beautiful.

 

[ray-dude]

For sure, there are some problems, which have to be solved! But I think this can be done, that's why I was talking about a "new USB Audio Protocol". It should allow

• "an intelligent buffering" ... there is no reason why the next track shouldn't be in the buffer too
  
• there is also somehow a "2-way communication" necessary, because the streamer should show the actual "playing time"
  
• "fast forward/backward", handled by the streamer has also to be solved (again ... 2-way connection)
• playlist of the streamer has to be "in sync" with the buffer of the DAC
  
• but these "control commands" are only a few bytes via USB and not so much "time critical" as an audio signal

Yes, there are a lot of "open points", but I think we should have this "sometimes in the future", because it will solve "so many problems we have with audiophile streaming" !

At the risk of going off topic, I've been experimenting a lot with these buffering concepts over the last several weeks. I am using a low power Intel NUC and booting AudioLinux to ram. It has replaced my MicroRendu 1.4 as my end point.

Over at the NUC forums on Computer Audiophile @austinpop reported that he was getting improved audio quality with SqueezeLite running as the end point (instead of Roon Bridge), but only when the buffer settings for the SL endpoint we increased.

Upon further investigation, we discovered that Roon (and LMS) both buffer the current track and the next track to SqueezeLite (when SL has large enough input buffers). On a wired ethernet network, that basically means that everything is buffered up in memory on the end point in around a second. For the balance of music playback, there is basically no ethernet traffic. The impact on SQ is pretty significant (mScaler + DAVE for me). When you reduce the buffer size on SL to the default, ethernet traffic is continuous during playback (same as with Roon Bridge), and SQ is pretty much equivalent to RoonBridge (ethernet traffic is continuous with Roon Bridge, but Roon Bridge does not have configurable buffers)

Clearly network traffic is impacting SQ on the end point (I suspect it is timing variation due to the system responding to ethernet interrupts, but I haven't done experiments to test that hypothesis yet).

SqueezeLite has a second buffer setting that controls the buffer between SL and the USB audio driver under linux. I found that increasing this buffer also had a significant positive impact on SQ (presumably by having music data always buffered on the USB interface to the DAC in the fastest memory available). Again, mote experiments to be done, but my prelim finding is that an end point running SqueezeLite with extremely large buffers basically is optimizing SQ, regardless of the tweaks upstream on the server side.

Net net from all this is that the USB interface is a very sensitive one, presumably to timing issues (these aren't RF issues...changing buffer sizes is clearly audible even though the electrical connections remain the same). There is a LOT of lift to be had by optimizing the USB link.

To the essence of this discussion, all the requirements being outlined for "next generation audio USB" are basically the functions that the end point streaming software provides (in this case, SqueezeLite...it is open source and the protocol for managing the various seek functions is well defined)

On my to do list is to leverage the optical in of HMS to see if buffering has an impact on the optical interface, and if so, how that compares to the USB interface.

As a caveat for those using Roon Server: Roon server does not play nice with LMS end points with large buffers. There is frequent skipping, long delays when seeking, etc. When you use LMS server, it handles all that perfectly. For now, SqueezeLite is a test bed for me to see how buffers can be leverages to optimize the data stream to the DAC as much as possible. When I'm done playing and doing critical listening, I switch back to Roon Bridge (reluctantly) so that the civilians in the house have something that "just works"

For those that want to play at home here is are my current SL settings:

/usr/bin/squeezelite -o front:CARD=SCALER,DEV=0 -b 4097152:97152 -d all=info -a 50000000:4 -c pcm -x -p 93

The -b parameter is the size of buffer between the server and the SL endpoint (in this case, ~4GB). The -a parameter is the size of the buffer between SL and the DAC (~50MB)

An aside: NUC running SL in RAM with gratuitously large buffers are the most impressive digital playback I've had in my system. For those wanting to experiment with these buffer concepts, dive in and please share your findings!

 

[Qute Beats]

Yes, I know these points, summarized:

• USB transmission is never perfect
• in case of USB file transmission: the USB protocol allows to resend the failed packages, until file is 100% bit-perfect as the original
• in case of audio transmission: yes, we can have a problem, because in case of a "continuous stream" we maybe don't have enough time to resend failed packages

Fine that's clear ... but why do we handle USB Audio still with a "continuous stream" ???
He .. we have 2019, we have already USB 3.1!

Here is my proposal for a "new USB Audio Protocol"

• if we want to hear "a track", the streamer (which is not longer a "streamer") sends THE COMPLETE TRACK AT ONCE to the DAC (like a 100 % bit-perfect file transmission)
  
• let's put 1 GB of RAM into the DAC that it can store the whole track in a buffer
• USB 3.1 allows to transmit the "maybe few 100 MB of a classical track" in less then 1 second ... (USB 3.0 will be a little bit slower, so what)
• USB 3.1 allows to transmit the track bit-perfect, because failed packages will be resend (like storing a file bit-perfect on an USB-Stick)
• all our laptops run with SPS, but storing files bit-perfect on an USB-Stick is absolute no issue
• so "streamers" with SPS, which send complete tracks, don't have a power supply problem
  
• btw: the same will also work with Ethernet LAN connections

So again ... why we still "use continuous streams for USB audio" (or in general on digital side) ?

• radio stations need streams, that's clear but
• for all our music stored in files, I don't see longer any need for a continuos stream
• let's send the complete file/track "at once" to the DAC (1GB RAM in the DAC should be cheaper than a 1000$ USB cable)
  
• it will buffer the whole track
• a lot of problems are gone (transmission problems, clocks, jitter, ...)

Best regards
Tom

Was thinking along these lines as well the other day (send entire music file to DAC with CRC error correction), but then thought, does this approach not need a processor on the DAC with the required codec installed in order to decode and play the file? FLAC codec is open source, so no problem there, but to decode other files licence fees need to be paid, thereby increasing cost of the DAC. But sure would eliminate all the arguments over USB etc file transmission.

 

[Qute Beats]

At the risk of going off topic, I've been experimenting a lot with these buffering concepts over the last several weeks. I am using a low power Intel NUC and booting AudioLinux to ram. It has replaced my MicroRendu 1.4 as my end point.

Over at the NUC forums on Computer Audiophile @austinpop reported that he was getting improved audio quality with SqueezeLite running as the end point (instead of Roon Bridge), but only when the buffer settings for the SL endpoint we increased.

Upon further investigation, we discovered that Roon (and LMS) both buffer the current track and the next track to SqueezeLite (when SL has large enough input buffers). On a wired ethernet network, that basically means that everything is buffered up in memory on the end point in around a second. For the balance of music playback, there is basically no ethernet traffic. The impact on SQ is pretty significant (mScaler + DAVE for me). When you reduce the buffer size on SL to the default, ethernet traffic is continuous during playback (same as with Roon Bridge), and SQ is pretty much equivalent to RoonBridge (ethernet traffic is continuous with Roon Bridge, but Roon Bridge does not have configurable buffers)

Clearly network traffic is impacting SQ on the end point (I suspect it is timing variation due to the system responding to ethernet interrupts, but I haven't done experiments to test that hypothesis yet).

SqueezeLite has a second buffer setting that controls the buffer between SL and the USB audio driver under linux. I found that increasing this buffer also had a significant positive impact on SQ (presumably by having music data always buffered on the USB interface to the DAC in the fastest memory available). Again, mote experiments to be done, but my prelim finding is that an end point running SqueezeLite with extremely large buffers basically is optimizing SQ, regardless of the tweaks upstream on the server side.

Net net from all this is that the USB interface is a very sensitive one, presumably to timing issues (these aren't RF issues...changing buffer sizes is clearly audible even though the electrical connections remain the same). There is a LOT of lift to be had by optimizing the USB link.

To the essence of this discussion, all the requirements being outlined for "next generation audio USB" are basically the functions that the end point streaming software provides (in this case, SqueezeLite...it is open source and the protocol for managing the various seek functions is well defined)

On my to do list is to leverage the optical in of HMS to see if buffering has an impact on the optical interface, and if so, how that compares to the USB interface.

As a caveat for those using Roon Server: Roon server does not play nice with LMS end points with large buffers. There is frequent skipping, long delays when seeking, etc. When you use LMS server, it handles all that perfectly. For now, SqueezeLite is a test bed for me to see how buffers can be leverages to optimize the data stream to the DAC as much as possible. When I'm done playing and doing critical listening, I switch back to Roon Bridge (reluctantly) so that the civilians in the house have something that "just works"

For those that want to play at home here is are my current SL settings:

/usr/bin/squeezelite -o front:CARD=SCALER,DEV=0 -b 4097152:97152 -d all=info -a 50000000:4 -c pcm -x -p 93

The -b parameter is the size of buffer between the server and the SL endpoint (in this case, ~4GB). The -a parameter is the size of the buffer between SL and the DAC (~50MB)

An aside: NUC running SL in RAM with gratuitously large buffers are the most impressive digital playback I've had in my system. For those wanting to experiment with these buffer concepts, dive in and please share your findings!

The media player I use (musicbee, free) has option to buffer whole track to PC RAM and I use this, as prevents continuous reading of HDD, it only adds the tiniest delay when starting playback.

 

[Joe-Siow]

Hey . The PSU subject shouldn't die . I spent the better part of a week learning about LPS and SMPS and after careful deliberation I decided to take the plunge. I went with a Zero Zone 12V 6.5a LPS .
Got it off eBay and should arrive in 2 weeks from now . I have a pretty heavy duty and unique power supply for my CD player and it makes a difference sound wise, so I decided to try the same with my Qutest .why not? Can't hurt.
Also . I will give my honest opinion weather this Zero Zone LPS makes a difference. I kinda doubt it will be substantial but given what I learned and read for the past week it really can't hurt to try .

Did you order the wrong voltage? Qutest takes 5V PSU. You might want to reach out to the seller if you can change the order.

 

[nephilim32]

Did you order the wrong voltage? Qutest takes 5V PSU. You might want to reach out to the seller if you can change the order.

Most wall adaptors are not regulated, this means that the voltage they produce varies with load. For a "5V" adaptor with minimal load the voltage may be as high as 12 or 15 V.

 

[Chester Rockwell]

This post is interesting and caught my eye in the world of usb/computer based audio . it makes me think of what my Cyrus CD i implores technology wise . The Cyrus engineering way uses an information or data reading system called servos technology .Servos tech gathers up all the data from a CD all at once to avoid sound anomalies like timing issues and to avoid using the dreaded ' error correction' like found in many conventional CD players and Apple I tunes import disc settings .
All I want to say is that with a "gathering of data all at once" philosophy really does lead to much better audio, especially with the timing of your music .
Makes a huge difference so I think your post here, Tom is great!

I appreciate and love all kinds of audio set ups, but I am simply a purist.
I'm a CD guy and I use my Qutest with my CD i to get the best results for me of course.

The Cyrus CD player may be gathering all the data at once, but if you’re connecting it to the Qutest, then surely it will still need to stream that data to the Qutest, where errors could still occur (in theory)?

 

[nephilim32]

The Cyrus CD player may be gathering all the data at once, but if you’re connecting it to the Qutest, then surely it will still need to stream that data to the Qutest, where errors could still occur (in theory)?

Stream? No. Gather yes The 1's and 0's. The cd player, since I bypass the internal dac, mainly acts as a time keeper and is the main keeper of all disc data read .the Qutest interpets whatever flow and gathering of info/data to do its d/A conversion from the cyrus's flow and interpetation .
Qutest doesn't take information...it receives .