HQP and Chord Qutest

I hope you’re case is resolved but from personal experience, i fear the infamous white noise blast is not far away :pensive:

I hope i’m wrong. Keep us posted

1 Like

I certainly don’t want to be a killjoy, but I also did all this and thought the issue was solved, but the white noise will happen at anytime and at the moment you’re least expecting it. Happy listening for now!

1 Like

:smile: I lived in fear with headphones, waiting for it.

Anxiety filled listening sessions. Good times.

1 Like

LOL! Thanks guys.

I have noticed when I am playing an album there is no re-init of the DAC. It only seems to occur in play lists from different albums.

I’ll update when I have something new to say. So far so good.

2 Likes

Must be even worse through cans. Brave man! :grinning:

1 Like

I have a Qutest and I reported elsewhere in this forum that my white noise problems were reduced greatly when I used a Raspberry Pi 4 and its USB 3 ports into the Qutest at 705 / 768 – i.e. the white noise occurred hardly ever.

I also have a SRC-DX and use this now in preference to the USB – at the moment I have nothing connected to the Qutest’s USB port. Again, I hardly ever get the white noise using this, at 705 / 768. I think it has happened once in about 4 months of SRC DX use. I found that when I want to use the double data rate to get 705 / 768 on the SRC DX you have to use a USB 2.0 port on the Raspberry Pi 4 – NOT the USB 3 port – it doesn’t want to do the double data rate when you connect it to the USB 3 port. No idea why, but I am not complaining. Sounds very nice indeed.

BTW I am using Ropieee XL for the HQP NAA and it is flawless.

Hope this is helpful

1 Like

I’m surprised the SRC-DX had this issue at all

Ever had this @Daniel_Mance ?

1 Like

@Steve_Taylor1 that sounds awesome, but I also have good news to report. I compiled on arch linux the real time kernel. I’ve been hammering roon and by extension HQ and Dac all afternoon. No white noise so far! I also do not see the Dac being reinitialized like I did before.

I have never had this issue on SRC-DX with Qutest using dual BNC 705/768 in over 1 year of use. I was a regular victim of the white noise on USB typically when switching rate to 48k base. SRC DX sounds a bit more relaxed too (or perhaps it’s me that’s more relaxed not being on tenterhooks waiting to get blasted).

5 Likes

That’s promising. I guess if my music is interrupted again I’ll have to look into purchasing the SRC-DX. It’s just after my outlay on Dac roon and hq…

1 Like

When you play with standalone HQPlayer and output rate is fixed, the DAC keeps running without interruptions from start of playback to end of playback. If rate changes, Roon usually asks HQPlayer to stop before switching to the new content and this causes DAC restart.

But with my Mojo, even when playing Spotify through CCK at 44.1k from iPhone, eventually there is sudden full volume white noise blast in the middle of some track. I ended up shelving my Mojo because of that.

That would explain the apparent stability I’m experiencing. Maybe next month if Zeus is willing, I’ll pick up the SRC DX and try it. I just like the sound of the Qutest too much to get rid of it right now

It should go away completely that way. But if it can still happen, it is likely some data sync problem further down the line where data falls out of word clock sync.

Usually source is Amanero based USB interfaces with certain firmware versions where clocking runs awry and the data becomes corrupted as a result. It is not completely unusual. Some XMOS interfaces running MQA have also issues, but they just have data packet loss, that results in snap-crackle-and-pop.

1 Like

That’s good to hear. I have a question for you. Will you be supporting libFLAC ver. 1.4 soon?

I’ve soft linked libFLAC.so.8 to libFLAC.so.12 but I find the HQ Player freezes sometimes

Why? On which platform?

On Linux distributions, the distro’s libFLAC is used. In other cases, the latest release source code is used.

Oh, that’s curious then. I’m using Arch Linux which converts the rpm to a Arch package.

If you are using RPM, then the version shipped by Fedora 36 is being used.

Arch is not among the supported distributions.

I see. Considering the popularity of Arch, any chance in adding to your workload and spinning up a package for Arch? :smile:

It is not popular enough compared to the distributions I support. It is not among supported distributions for my build tooling.

Fair enough. I had to ask :smile:

1 Like