HQPlayer4 EC modulator tips and techniques

[bodiebill]

8 hours ago, Solstice380 said:

Oh OK.   So increasing the CPU voltage stopped the dropouts?  That’s interesting.  

 

Well, I thought so, but then I only checked with redbook files. When I play a 96/24 file I again have dropouts.

@Miska Is it advisable to go back to my previous RAM which has lower CAS latency?

[bodiebill]

22 minutes ago, Miska said:

For best performance, both memory channels should be populated with low CAS latency memory. Doesn't necessarily solve the problem, but at least helps.

 

Thanks Miska. Playing PCM 96/24 material, I tried many changes to the following basic setup:

 

Windows PC with control point (UPPlay or JRiver) =>

Audiolinux Server with HQPlayer embedded upsampling to DSD256 with EC7 =>

Audiolinux endpoint with NAA

 

This I tried:

• DSD128 instead of DSD256
• non-EC7
• no upsampling at all (PCM)
• playing from different source (NAS instead of local HD)
• removing ISO Regen
• changing DAC
• trying different NAA endpoint
• substituting HQPlayer OS for AL on server
• attaching DAC directly to server (ALSA setting)
• trying normal (non-fiber) ethernet connection
• limting ethernet speed to 100Mb on both server and endpoint
• changing kernel in AL
• going back to 2 modules of lower latency Crucial Ballistix RAM
• several overclocking options (hardly relevant as the problem even occurs without upsampling)

but in all cases I have tiny dropouts (1st one after 14 seconds, then some 30 seconds later etc., irregularly). I checked the original file: playing on a mac with VLC there are no dropouts.

 

I hope it can be solved somehow, but I do not know what else to think of...

Any advice will be greatly appreciated!

 

 

[bodiebill]

11 hours ago, Miska said:

Best way to figure it out is to simplify everything as much as possible, so local content played by controlling HQPlayer with HQPlayer Client, upsampling turned off to a locally connected DAC (without Regen or other USB gadgets, with a cheap standard USB cable). And get it first working with such setup before adding anything more. Because otherwise there are way too many variables in the picture to figure out where the problem is.

 

But sounds like some I/O issue. Did you try the same DAC with the same cable from a Mac? Have you tried changing the USB cable? You could try booting up HQPlayer OS from a memory stick on another computer with DAC connected to that one, upsampling turned off again.

 

If the dropouts are small, then it may be a lost or broken USB packet (which are 125 µs long).

 

I just drastically simplified things by starting another PC (a spare laptop) with HQPlayer embedded. I played the 96/24 PCM file locally without any upsampling or conversion, trying two different DAC's with two different cables (without USB gadgets). In both cases I get the dreaded small dropouts (13s, 55s, etc.).

This happens with HQPe version 4.12.1 as well as 4.13.

 

The same file plays without problems directly on a mac, Windows PC or Chromebook with an applicable software player.

 

Here is a link to the mono 96/24 file (Hungarian String Quartet, Beethoven 1st movement of 1st string quartet):
https://drive.google.com/file/d/15GiDDTk-6bs5Q8K0bSLNLJUeCS9vpYOB/view?usp=sharing 

[bodiebill]

43 minutes ago, Miska said:

44 minutes ago, Miska said:

I can reproduce the drop-out at 13s position with this file, seeking around it always produces it at the same point, and reason can be found from the log file:

# 2019/12/26 21:35:46 ReadFLACErrorCB(): CRC error

IOW, the file is broken at that position. With VLC on Ubuntu 18.04 I get even worse sounding drop-out at that point.

 

 

Thanks Jussi for checking, appreciated!

 

So now I am a bit worried as I had dropouts with quite a few files lately. Is it possible that my media disk got corrupted, and hence some files got broken? Is there a program to check integrity of PCM files?

 

I will see if I can locate some of the source files to check their integrity.

 

The good news is that the problem does not seem to arise from lack off juice of the server, I guess.

[bodiebill]

1 hour ago, Miska said:

Best way would be to process checksums (MD5, SHA1, SHA256 or similar) against the original ones to see if the checksums match. But that may be hard to achieve if there are no multiple copies of the files.

 

I managed to locate the source file and indeed: it had a different md5 checksum and it has no dropouts! It also sounds slightly different, so I am not sure what happened. Maybe it got corrupted, while downloading or later in my system. I hope to find out before long whether this applies to other files also.

 

A relieve though that we were able to rule out most other causes that I suspected earlier. Thanks for helping out!

[bodiebill]

12 minutes ago, StreamFidelity said:

The problem of moving parts of a fan with electromagnetic fields remains. 

 

But is, in my experience, less of a problem, if the server is well (optically) isolated.