Chord Qutest

[ElviaCaprice]

5 minutes ago, beerandmusic said:

so if Rob says the jssg360 doesn't do anything, what is his recommendation to deal with RFI?

Rob has never commented on this cable modification/design.  Not even sure he's aware of what it is.  

I am curious to see how M-Scaler moderates/effects this contamination or worse creates it's own.

[beerandmusic]

23 minutes ago, ElviaCaprice said:

Rob has never commented on this cable modification/design.

 

https://www.head-fi.org/threads/watts-up.800264/page-63

 

besides link above, even in threads on C.A. i just read others saying that Rob Watts doesn't agree with jssg360.

 

anyway, after spending about 24hrs reading stuff lately, i just have a headache and think i will stick with enet for now...going to lay down for a much needed nap.

[beerandmusic]

1 hour ago, ElviaCaprice said:

  The problem I am encountering with JSSG360 is that it kills the music from it's reflection (great transparency, awful listening fatigue), at least in my findings with PCIe ribbon.  Which I would assume also applies to USB cables.

you also have me confused inre your word "reflection"....i thought all the jssg360 did was stop rfi..and even if it didn't work as suggested, that it couldn't possibly hurt anything....what do you mean by "reflection".

[Miska]

2 hours ago, beerandmusic said:

This post has really impacted me, and has always been in the back of my mind.

Here you state that the RF (I am assuming you are talking about RFI/EMI) is "specifcally isolated"...where many suggest it can't be isolated, but i thought i read that it is part of FCC standard that it be isolated....is it isolated or not? 

If a name brand, such as Chord, states the qutest is galvanically isolated and it meets fcc standards, can cables and usb toys further minimize rfi/emi, or is that where the objective vs subjective comes in to play?

Right now, i am most interested in how it applies to so called JSSG360 double insulated cables that suggest it minimizes RFI.  I just read on another forum where Rob Watts (Chord Engineer) says these cables do nothing, yet we have others suggesting dramatic impact?  Perhaps dramatic impact with older dacs that do not have newer technology that has designed new methodology to limit noise??

I am curious as to what your take is?

 

What I've tested, using bog standard USB HiSpeed certified cables with ferrites makes more difference than audiophile USB cables that usually don't make a difference or make things worse.

 

[ElviaCaprice]

9 minutes ago, beerandmusic said:

you also have me confused inre your word "reflection"....i thought all the jssg360 did was stop rfi..and even if it didn't work as suggested, that it couldn't possibly hurt anything....what do you mean by "reflection".

 

[beerandmusic]

10 minutes ago, Miska said:

 

What I've tested, using bog standard USB HiSpeed certified cables with ferrites makes more difference than audiophile USB cables that usually don't make a difference or make things worse.

 

 

that seems to mirror what Rob Watts suggested...i have seen some cables with one ferrite and some with two.   Also, i have found some "standard" usb fcc compliant cables offer double shielding?  any comment about either 2 ferrites or 2 shields?

 

anyway, i have also purchased one of these besides 4 other usb cables...it has both 2 ferrites and double-shielded.

 

https://www.amazon.com/gp/product/B008VOPCGY/ref=oh_aui_detailpage_o00_s00?ie=UTF8&th=1

[beerandmusic]

3 minutes ago, ElviaCaprice said:

 

unfortunately clicking the link just takes you to page 1 and "reflection" is not searchable on that page?

[Miska]

4 minutes ago, beerandmusic said:

that seems to mirror what Rob Watts suggested...i have seen some cables with one ferrite and some with two.   Also, i have found some "standard" usb fcc compliant cables offer double shielding?  any comment about either 2 ferrites or 2 shields?

 

The stuff I have is with just one ferrite (these kind of things commonly also come with scanners, digital cameras, etc). I have also retrofitted ferrites on some of my cables, 2 cm from the B-connector. I don't think adding more shields or ferrites improves things anymore. USB uses differential signaling on twisted pair, so shielding as such is not so important from signal point of view. Power feeds of the USB are more problematic, especially the ground/shield link. Ferrites help killing some of the HF noise on these.

 

[beerandmusic]

6 minutes ago, Miska said:

 

The stuff I have is with just one ferrite (these kind of things commonly also come with scanners, digital cameras, etc). I have also retrofitted ferrites on some of my cables, 2 cm from the B-connector. I don't think adding more shields or ferrites improves things anymore. USB uses differential signaling on twisted pair, so shielding as such is not so important from signal point of view. Power feeds of the USB are more problematic, especially the ground/shield link. Ferrites help killing some of the HF noise on these.

 

 

OK thanks....yes, i understand the the power on the usb is different and more problematic...Dac galvanic isolation for that...thanks again!

[kbkaran]

I think some posters are under the impression that when we say - galvanic isolation - there is only one, theoretically perfect way to implement it. This is usually not the case, other ways to put it - performance varies on implementation approach. This goes for eg. DACs too - convert digital to analog - we know how to convert a binary number to decimal value .. so we think that is all there to it. Long ago, I was banking on the asynchronous USB to free us from some upstream issues (cable, computer etc) But unfortunately still no, every thing in the chain seems to make a difference.  Anyways, back to the topic, I have a 2Qute and I got into this thread to see whether there is some benefit to upgrade to Qutest. So far,  my chain looks like - JRiver/Fidelizer/Win 10 -> Audioquest Jitterbug -> Wireworld Ultraviolet -> Ifi IUSB 30  -> Oyaide Class S -> 2Qute + Ifi IPower supply -> Preamp. I am not sure the USB cables make much difference but the ifi IUSB does. Also, the iPower Supply to the 2Qute did make a difference. Like the other poster, I am not so fond of the micro USB port on the Qutest for power supply. 

[barrows]

9 hours ago, beerandmusic said:

 

wow that is surprising that he would recommend toslink over usb...esp since you can't get highest resolutions from toslink....and to think the qutest would have been next dac (if any) i would consider.

 

you also have me confused inre your word "reflection"....i thought all the jssg360 did was stop rfi..and even if it didn't work as suggested, that it couldn't possibly hurt anything.

 

this industry is really starting to frustrate me...lol...so much for the cables i ordered that i was going to try to DIY...

 

i think i will just stick to enet still....

 

I am sure you can find plenty of folks on this forum using the JSSG DIY shield approach on their Ethernet cables as well...

 

But do not despair, no one says you have to go to such tweaks to get good sound!

[beerandmusic]

20 hours ago, Miska said:

 

What I've tested, using bog standard USB HiSpeed certified cables with ferrites makes more difference than audiophile USB cables that usually don't make a difference or make things worse.

 

you mention that you think usb cables with ferrites seems to work best in your testing.  Do you think that  ferrites on "BOG" usb compliant cables are effective?  I read one mfr advertisement stated that Not all ferrites are tuned correctly (whatever that means?) to be used with  high frequency data transfer cable without changing the electrical properties of the cable to the point where the data transfer is corrupted and/or slowed down?

[Miska]

3 hours ago, beerandmusic said:

you mention that you think usb cables with ferrites seems to work best in your testing.  Do you think that  ferrites on "BOG" usb compliant cables are effective?  I read one mfr advertisement stated that Not all ferrites are tuned correctly (whatever that means?) to be used with  high frequency data transfer cable without changing the electrical properties of the cable to the point where the data transfer is corrupted and/or slowed down?

 

You can get cables with built-in ferrites (regularly also as freebies with either pro-audio gear, scanners, digital cameras, etc etc). Or you can get correct ferrites. For example my Focusrite Forte, Epson Scanner and HP touch screen monitor came with USB cable with built-in/on ferrite.

 

There's no "slowed down", it would be corrupted instead. And since USB Audio Class doesn't have error correction, you'd have snap'crackle'and'pop, or device disconnects. Usually when I've encountered corrupted data or device disconnects on USB, it has been with audiophile USB cables (actually never seen a certified one) or with USB gadgets on the path.

 

With the blue USB 3 cables I haven't used ferrites yet, these can be used on some audio gear, like Holo Audio DACs and some iFi gear. For those I just use cheap ordinary certified USB 3 cable.

 

[HumanMedia]

What are Qutest owners opinions on the different DAC filter options?

 

Default ‘Neutral Incisive’?

 

 

 

[rhern213]

On 8/21/2018 at 2:18 AM, HumanMedia said:

What are Qutest owners opinions on the different DAC filter options?

 

Default ‘Neutral Incisive’?

 

 

 

 

Definitely Incisive neutral for me, when I was using HP's I'd go with green roll-off, on my speakers now I go with default white because I don't hear any areas that are a bit too high and bright. Warm was fine, but kinda takes away the point of owning a Chord DAC IMO.

[HumanMedia]

Im using the Qutest via USB from an UltraRendu using LMS Server, which sees the DAC as supporting DSD.

 

Exact same setup with the 2Qute and had no trouble playing all flavours of PCM, DSD64, DSD128 and DSD256.  And never a glitch or dropout with thousands of hours of DSD playback.

 

However with the Qutest it wont play DSD128 or DSD256. It plays DSD64, and PCM up to DXD @ 384khz without an issue but when I try and play DSD128 or DSD256 it reports that the current track is the selected track, but just wont play and time stays at 0.

DSD is all sent as DOP by the LMS Server, but no play.

 

Any hints?

 

I suspect its a serious user error, and somehow Ive messed up something, but maybe not...

[audio.bill]

4 hours ago, HumanMedia said:

Im using the Qutest via USB from an UltraRendu using LMS Server, which sees the DAC as supporting DSD.

 

Exact same setup with the 2Qute and had no trouble playing all flavours of PCM, DSD64, DSD128 and DSD256.  And never a glitch or dropout with thousands of hours of DSD playback.

 

However with the Qutest it wont play DSD128 or DSD256. It plays DSD64, and PCM up to DXD @ 384khz without an issue but when I try and play DSD128 or DSD256 it reports that the current track is the selected track, but just wont play and time stays at 0.

DSD is all sent as DOP by the LMS Server, but no play.

 

Any hints?

 

I suspect its a serious user error, and somehow Ive messed up something, but maybe not...

Have you tried to use native DSD instead of DoP? According to Chord's website the Qutest supports native DSD playback up to DSD512.

[seeteeyou]

First of all, 2Qute couldn't even support DSD256 in the first place and therefore not exactly sure about what you're talking about

 

https://chordelectronics.co.uk/wp-content/uploads/2016/09/2Qute-User-Manual.pdf#page=3

 

Read what other owners went through and most likely you're outta luck, even SOtM sMS-200 wasn't going anywhere

 

http://www.diyaudio.com/forums/pc-based/310578-chord-2qute-dop-challenge-16.html#post5257684

http://www.raspyfi.com/forum/raspyfi-install-and-troubleshooting/no-sound-from-usb-chord-dac/

https://community.roonlabs.com/t/dsd-playback-through-chord-mojo/17860

https://community.roonlabs.com/t/doubt-about-native-dsd/33016

https://community.roonlabs.com/t/native-dsd-chord-hugo-2/35777

 

Neither Sonore nor Chord seemed to be interested in getting anything done

 

https://www.head-fi.org/threads/chord-electronics-qutest-dac-official-thread.869417/page-98#post-14255566

 

Basically we could "try" to patch the file quirks.c by adding a line for DACs from Chord, though there's no guarantee that native DSD would work

 

https://github.com/RoPieee/ropieee-kernel/blob/master/kernel-usb-native-dsd-quirks.patch

https://github.com/torvalds/linux/blob/master/sound/usb/quirks.c

case USB_ID(0x245F, 0x0815): /* Chord DAVE/Hugo 2/Qutest/Hugo TT 2 */

Those values were taken from the driver, just check the file cdh768.inf

 

https://chordelectronics.co.uk/wp-content/uploads/2017/01/Windows-10-768KHz-driver.zip

[OEM.ntamd64]
%USBSPDIFDesc%=USBSPDIF_Inst,USB\VID_245f&PID_0815

 

[ecwl]

16 hours ago, HumanMedia said:

Im using the Qutest via USB from an UltraRendu using LMS Server, which sees the DAC as supporting DSD.

 

However with the Qutest it wont play DSD128 or DSD256. It plays DSD64, and PCM up to DXD @ 384khz without an issue but when I try and play DSD128 or DSD256 it reports that the current track is the selected track, but just wont play and time stays at 0.

 

Any hints?

My experience is quite different than yours (and others) based on testing I just did on my Blu2 (which should have the same USB receiver as DAVE/Qutest). Granted, I use Roon.

First of all, I presume you have the latest version of sonicorbiter (v2.6) on your Ultrarendu. When you go to sonicorbiter.com, you can log onto the Ultrarendu and then in the Settings for Roon Ready or Squeezelite, you have the option to select the DSD support between DoP vs native DSD. (I presume you're running Squeezelite mode on your Ultrarendu). In my system, I find that if I were to choose native DSD, I actually cannot get DSD playback at all as Roon wouldn't give me that option. Whereas if I were to choose DoP, I can easily play DSD64, DSD128 and DSD256.

So I can tell you from my system DSD256 with DoP definitely works with Roon. I would suggest double checking your LMS Server settings and  your Ultrarendu settings are correct, both in terms of the Output Mode and the Squeezelite DSD settings.

[HumanMedia]

@ECWL

 

Ahh good tip! On the LMS Server web settings it just says DSD playback is fine, but I haven’t checked the Rendu settings which sometimes conflict with the LMS Server settings. Like the playername - it is often overridden or ignored between the Server Settings and the Rendu settings (annoyingly)

 

Also in regards to the LMS DSD support, if it detects the DAC doesn’t support a specific sample rate it will convert on the fly to the next highest sample rate - or to PCM if DSD isn’t supported. On the 2Qute, DSD64, DSD128 and DSD256(?) always lit the white light so it wasn’t converting to PCM but was it converting DSD128 (and DSD256?) to DSD64 the whole time?

 

ECWL - will try your suggestion for the Rendu settings in a couple of hours, thanks for the tip.

 

PS Chord support said that the Qutest should play all flavours of DSD over DOP via USB. But they didn’t touch on any restrictions of different renderers drivers....

[HumanMedia]

10 minutes ago, HumanMedia said:

@ECWL

 

Ahh good tip! On the LMS Server web settings it just says DSD playback is fine, but I haven’t checked the Rendu settings which sometimes conflict with the LMS Server settings. Like the playername - it is often overridden or ignored between the Server Settings and the Rendu settings (annoyingly)

 

Also in regards to the LMS DSD support, if it detects the DAC doesn’t support a specific sample rate it will convert on the fly to the next highest sample rate - or to PCM if DSD isn’t supported. On the 2Qute, DSD64, DSD128 and DSD256(?) always lit the white light so it wasn’t converting to PCM but was it converting DSD128 (and DSD256?) to DSD64 the whole time?

 

ECWL - will try your suggestion for the Rendu settings in a couple of hours, thanks for the tip.

 

PS Chord support said that the Qutest should play all flavours of DSD over DOP via USB. But they didn’t elaborate on the restrictions of different renderers drivers....

 

[HumanMedia]

Ok problem solved with my LMS Server, Rendu to Chord Qutest high datarate DSD issues.

 

Here is the solution for others who may also encounter this.

 

Set DOP not Native DSD in the Squeezelight settings on the Rendu web interface.

And in the LMS Server Web interface, on the Advanced Tab, in the File types area, make sure that for .dsf and .dff are set to Native. All the FLAC containers should be set to DSDPlay, which mine were by default.

 

The key to was to change from (Native DSD) Disabled to Native (enabled).

If you don’t do this Native Disabled works for DSD64, but not higher DSD rates. Plus it’s confusing that you have to set it to Native on the server, but DOP on the rendu’s player.

 

Cootie Williams now playing in the background at DSD256. No issues now all DSD playing seemlessly and without the slightest issue.

 

[barrows]

@HumanMedia,  Please note that in the sonicorbiter.com web interface for the ultraRendu there is also the "DAC diagnostics" in the "apps".  If you open DAC diagnostics while playing you can confirm the sample rate which the ultraRendu is receiving.

 

DoP, will indicate a PCM sample rate like this: 176.4 for DSD 64, 352.8 for DSD 128, and 705.6 for DSD 256.

 

for Native DSD playback (not possible with Chord DACs) will indicate a PCM sample rate like this:

88.2 for DSD 64, 176.4 for DSD 128, and 352.8 for DSD 256.

 

Using "DAC Diagnostics" can be helpful for sorting out problems like this.

[nick77]

Just curious if anyone has compared to Holo Spring L3??

 

And how much difference in sonics is a good LPS? I know my 2Qute responded very well to a good LPS.

[Northern Light]

I am in the process of “ditching” my Naim ND5XS for a Qutest. Obviously I’ll need a transport for the Qutest. I now wonder whether it was better to use the Qutest’ USB input, or rather the S/PDIF (BNC) input. Does it make any SQ difference? 

Cheers!