Roon / HQPlayer Integration

[ted_b]

I am also experiencing random stoppage on DSD sources (but never with PCM).

 

Unlike Ted I am NOT processing DSD files... I thought that wasn't advised... now I need to try it.

 

I only process DSD (and PCM, of course) because the modulators are so good and the clear sweetspot of two of my SABRE DSD dacs is DSD256....no brainer for those dacs.

[KMan]

Well it is nice to know I am not crazy or experiencing something unique to my setup. As I told Ted, I have tried every possible combination to thwart this issue BUT to no avail.

 

Hopefully the two companies will put their resources together to solve the issue. After hearing HQP there is no going back SO hopefully Roon will resolve whatever issues there are with HQP or I am sure some else will. In any case until such time I will have to load my DSD albums manually into HQP and listen that way.

 

Priaptor, ted_b: Myself and Zorntel were able to replicate this issue, DSD64 would stop exactly at 12 minutes 40 seconds, and DSD128 at 6 minutes 20 seconds etc. Brian on Roon forum was able to track down the problem (a 32 bit signed integer overflow) and already has a Alpha that fixes the issue. Post #174 has the details.

[ted_b]

Priaptor, ted_b: Myself and Zorntel were able to replicate this issue, DSD64 would stop exactly at 12 minutes 40 seconds, and DSD128 at 6 minutes 20 seconds etc. Brian on Roon forum was able to track down the problem (a 32 bit signed integer overflow) and already has a Alpha that fixes the issue. Post #174 has the details.

 

Nice! Good work guys.

[One and a half]

Priaptor, ted_b: Myself and Zorntel were able to replicate this issue, DSD64 would stop exactly at 12 minutes 40 seconds, and DSD128 at 6 minutes 20 seconds etc. Brian on Roon forum was able to track down the problem (a 32 bit signed integer overflow) and already has a Alpha that fixes the issue. Post #174 has the details.

 

Heh, my cup runneth over with bits....

[orgel]

Priaptor, ted_b: Myself and Zorntel were able to replicate this issue, DSD64 would stop exactly at 12 minutes 40 seconds, and DSD128 at 6 minutes 20 seconds etc. Brian on Roon forum was able to track down the problem (a 32 bit signed integer overflow) and already has a Alpha that fixes the issue. Post #174 has the details.

 

Thanks a million for isolating and reporting this. I've been listening to a fair amount of Bruckner and Mahler over the unexpectedly long weekend while snowed in, and repeatedly ran into the "12:40" bug. I was going to ask today if anyone else was experiencing this.

 

--David

[craighartley]

Thanks a million for isolating and reporting this. I've been listening to a fair amount of Bruckner and Mahler over the unexpectedly long weekend while snowed in, and repeatedly ran into the "12:40" bug. I was going to ask today if anyone else was experiencing this.

 

--David

 

Same here (apart from the snow)...

[Germanboxers]

I had a very unusual issue occur last night while listening to Roon->HQPlayer->Linux NAA. In the middle of a song, the guitar and singer shifted places in the soundstage, along with a little hiss and crackle. It then switched back 30 sec later...never heard that before on this album. Is it even possible to have L/R balance shifted in the digital domain with out the intention of doing so?

 

Thanks,

 

Jordan

[Miska]

I had a very unusual issue occur last night while listening to Roon->HQPlayer->Linux NAA. In the middle of a song, the guitar and singer shifted places in the soundstage, along with a little hiss and crackle. It then switched back 30 sec later...never heard that before on this album. Is it even possible to have L/R balance shifted in the digital domain with out the intention of doing so?

 

Sounds like data transfer problem (packet loss) on USB or some transfer error between USB interface and the D/A conversion stage inside the DAC...

 

Sometimes iFi iDSD Nano does similar tricks for me, or echo-effect. Seems to happen due to some electrical disturbance coming through the headphone socket.

 

Also make sure you don't turn volume too high in HQPlayer, I don't recommend exceeding -2 dBFS setting. Overload due to inter-sample overs doesn't sound nice... ("Limited" value in HQPlayer window should never change from 0)

[sdolezalek]

How do the new "auto" settings function in Beta 3.13.0? What determines the output rates and choice between DSD and PCM?

[jhwalker]

How do the new "auto" settings function in Beta 3.13.0? What determines the output rates and choice between DSD and PCM?

 

Same question here - I thought "Auto" would switch the DSD128 sampling rate to 5.6Mhz for 44.1k PCM rates (e.g., 44.1, 88.2, 176.4, etc.) and chose 6.1Mhz for 48k PCM rates (e.g., 48, 96, 192, etc.). Instead, it seems to just stick with whatever was last chosen

[Miska]

How do the new "auto" settings function in Beta 3.13.0? What determines the output rates and choice between DSD and PCM?

 

It picks highest rate supported by the hardware that is equal or below the Default/Limit set in settings and that the filter is capable of producing given the source rate.

[Miska]

Same question here - I thought "Auto" would switch the DSD128 sampling rate to 5.6Mhz for 44.1k PCM rates (e.g., 44.1, 88.2, 176.4, etc.) and chose 6.1Mhz for 48k PCM rates (e.g., 48, 96, 192, etc.). Instead, it seems to just stick with whatever was last chosen

 

If the filter can do 6.1 output for 44.1 input, that is naturally what gets selected... Why would it do something else?

[bogi]

How do the new "auto" settings function in Beta 3.13.0? What determines the output rates and choice between DSD and PCM?

 

Read here:

http://www.computeraudiophile.com/f11-software/hq-player-20293/index184.html#post506160

[craighartley]

If the filter can do 6.1 output for 44.1 input, that is naturally what gets selected... Why would it do something else?

 

Fine for what was intended, but surely it would also be really useful for lots of people to have an option to automatically relate output rate to multiple of 44.1 or 48, as for many people this is what will determine whether their computer will manage up sampling to DSD128 or DSD256. I suspect that is what a lot of people were hoping for.

[bogi]

I thought "Auto" would switch the DSD128 sampling rate to 5.6Mhz for 44.1k PCM rates (e.g., 44.1, 88.2, 176.4, etc.) and chose 6.1Mhz for 48k PCM rates (e.g., 48, 96, 192, etc.).

 

It does what you wrote only if you have set an upsampling filter, which can do only integer multiple of sample rate (closed form, poly-sinc-mqa).

 

For other filters (all apodizing if I understand that well) it is not needed to stay within a 44.1k or 48k sample rate family. HQPlayer does all upsampling to the target sample rate in one step.

[bogi]

Sometimes in the past I already asked Miska to implement something like a global checkbox in Settings

[x] Stay within sample rate family

and I would consider it to be useful. For example my PC has not enough resources with poly-sinc to upsample from 44.1k to 6.1MHz, but 44.1k to 5.6MHz plays yet well. But I like to use 6.1MHz for 48, 96 amd 192k recordings. Having such a check box I would not need to adapt bitrate in the HQPlayer main window so often.

[Miska]

Fine for what was intended, but surely it would also be really useful for lots of people to have an option to automatically relate output rate to multiple of 44.1 or 48, as for many people this is what will determine whether their computer will manage up sampling to DSD128 or DSD256. I suspect that is what a lot of people were hoping for.

 

Then there is option to use -2s family of filters where it doesn't really make practical difference. There is also benefit of using 500 kHz higher sampling rate for DSD128 or 1 MHz higher sampling rate for DSD256! That is not a small difference anymore.

 

Now the logic is straightforward, filter is asked "can you do X to Y" and that is used as basis for the selection.

[craighartley]

Then there is option to use -2s family of filters where it doesn't really make practical difference. There is also benefit of using 500 kHz higher sampling rate for DSD128 or 1 MHz higher sampling rate for DSD256! That is not a small difference anymore.

.

 

Sorry Miska but could you please indulge me by explaining further?

 

1) What do you mean by no 'practical difference'? You mean no real difference in SQ between polysinc and polysinc-2s?

 

2) Are you saying that polysinc-2s at 12.3 is likely to have advantage over polysinc at 11.2?

 

3) Theoretically does difference between polysinc and polysinc-2s to DSD256 depend on the starting rate, ie whether source file is RedBook, 176/192, or 352.8?

[Miska]

Sometimes in the past I already asked Miska to implement something like a global checkbox in Settings

[x] Stay within sample rate family

and I would consider it to be useful. For example my PC has not enough resources with poly-sinc to upsample from 44.1k to 6.1MHz, but 44.1k to 5.6MHz plays yet well. But I like to use 6.1MHz for 48, 96 amd 192k recordings. Having such a check box I would not need to adapt bitrate in the HQPlayer main window so often.

 

The part I don't like in such setting is that it would apply to all filters. To some extent I can understand it for poly-sinc (load when in SDM output mode), but for -2s variants there is no practical benefit. And I really don't want to make such conditional to different filters so it is all or nothing.

 

OK, I could add it, but always adding one more configuration option that alters the internal logic and code paths means more possible setting combinations which means more possible corner cases and bugs. Having combinatorial settings also makes learning curve of the application steeper. Good thing with the auto-rate + auto-mode was that I was able to remove the earlier obscure PCM "none" filter logic and replace it with more clear approach. So the PCM "none" doesn't have magical meanings anymore.

[craighartley]

Having such a check box I would not need to adapt bitrate in the HQPlayer main window so often.

 

Yes, which would make a huge difference to those using Roon, especially on a tablet remote.

[craighartley]

The part I don't like in such setting is that it would apply to all filters. To some extent I can understand it for poly-sinc (load when in SDM output mode), but for -2s variants there is no practical benefit.

 

Okay, sorry I misunderstood what you meant, so that now answers my first question.

[Miska]

1) What do you mean by no 'practical difference'? You mean no real difference in SQ between polysinc and polysinc-2s?

 

In terms of CPU load. So with -2s filter the load difference between 44.1 -> 5.6 and 44.1 -> 6.1 is small.

 

2) Are you saying that polysinc-2s at 12.3 is likely to have advantage over polysinc at 11.2?

 

At least technically, if you measure the DAC output, the difference between 5.6 and 6.1 is bigger than the difference between polysinc and polysinc-2s. The difference is also notable for DSD64 between 2.8 and 3.1. But depending on the DAC the absolute difference for 11.2 vs 12.3 is smaller because the analog filter has rolled off so much further at those rates.

 

The difference between the two sampling rates is easy to measure, the difference between polysinc and polysinc-2s filters is not.

 

3) Theoretically does difference between polysinc and polysinc-2s to DSD256 depend on the starting rate, ie whether source file is RedBook, 176/192, or 352.8?

 

Mathematically it depends on the ratio between source file rate and output rate.

[craighartley]

Thank you very much. Your answer to (2) is particularly interesting..

[bogi]

The part I don't like in such setting is that it would apply to all filters. To some extent I can understand it for poly-sinc (load when in SDM output mode), but for -2s variants there is no practical benefit. And I really don't want to make such conditional to different filters so it is all or nothing.

 

OK, I could add it, but always adding one more configuration option that alters the internal logic and code paths means more possible setting combinations which means more possible corner cases and bugs. Having combinatorial settings also makes learning curve of the application steeper. Good thing with the auto-rate + auto-mode was that I was able to remove the earlier obscure PCM "none" filter logic and replace it with more clear approach. So the PCM "none" doesn't have magical meanings anymore.

 

OK, I agree ... for 2s filters it wouldn't have sense. It is better to have as simple logic of HQPlayer settings as possible.

 

Did anything change on "none" PCM filter meaning? Did you mean change of the case: DirectSDM enabled, PCM defaults 'Filter'=none, PCM input and SDM(DSD) output?

http://www.computeraudiophile.com/f11-software/hq-player-20293/index82.html#post424353

[jhwalker]

Sometimes in the past I already asked Miska to implement something like a global checkbox in Settings

[x] Stay within sample rate family

and I would consider it to be useful. For example my PC has not enough resources with poly-sinc to upsample from 44.1k to 6.1MHz, but 44.1k to 5.6MHz plays yet well. But I like to use 6.1MHz for 48, 96 amd 192k recordings. Having such a check box I would not need to adapt bitrate in the HQPlayer main window so often.

 

Same here - my Mini will upsample 44.1 > 5.6 all day long . . . but change it to 6.1, and it stumbles badly. Same for 48 > 6.1 - works great. 48 > 5.6? Not so much (though better than 44.1 > 6.1).