HQPlayer Linux Desktop and HQplayer embedded

[Miska]

On 11/30/2018 at 8:31 PM, gvl said:

Another stupid question, how hard of a requirement is the SSE4.2 support for HQPE? Is it only needed for specific filters or HQ won't run at all? I have a E6500-based vintage small factor PC laying around, it should technically be beefy enough to run PCM filters but it doesn't have SSE4.2.

 

It will cause "illegal instruction" crash quite fast without SSE4.2. Only version that runs on SSE2 and up is the 32-bit Windows version.

 

[guiltyboxswapper]

6 minutes ago, Miska said:

 

Jessie is quite outdated, why not use Stretch instead which is current -stable release?

 

But yes, there's backwards compatibility to older NAA versions, so it should work. I don't really test old versions anymore, but possibly I have not broken the compatibility either.

 

 

In short, Volumio/ProJect's build has a highly optimised USB stack for the RPi (i've been informed) and have noticed the occasional pop sound on the RPI CM3 based platform so wanted to give it a try first.

 

Do you have any URLs to the older Jessie deb packages?

[Miska]

35 minutes ago, guiltyboxswapper said:

Do you have any URLs to the older Jessie deb packages?

 

If it is not on my server, I have deleted those...

 

One problem with Jessie was that the default libasound2 and kernel don't support native DSD and thus the OS itself needed patching number of components...

 

[guiltyboxswapper]

5 minutes ago, Miska said:

 

If it is not on my server, I have deleted those...

 

One problem with Jessie was that the default libasound2 and kernel don't support native DSD and thus the OS itself needed patching number of components...

 

 

I think in this case their older kernel has been patched for native DSD support.  

[acatala]

I asked a few time ago a question in the DAC forum ( Click sound at the beginning of DSD playing ) regarding the click sound that my DAC makes when it changes its mode, from PCM to DSD and viceversa. This sound is higher with HQPlayer Embedded than with Roon. I guess this has nothing to do with both pieces of sofware but with the DAC (or the AKM AK4495 chip itself). Right ?

 

Could that starting/ending noises damage the loudspeakers?

[Miska]

1 hour ago, acatala said:

I asked a few time ago a question in the DAC forum ( Click sound at the beginning of DSD playing ) regarding the click sound that my DAC makes when it changes its mode, from PCM to DSD and viceversa. This sound is higher with HQPlayer Embedded than with Roon. I guess this has nothing to do with both pieces of sofware but with the DAC (or the AKM AK4495 chip itself). Right ?

 

Could that starting/ending noises damage the loudspeakers?

 

I responded to that other thread. But it is a DAC "feature".

 

Best solution anyway is to just stick to DSD mode and not switch to PCM ever...

 

[guiltyboxswapper]

Can't seem to find Jessie based networkaudiod packages.  If anyone has a copy please get in contact.

[acatala]

1 hour ago, Miska said:

 

I responded to that other thread. But it is a DAC "feature".

 

Best solution anyway is to just stick to DSD mode and not switch to PCM ever...

 

 

I don't switch to PCM, DAC or Networkd does. When I switch on the pre-amp (with the embedded DAC) in the display I see that it is in DSD mode. After that, whenever I play or stop music it goes back and forth between DSD and PCM. Is there any configuration parameter in HQPlayer Embedded that sticks the DAC in DSD and/or PCM mode?

 

[Miska]

1 hour ago, acatala said:

I don't switch to PCM, DAC or Networkd does. When I switch on the pre-amp (with the embedded DAC) in the display I see that it is in DSD mode. After that, whenever I play or stop music it goes back and forth between DSD and PCM. Is there any configuration parameter in HQPlayer Embedded that sticks the DAC in DSD and/or PCM mode?

 

Are you using DoP or native DSD mode? With DoP the switch is likely unavoidable because DAC could be returning to PCM whenever it is not receiving DoP marker stream.

 

[acatala]

11 minutes ago, Miska said:

 

Are you using DoP or native DSD mode? With DoP the switch is likely unavoidable because DAC could be returning to PCM whenever it is not receiving DoP marker stream.

 

 

Yes, I use DoP. Your point makes perfect sense.

 

The NAA is running Linux (DietPi or your NAA image). I guess I can not use native DSD with Linux, or am I wrong? The NUC that runs Roon and HQPlayer Embedded, runs in Debian Linux, so when I have tried the NUC directly attached to the DAC I also have used DoP.

 

[Miska]

1 hour ago, acatala said:

The NAA is running Linux (DietPi or your NAA image). I guess I can not use native DSD with Linux, or am I wrong? The NUC that runs Roon and HQPlayer Embedded, runs in Debian Linux, so when I have tried the NUC directly attached to the DAC I also have used DoP.

 

You could try my bootable HQPlayer Embedded image from USB flash stick on the NUC and see if it recognizes native DSD capability with your DAC (DoP disabled).

 

[asdf1000]

Hi @Miska

 

Does a RAM upgrade affect the fingerprint for HQPe ?

 

[asdf1000]

Also Jussi, trying out the miniDSP USBStreamer with your bootable HQPe image.

 

I can't see USBStreamer as an "input" but it is there strangely under network backend and ALSA backend:

 

 

 

 

 

 

[Miska]

3 hours ago, Em2016 said:

Does a RAM upgrade affect the fingerprint for HQPe ?

 

No, RAM, HDD/SSD and GPU are not part of the fingerprint, those are usual upgrades to do.

 

3 minutes ago, Em2016 said:

Also Jussi, trying out the miniDSP USBStreamer with your bootable HQPe image.

 

I can't see USBStreamer as an "input" but it is there strangely under network backend and ALSA backend:

 

The current image doesn't have it configured, while the Debian package does. You can either wait for couple of days for me to get new HQPE release out, or alternatively you can copy the relevant lines from your DietPi setup to the image setup.

 

You can use backup functionality to retrieve settings file from both. Then you can open both in text editor and copy-paste the relevant <input> element lines from one to another and then restore the settings "backup" back to the image. Windows Notepad doesn't usually handle Unix line feeds correctly (unless they have recently fixed it), but many better editors do. So if editor shows the entire file as single line, it is not handling line feeds correctly. It should be neatly indented file.

 

[asdf1000]

1 minute ago, Miska said:

No, RAM, HDD/SSD and GPU are not part of the fingerprint, those are usual upgrades to do.

 

Nice. Thanks.

 

1 minute ago, Miska said:

The current image doesn't have it configured, while the Debian package does. You can either wait for couple of days for me to get new HQPE release out

 

Crap, I forgot you mentioned that last week. No rush at all.

 

Ok I'll boot in Debian/Dietpi again and try USBstreamer setup again. I do remember seeing USBstreamer there in "Input".

 

[asdf1000]

We have lift off!

 

Chromecast audio --> miniDSP USBStreamer --> HQP Embedded working great.

 

[gvl]

13 hours ago, Em2016 said:

We have lift off!

 

Chromecast audio --> miniDSP USBStreamer --> HQP Embedded working great.

 

 

Any particular reason to use the USBStreamer with the CCA? I picked a used Edirol UX-1ex interface for cheap, works fine in my limited tests.

[asdf1000]

15 minutes ago, gvl said:

 

Any particular reason to use the USBStreamer with the CCA? I picked a used Edirol UX-1ex interface for cheap, works fine in my limited tests.

 

I got the USBStreamer only because Jussi has one.

 

But I saw your post about the Roland working.

 

It’s cool that there are multiple options.

 

Especially for Chromecast Audio, I don’t think either has an advantage as both support 24/96kHz.

 

[Miska]

USBStreamer is very simple and reasonably priced Toslink I/O device (well, in fact it also has couple of extra I2S inside). Should be always bit-perfect without hassle. And that's why I have it in use, two small dongles connected together; Chromecast Audio and USBStreamer.

 

I first got some fancier devices, like Mutec MC-1.2 just to discover that they have ASRC engaged between input and USB, or some other problems, and not any better functionality otherwise.

 

So now I have three input devices of choice. miniDSP USBStreamer, RME ADI-2 and RME HDSPe AIO. Although AIO's Linux driver is a bit buggy and it doesn't completely work as intended, but optical input happens to work up to 96k with automatic rate switching. On ADI-2 all digital inputs work up to max rate with automatic rate switching, but that took me some extra driver development effort. USBStreamer doesn't have automatic rate switching because it just lacks needed extra functionality, but with manual rate switching it works fine.

 

Certainly there are more interfaces that work fine, for a while I just gave up buying more to find out which ones work and which don't. So any information about other devices that work is very welcome indeed!

 

[gvl]

ASRC in Mutec 1.2 on the SPDIF input? Really? Who would have thought.

 

I'm curious Is there any danger of running into buffer underruns when using the chain CCA -> HQPE -> Async USB DAC if the DAC's clock spins a bit faster than the CCA's?

[asdf1000]

31 minutes ago, Miska said:

Should be always bit-perfect without hassle.

 

Yep, first thing I tested was DoP64 (USB to Toslink conversion) and had no issues.

 

I assume it should be fine in reverse too.

 

[Miska]

8 hours ago, Em2016 said:

Yep, first thing I tested was DoP64 (USB to Toslink conversion) and had no issues.

 

I assume it should be fine in reverse too.

 

One can actually test it too. HQPlayer supports DoP on inputs, it just needs to be enabled. In the <input> element following attributes do it:

pack_sdm="1" format="auto"

 

I'll enable this on next release for USBStreamer at 176.4/192k input rates.

 

[asdf1000]

9 minutes ago, Miska said:

 

One can actually test it too. HQPlayer supports DoP on inputs, it just needs to be enabled. In the <input> element following attributes do it:

pack_sdm="1" format="auto"

 

I'll enable this on next release for USBStreamer at 176.4/192k input rates.

 

 

Nice! I have a Pi2Design 502DAC which has TOSlink output that outputs DoP64 and PCM192kHz, that I can test as a DoP64 source, into USBStreamer.

[Miska]

9 hours ago, gvl said:

ASRC in Mutec 1.2 on the SPDIF input? Really? Who would have thought.

 

Yes, I think all their interfaces do that for inputs. And they got just mad at me when I proposed that it would be nice to instead indicate the detected input rate to USB host and not do ASRC but get bit-perfect data instead.

 

Reason they do that is because UAC is quite stupid in a way that USB host sets the sample rate... All (?) UAC devices have a clock validity flag that I could use, but they don't actually utilize it but instead set it always to "valid".

 

But RME does everything I need. I just needed to implement support for the non-standard extensions to retrieve information about detected input rate and lock status.

 

9 hours ago, gvl said:

I'm curious Is there any danger of running into buffer underruns when using the chain CCA -> HQPE -> Async USB DAC if the DAC's clock spins a bit faster than the CCA's?

 

Or other way around with buffer overflow, if CCA runs faster. There's a resync and you'll have a small gap when that happens. Eventually it will, but HQPlayer has so large FIFOs at both sides that usually that would take a very long time to happen. Advantage of this is that amount of jitter at input side doesn't matter, because everything is completely reclocked by the DAC and there's no clock dependency between input and output. This is why you can input at 44.1k and output at 768k for example, and without ASRC.

 

[asdf1000]

39 minutes ago, Miska said:

Or other way around with buffer overflow, if CCA runs faster. There's a resync and you'll have a small gap when that happens. Eventually it will, but HQPlayer has so large FIFOs at both sides that usually that would take a very long time to happen.

 

So the worst that would ever happen (after a long duration) is a brief dropout in audio? (with DSD512)

 

Not a nasty loud pop?