[azabu]

Yes but you don't have to use wall power for the Qutest, you can use an external battery pack as well.

I tried this and (to me) it sounded flat. I've gone the LPS 1.2 route and pleased with the results.

 

[Triode User]

But this noise is negligible.

I used a Hugo 2 battery, loaded with a 15 ohm resistor to draw 0.25A. A wt 20 to 20k it was 670nV on the AP with the battery connected, with the battery not connected to the 15 ohm load it was ... 670nV. So no noise at all from the battery.

Using the AP's 2.5MHz ADC with a 1 MHz bandwidth, it went from 8.45 uV to 9 to 10 uV. Against any active regulator this is fantastic performance.... A quality linear regulator would be 60uV in the audio bandwidth alone. And ultra low noise regulators are an enormous 12uV 20-20kHz alone, let alone a 1 MHz bandwidth.

You spoiled my pedantic fun.

 

[Rob Watts]

Hi Rob, I think you've mentioned this before, but over all else you do recommend a battery pack as a power supply for the Qutest for the best possible SQ?

If so are there any particular brands you personally use or recommend to try out?

If not is there any other typical LPS/UPS type you recommend?

There are so many options, discussions, contradicting info I've gone through that it's exhausting and hard to discern facts vs nonsense.

I trust the person who actually designed the darn thing over anyone else.

And thanks for designing a really excellent product!

The one I use is Poweradd Pilot Pro2. Now this has internal regulators - so it is noisy on the OP - but the key is the absence of mains bourne RF noise. With Hugo 2, adding the unit makes no difference to the SQ, and it's the issue of RF noise that is key, not the noise on the OP. Also, it's completely isolated from the mains, so no ground loops or leakage current is possible.

 

[AlexB73]

Guys,
How much break in time does Qutest need?
I got my Qutest in the previous week.
I tried to listen it twice.

After 4x24 hours Qutest sounded really bad and unmusical.

After 7x24 hours Qutest sounded better, at least comparable to 2Qute.
But steel, sound wasn't open like in my 2Qute and in term of details and separation it was just a very little better then 2Qute.
I use white setting of the filter.

 

[ecwl]

Guys,
How much break in time does Qutest need?
I got my Qutest in the previous week.
I tried to listen it twice.

After 4x24 hours Qutest sounded really bad and unmusical.

After 7x24 hours Qutest sounded better, at least comparable to 2Qute.
But steel, sound wasn't open like in my 2Qute and in term of details and separation it was just a very little better then 2Qute.
I use white setting of the filter.

That’s unusual. Maybe you should set your Qutest to output at 2V or even 1V. Perhaps you were always clipping your preamplifier at 3V with 2Qute and now Qutest which is why it’s hard to hear the sonic improvements.

 

[Zzt231gr]

^^Agree.I don't think mine burned in.Played fine from the beginning.

 

[kovacs]

Guys,
How much break in time does Qutest need?
I got my Qutest in the previous week.
I tried to listen it twice.

After 4x24 hours Qutest sounded really bad and unmusical.

After 7x24 hours Qutest sounded better, at least comparable to 2Qute.
But steel, sound wasn't open like in my 2Qute and in term of details and separation it was just a very little better then 2Qute.
I use white setting of the filter.

Seven days should be plenty, I did notice a difference after 24 hours of continuous burn-in with white noise, but after that sound quality didn't really change much anymore. I liked the sound right out of the box. I do find that the Qutest is a very sensitive piece of equipment, small changes can have a big impact on sound, definitely try to keep it away from power sources like transformers and power cables. What source are you using ?

 

[AlexB73]

I don't have an issue with 3V input.
My integrated amp. has L-pad on input before the first tube.
Actually my cartridge-SUT-phonostage (EMT TSD15 - Sun Audio/Tamura SAT1000 - EAR834P) combination gives about 9 volts RMS input to my integrated 300B SET!
No problem at all!

I do burn-in with music on repeat. It takes longer time compared to pink noise.

I use 2Qute and Qutest in the same conditions. Both use power supply supplied by Chord.
I use Cary 303 CD player as transport with Belkin Pro "blue" coaxial cable.
This transport overperformed my Mac Book Pro (with Audioquest Carbon USB cable) by miles.

 

[Sage Encore]

Hi Guys,
Sorry if I am asking in the wrong thread, can any kind souls please help. My current setup is: Amp: Simaudio HAD 430 (DAC model), Source is SP 1000, I also have a ALO CDM. Should I invest in a Qutest since I basically have three different DACs ie, My amp has a ESS Sabre 32bit 9018, my source SP1000 has dual AKM chips think its AK 4497EQ which I can use as a DAC and my ALO CDM has Wolfson DAC on board which I can also use as a DAC using Line out.

Will I see a significant increase in sound reproduction to all of the above combos I have in hand or should I just invest in something else. Thank you for your times guys.

 

[NeoVibe]

Hi all,

I currently have a Hugo (mk1) connected to an Auralic Aries (the full fat one). In this configuration I can only get the DSD lights in the Hugo when I activate DoP (DSD over PCM) in the Aries but this is, if I understand correctly because the Hugo only supports DSD in DoP 'encapsulation'.

I am considering the upgrade to a Qutest specifically for native DSD support but according to the online manual, "Native DSD playback is only available via Windows OS with the driver available from the Chord Electronics website." and I am trying to understand what this means:
- If I am running Roon on a MAC can I get native DSD?
- the sentence assumes the Qutest is either connected to PC or a MAC but in this case it will be connected to neither, but instead a specific devices, the Auralic Aries - will I get native DSD?

Thank you for the replies. Sorry if this has been discussed before but it is impossible to read 100 pages backwards

Regards all.

 

[x RELIC x]

Hi all,

I currently have a Hugo (mk1) connected to an Auralic Aries (the full fat one). In this configuration I can only get the DSD lights in the Hugo when I activate DoP (DSD over PCM) in the Aries but this is, if I understand correctly because the Hugo only supports DSD in DoP 'encapsulation'.

I am considering the upgrade to a Qutest specifically for native DSD support but according to the online manual, "Native DSD playback is only available via Windows OS with the driver available from the Chord Electronics website." and I am trying to understand what this means:
- If I am running Roon on a MAC can I get native DSD?
- the sentence assumes the Qutest is either connected to PC or a MAC but in this case it will be connected to neither, but instead a specific devices, the Auralic Aries - will I get native DSD?

Thank you for the replies. Sorry if this has been discussed before but it is impossible to read 100 pages backwards

Regards all.

DoP will be bit for bit the same DSD file as “Native DSD”.

DoP was simply developed as a way to use DSD over USB without audio drivers, and the PCM wrapper does not affect the DSD data. Unless you are experiencing drop-outs from the extra computation needed for DoP then you can rest assured you are hearing the full DSD. "Native DSD" really is an unfortunate name for DSD with audio drivers.

Reading your post I presume you know this already so what is wrong with DoP from the Aries?

 

[NeoVibe]

Hi there,

No I wasn't really aware of what DSD over PCM was. The Auralic is a new adition to the system, so nothing wrong with the sound, I simply assumed native was the real deal while DoP would mean some sonic compromise.

If that is the case I am fine.

Regarding my questions, I assume that both via Aries and Mac computer DoP is the only technical possibility (because no drivers are involved).

Thanks for the answer.

 

[x RELIC x]

Hi there,

No I wasn't really aware of what DSD over PCM was. The Auralic is a new adition to the system, so nothing wrong with the sound, I simply assumed native was the real deal while DoP would mean some sonic compromise.

If that is the case I am fine.

Regarding my questions, I assume that both via Aries and Mac computer DoP is the only technical possibility (because no drivers are involved).

Thanks for the answer.

Mac OSX actually has many USB audio drivers built-in but may also require drivers for some devices provided by the manufacturer. Windows based computers haven’t for a looooong time, hence the acceptance that drivers are required. Also, Windows software can also use DoP. Incidentally, other standards like coaxial and optical can also utilize DoP.

There is an advantage to some USB audio drivers in that if packets are skipped or if there are errors it can re-send them, but if there are no playback issues (computational overhead) then there is no concern with DoP.

The issue started because the USB standard only recognized PCM as an audio stream so then DSD over PCM (encapsulating the data in a PCM wrapper) was created. When the receiving device recognizes the DoP flag it dumps the PCM marker and plays as 100% DSD.

 

[NeoVibe]

Mac OSX actually has many USB audio drivers built-in but may also require drivers for some devices provided by the manufacturer. Windows based computers haven’t for a looooong time, hence the acceptance that drivers are required. Also, Windows software can also use DoP. Incidentally, other standards like coaxial and optical can also utilize DoP.

There is an advantage to some USB audio drivers in that if packets are skipped or if there are errors it can re-send them, but if there are no playback issues (computational overhead) then there is no concern with DoP.

The issue started because the USB standard only recognized PCM as an audio stream so then DSD over PCM (encapsulating the data in a PCM wrapper) was created. When the receiving device recognizes the DoP flag it dumps the PCM marker and plays as 100% DSD.

Thanks again for the additional information.

The point regarding the non existence of a "re-send" mechanism in (most?) USB dac implementations is one of the reasons why I think a good dedicate streamer with a good clock/isolation/low-noise etc is so important (without the re-send possibility the PCM/DSD streams need to be as accurate as possible as errors cannot be recovered with absolute certainty, although i believe there are mechanisms in place to "guesstimate" what the original stream really was.

You mentioned some drivers had this resend mechanism. Is this the case of the Hugo/Qutest products family? (I would assume not and don't know of any dac with this capability)

Regards

 

[x RELIC x]

You mentioned some drivers had this resend mechanism. Is this the case of the Hugo/Qutest products family? (I would assume not and don't know of any dac with this capability)

I’m not sure how universal this behaviour is for other drivers, but my information regarding resending packets with the Chord driver comes from this post (and a few others):

It's true that standard driverless USB does not resend faulty packets; but with the Chord Windows driver, it does. It's also true that standard USB has extremely low USB errors too, and if you got faulty data, it would sound as clicks and ticks. I have never heard a tick via USB from my mobile phone ever, and that is driverless.
As too optical errors - it either happens all the time (struggling with 192) or never, so SPDIF is actually robust in practice. I do all my measurements (some taking hours) with optical, and one bit failure I would see it in the measurements, and I never have.