HQ Player

[Miska]

39 minutes ago, sdmarquart said:

Thanks @Miska So, for my HQPlayer settings do I turn on DSD direct or leave it as my sdm settings? 

 

I was hoping that by using DSD direct on the adi-2, it would improve the sound of everything coming from HQP, be it dsf files or other non dsf files. Pretty sure it will since they are sending DSD over dop in SDM to the ADI-2. In direct DSD mode, I’m still outputting everything (usb, coaxial, optical) to a passive preamp with volume control, correct? Where do I set the ADI-2’s volume control to -3.5? 

 

Here are my ADI-2 settings, you can also see that volume is turned to -3.5 dB.

 

 

 

41 minutes ago, sdmarquart said:

By going DSD direct on the adi I no longer get volume control on the unit, it all happens at the passive preamp, correct?

 

Yes, ADI-2 won't have volume control for DSD sources anymore. Note that passive preamps may have compatibility issues, the overall result largely depends on properties of next component's input. This is because it drastically increases source impedance seen by the next component. It also emphasizes properties of the cable used between the two (need to pay attention for low capacitance cable).

 

 

Here's my office desktop setup I use for most HQPlayer development:

 

Volume control is handled by the Schiit. It has the "Balanced DAC" module for YouTube etc. But they also have phono input module which could be useful for you. ADI-2 is connected through balanced and Holo Spring through unbalanced (this is why I'd like the Benchmark HPA-4 because it has more than one balanced input).

 

If you don't need a headphone amp, the Schiit Freya S or Freya + seems like a good reasonably priced choice.

 

[asdf1000]

5 hours ago, Em2016 said:

 

Hi @Ales Prochazka

 

I've been enjoying your Bauer crossfeed files very much. Chu Moy is my favourite.

 

I have two questions, if you can kindly help

 

Q1) I see in your included "hqp.png" file, you have impulse response .wav files

 

But in your zip file I only use ChuMoy the high_pass.wav and low_pass.wav files

 

Am I missing impulse response files or do I have it ok?

 

See below: top is your "hqp.png" file settings and bottom is my settings.

 

Q2) Is gain -2dB enough for ChuMoy crossfeed? I do use -3dB fixed volume in main HQP volume settings for up-sampling to DSD256.

 

Many thanks in advance

 

 

 

 

Edit: sorry @Ales Prochazka - I see the difference is just HQP Embedded vs Desktop, when I look at my Embedded machine. So no problem there.

 

So my only question is about -2dB gain with your Chu Moy crossfeed files.  

 

Is there any issue with having 0dB, if I have (example) -6dB fixed volume in HQP Embedded main volume?

 

 

 

[fusos]

Hi @Miska i've been using HQPlayer with Allo DigiOne as an endpoint connected to my Supernait, upsampling to 192/24. However i noticed that the NAA always reports and set itself as 32 bit although this rate isn't supported by the DigiOne, neither by my Supernait. Changing the HQPlayer bit settings doesn't have any effect and i . Couldn't also find any ALSA settings which would cause that.

 

Here is the log from HQPlayer: 

  2019/07/16 10:01:20 Audio engine: network
  2019/07/16 10:01:20 Input set channels: 2 (2)
  2019/07/16 10:01:20 Input DAC bits: 24
  2019/07/16 10:01:20 Output set channels: 2 (2)

  2019/07/16 10:01:21  Network endpoint: snd_allo_digione:  (hw:CARD=sndallodigione,DEV=0)
  2019/07/16 10:01:21 Discovered 1 Network Audio Adapters
+ 2019/07/16 10:01:21 Connect to 192.168.0.21:43210 [ipv4]
  2019/07/16 10:01:21 Network format: 32000/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 44100/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 48000/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 64000/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 88200/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 96000/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 176400/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 192000/32/2 [pcm] 
+ 2019/07/16 10:01:27 Control connection from 127.0.0.1:52871
+ 2019/07/16 10:01:27 Control started from 127.0.0.1:52871

+ 2019/07/16 10:01:28 Playback engine running
  2019/07/16 10:01:28 Rate or blocksize change triggered
  2019/07/16 10:01:28 Rate: 44100, block size: 2352, frame size: 588
  2019/07/16 10:01:28 Block size: 2352 (sample: 2)
  2019/07/16 10:01:28 Playback engine ratio: 4.35374

This is from DigiOne:

 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA device: hw:CARD=sndallodigione,DEV=0
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA access mode: RW_INTERLEAVED
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format: S24_LE
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM bits: 32
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM physical width: 32
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM rates: 32000 - 192000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA DSD not supported
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 32000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 44100
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 48000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 64000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 88200
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 96000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 176400
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 192000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA backend initialized
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 32000/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 44100/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 48000/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 64000/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 88200/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 96000/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 176400/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 192000/32/2
 10:01:29 DigiOne : sh: 1: /etc/networkaudiod/onstart: not found
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): start 192000/32/2 [pcm]
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): Set channels: 2 (2)
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): Set sampling rate: 192000 (192000)
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA engine starting...
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA channels: 2 - 2
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA active channels: 2
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA number of periods: 4
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA period times: 166 - 85334
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA period sizes: 32 - 16384
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA period time: 85333
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA period size: 16384
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA engine started at: 192000 (192000)
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): enter streaming mode
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA engine running...

And this what i get from ALSA output:

access: RW_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 1920
buffer_size: 7680

This looks to me like that the 16 bit Source is converted to 24bit by HQPlayer then to 32bit by NAA Daemon and back to  24bit by ALSA. Is this really the case and how can i set the NAA Daemon to 24bit?

 

 

[Ales Prochazka]

50 minutes ago, Em2016 said:

 

Edit: sorry @Ales Prochazka - I see the difference is just HQP Embedded vs Desktop, when I look at my Embedded machine. So no problem there.

 

So my only question is about -2dB gain with your Chu Moy crossfeed files.  

 

Is there any issue with having 0dB, if I have (example) -6dB fixed volume in HQP Embedded main volume?

 

 

 

 

Hi,

try to set 0 dB and check the HQPlayer limiter. If the limiter is active, correct the gain 
 

[asdf1000]

6 minutes ago, Ales Prochazka said:

 

Hi,

try to set 0 dB and check the HQPlayer limiter. If the limiter is active, correct the gain 
 

 

Many thanks.  I knew the limiter is how to check if main volume control for up-sampling is insufficient - but wasn't sure how to know if matrix pipeline gain is too high. So it's the same check. Thanks again

[Miska]

2 hours ago, fusos said:

Hi @Miska i've been using HQPlayer with Allo DigiOne as an endpoint connected to my Supernait, upsampling to 192/24. However i noticed that the NAA always reports and set itself as 32 bit although this rate isn't supported by the DigiOne, neither by my Supernait. Changing the HQPlayer bit settings doesn't have any effect and i . Couldn't also find any ALSA settings which would cause that.

 

Here is the log from HQPlayer: 

  2019/07/16 10:01:20 Audio engine: network
  2019/07/16 10:01:20 Input set channels: 2 (2)
  2019/07/16 10:01:20 Input DAC bits: 24
  2019/07/16 10:01:20 Output set channels: 2 (2)

  2019/07/16 10:01:21  Network endpoint: snd_allo_digione:  (hw:CARD=sndallodigione,DEV=0)
  2019/07/16 10:01:21 Discovered 1 Network Audio Adapters
+ 2019/07/16 10:01:21 Connect to 192.168.0.21:43210 [ipv4]
  2019/07/16 10:01:21 Network format: 32000/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 44100/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 48000/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 64000/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 88200/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 96000/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 176400/32/2 [pcm] 
  2019/07/16 10:01:21 Network format: 192000/32/2 [pcm] 
+ 2019/07/16 10:01:27 Control connection from 127.0.0.1:52871
+ 2019/07/16 10:01:27 Control started from 127.0.0.1:52871

+ 2019/07/16 10:01:28 Playback engine running
  2019/07/16 10:01:28 Rate or blocksize change triggered
  2019/07/16 10:01:28 Rate: 44100, block size: 2352, frame size: 588
  2019/07/16 10:01:28 Block size: 2352 (sample: 2)
  2019/07/16 10:01:28 Playback engine ratio: 4.35374

This is from DigiOne:

 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA device: hw:CARD=sndallodigione,DEV=0
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA access mode: RW_INTERLEAVED
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format: S24_LE
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM bits: 32
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM physical width: 32
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM rates: 32000 - 192000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA DSD not supported
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 32000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 44100
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 48000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 64000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 88200
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 96000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 176400
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA rate available: 192000
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA backend initialized
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 32000/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 44100/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 48000/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 64000/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 88200/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 96000/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 176400/32/2
 10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format available: 192000/32/2
 10:01:29 DigiOne : sh: 1: /etc/networkaudiod/onstart: not found
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): start 192000/32/2 [pcm]
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): Set channels: 2 (2)
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): Set sampling rate: 192000 (192000)
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA engine starting...
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA channels: 2 - 2
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA active channels: 2
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA number of periods: 4
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA period times: 166 - 85334
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA period sizes: 32 - 16384
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA period time: 85333
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA period size: 16384
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA engine started at: 192000 (192000)
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): enter streaming mode
 10:01:29 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA engine running...

And this what i get from ALSA output:

access: RW_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 1920
buffer_size: 7680

This looks to me like that the 16 bit Source is converted to 24bit by HQPlayer then to 32bit by NAA Daemon and back to  24bit by ALSA. Is this really the case and how can i set the NAA Daemon to 24bit?

 

 

 

Source number of bits is irrelevant.

 

That same info is also in the HQPlayer log you pasted:

Quote

10:01:21 DigiOne : [/usr/sbin/networkaudiod] (528): ALSA PCM format: S24_LE

 

Then if you refer to ALSA documentation:

So it is 24-bit data put into 32-bit container, LSB-aligned. Quite rare to see this one in use. Opposed to S24_3LE:

Which is actually 24-bit only, but highly inefficient to deal with because of the 3 byte size.

 

Your Allo kernel is probably too old to know better. Just in case, set "DAC Bits" in HQPlayer to 24. Rest is already dealt with for you.

 

[fusos]

40 minutes ago, Miska said:

 

Source number of bits is irrelevant.

 

That same info is also in the HQPlayer log you pasted:

 

Then if you refer to ALSA documentation:

So it is 24-bit data put into 32-bit container, LSB-aligned. Quite rare to see this one in use. Opposed to S24_3LE:

Which is actually 24-bit only, but highly inefficient to deal with because of the 3 byte size.

 

Your Allo kernel is probably too old to know better. Just in case, set "DAC Bits" in HQPlayer to 24. Rest is already dealt with for you.

 

 

Is there a way to change this? The optimal input for my DAC is 20bit, in fact if i connect my computer directly to it, HQPlayer shows the output as 20bit (i guess it auto detects it). But the DigiOne always outputs as 32bit (or s24_LE which apparently is them same) regardless of which setting i put into HQPlayer. And I'm quite confident that the 20bit option sounds better. Just took a look at the ALSA documentation and noticed that there should be actually option to output to 20bit.

 

So is this something which the NAA Daemon could tell ALSA to do, or perhaps if i switch to your Raspberry image?

 

 

[Miska]

3 hours ago, fusos said:

Is there a way to change this? The optimal input for my DAC is 20bit, in fact if i connect my computer directly to it, HQPlayer shows the output as 20bit (i guess it auto detects it). But the DigiOne always outputs as 32bit (or s24_LE which apparently is them same) regardless of which setting i put into HQPlayer. And I'm quite confident that the 20bit option sounds better. Just took a look at the ALSA documentation and noticed that there should be actually option to output to 20bit.

 

So is this something which the NAA Daemon could tell ALSA to do, or perhaps if i switch to your Raspberry image?

 

There's a difference between the "wire format" that you cannot change without modifying the DAC firmware - this is what ALSA format reports and is based on what the DAC's USB Audio Class descriptor says. And how many active bits HQPlayer uses on that wire protocol. You can just set "DAC Bits" in HQPlayer to 20 if the auto-detection doesn't work. Unused bits are then padded as zeros and dithering/noise-shaping depth is correct.

 

S32_LE and S24_LE are drastically different although both are 32-bit wide. If you send S32_LE to a DAC that uses S24_LE you will get really strange output. If you send S24_LE to a DAC that uses S32_LE, your output volume is effectively around -48 dBFS.

 

Other images than x64 are somewhat outdated at the moment.

 

[DancingSea]

12 hours ago, Miska said:

 

Please take the Aurender discussion to some Aurender thread, out of HQPlayer thread. Thanks!

 

 

It’s not about specifically about the Aurender, more about standalone streamers/ players vs a PC/ Mac.  Small Green Computers sells, as you know, the SonicTransporters, some of which are specifically designed for HQPlayer.  What are your thoughts on the various HQP capable SonicTransporter offerings vs PC’s?  Do those possess the same tiny brains as the Raspberry Pi?

[Superdad]

20 minutes ago, DancingSea said:

 What are your thoughts on the various HQP capable SonicTransporter offerings vs PC’s?  Do those possess the same tiny brains as the Raspberry Pi?

 

Of course not.  Full on Intel i9 8-core processor. It's listed right on the Small Green Computer's SonicTransporter web page:

https://www.smallgreencomputer.com/collections/audio-server/products/sonictransporter-roon-server-hqplayer?variant=21739021508

 

[Miska]

41 minutes ago, DancingSea said:

It’s not about specifically about the Aurender, more about standalone streamers/ players vs a PC/ Mac.  Small Green Computers sells, as you know, the SonicTransporters, some of which are specifically designed for HQPlayer.  What are your thoughts on the various HQP capable SonicTransporter offerings vs PC’s?  Do those possess the same tiny brains as the Raspberry Pi?

 

As @Superdad said, SGC's sonicTransporter, PinkFaun Streamer 2.16 or Antipodes CX are whole different category. Or something like Roon Nucleus for that matter.

 

Then rest depends on what kind of software the server runs. Of course it is also possible to run very dumb down software on a powerful machine, not that it would make so much sense though.

 

[LoryWiv]

14 hours ago, Miska said:

 

Default range is from -60 to 0... There's no need to change it, what matters is where the volume knob is actually set. With -3/-3 it can just go to one setting and nothing else. I use -6 to 0 range myself, normal setting thus having volume knob pointing up at -3 setting. This allows some small trim adjustment. For about 90+ % of material -3 setting is fine. There are few albums where lower volume settings may be needed.

 

By keeping volume knob at -3.0, aren't we attenuating signal? Would it be preferred to set the highest non-clipping volume to avoid the traditional truncating / lossy effects of digital volume control, or is that no longer relevant as digital volume control algorithms have advanced? 

[ted_b]

-3 is, inevitably, the highest non-clipping volume for DSD, cuz many times the DSD signal is pushed and can activate the limiter in HQPlayer (limit counter and red volume knob)

[LoryWiv]

I see, that makes sense....so de facto is that generally the correct setting for outputting PCM to DSD of just for native DSD file playback? Thanks for clarifying.

[Miska]

8 minutes ago, LoryWiv said:

By keeping volume knob at -3.0, aren't we attenuating signal? Would it be preferred to set the highest non-clipping volume to avoid the traditional truncating / lossy effects of digital volume control, or is that no longer relevant as digital volume control algorithms have advanced? 

 

If the modulator for example has ~180 dB SNR in the audio band, and your DAC/amplifier has in best case 130 dB SNR, you don't need to really worry about "lossy" effects of volume control. If your digital SNR is 177 dB instead of 180 dB it doesn't really make practical difference. Especially given that listening room likely has around 30 dB background noise and you cannot "safely" listen with peaks higher than 120 dB. These days most of the losses are because of pushing digital levels too high, not having something too low. Even for most material, RedBook would have plenty of unused dynamic range downwards.

 

If you start hearing background hiss, like on tape or AM radio, when you turn down good digital volume control, you know you are getting to the limit. Most likely that hiss would still be from analog equipment having too much gain rather than digital background noise.

 

Important thing is that background is noise (random spectrum) instead of distortion (discrete spectrum). So those effects only apply to badly done digital volume control.

 

[LoryWiv]

21 minutes ago, Miska said:

 

If the modulator for example has ~180 dB SNR in the audio band, and your DAC/amplifier has in best case 130 dB SNR, you don't need to really worry about "lossy" effects of volume control. If your digital SNR is 177 dB instead of 180 dB it doesn't really make practical difference. Especially given that listening room likely has around 30 dB background noise and you cannot "safely" listen with peaks higher than 120 dB. These days most of the losses are because of pushing digital levels too high, not having something too low. Even for most material, RedBook would have plenty of unused dynamic range downwards.

 

If you start hearing background hiss, like on tape or AM radio, when you turn down good digital volume control, you know you are getting to the limit. Most likely that hiss would still be from analog equipment having too much gain rather than digital background noise.

 

Important thing is that background is noise (random spectrum) instead of distortion (discrete spectrum). So those effects only apply to badly done digital volume control.

 

Understood, appreciated, and CLEARLY far preferable to clipping. Thank you.

[DancingSea]

4 hours ago, Miska said:

 

As @Superdad said, SGC's sonicTransporter, PinkFaun Streamer 2.16 or Antipodes CX are whole different category. Or something like Roon Nucleus for that matter.

 

Then rest depends on what kind of software the server runs. Of course it is also possible to run very dumb down software on a powerful machine, not that it would make so much sense though.

 

 

But isn’t the “Rasberry Pi” low level of computing power found in expensive music servers by design to reduce noise?

[AnotherSpin]

4 hours ago, DancingSea said:

 

But isn’t the “Rasberry Pi” low level of computing power found in expensive music servers by design to reduce noise?

 

It was discussed in the thread I've mentioned above - weak vs. powerful processors. The whole NAA idea is about taming the noise, btw. 

[Miska]

6 hours ago, DancingSea said:

But isn’t the “Rasberry Pi” low level of computing power found in expensive music servers by design to reduce noise?

 

That's why there's a NAA and devices like Rendu and sMS-200, or DACs like the T+A and exaSound. Or you can use something like UP Gateway.  Extremely light weight audio end point, not player, but just audio endpoint that only works as a data buffer between network and DAC.

 

You need very powerful DSP algorithms to have most accurate analog reconstruction from especially RedBook content. That's why we use latest CPUs and GPUs to do the processing.

 

You get best of both worlds, very powerful computer (with extremely good price/performance ratio) for the processing. And very low power and simple audio endpoint for the audio endpoint. Network being isolation barrier between the two. If you want to go extreme, you can easily use optical networking between the two.

 

[jamesg11]

I eventually found that my 24-192 pcm albums cause skips & stutters ... otherwise all good with HQP upsampling everything to dsd256x48, including redbook files.

 

Suggestions for any settings that might allow success with these larger pcm files?

I did search for such here, but no hints worked so far.

 

HQP 3. - macmini - urendu - rme adi-2

[asdf1000]

37 minutes ago, jamesg11 said:

I eventually found that my 24-192 pcm albums cause skips & stutters ...

 

Probably the same reason as:

 

https://audiophilestyle.com/forums/topic/19715-hq-player/page/602/?tab=comments#comment-970797

[Miska]

34 minutes ago, jamesg11 said:

HQP 3. - macmini - urendu - rme adi-2

 

Can you share a screenshot of your HQPlayer settings?

 

[asdf1000]

Hi @Miska

 

With HQP Desktop, when using USBStreamer input on macOS (Mojave), do you use "miniDSP internal clock" or "miniDSP toslink clock"?

 

On HQPe, I always use "miniDSP toslink clock" (selected in alsamixer) and this eliminated the small pops issues I previously had.

 

On HQP Desktop 4, if I select "miniDSP toslink clock" in  Audio MIDI Setup,  I can't select input sample rates - I'm limited to 44kHz for both input and output.

 

 

[Miska]

7 hours ago, Em2016 said:

With HQP Desktop, when using USBStreamer input on macOS (Mojave), do you use "miniDSP internal clock" or "miniDSP toslink clock"?

 

On HQPe, I always use "miniDSP toslink clock" (selected in alsamixer) and this eliminated the small pops issues I previously had.

 

On HQP Desktop 4, if I select "miniDSP toslink clock" in  Audio MIDI Setup,  I can't select input sample rates - I'm limited to 44kHz for both input and output.

 

I have never used USBStreamer on anything else than  Linux. But you really need to set it to Toslink clock when using the input, because it needs to be slaved to sender's clock. If you use only output, then it needs to be set to internal clock, because otherwise it doesn't have a clock at all. This is because on S/PDIF and AES/EBU the sender is always master clock and receiver is slave.

 

When slaved, probably the listed rates are limited to the detected input frequency.

 

[sdmarquart]

On 7/15/2019 at 2:10 PM, JTS said:

I would recommend putting a pre between the RME and your monitors - a passive balance pre, or something like a Schiit Freya which allow you to run passive, jfet or tube gain. It will allow you to run the RME in DSD direct which works very very well. I run it in passive for work and tubes for pleasure listening.

 

I just bit the bullet on the Freya +. Looking forward to adding this using HQPlayer and DSD Direct on the RME. Will report back soon. I appreciate all the info!

 

Thanks,

Spence