I upgraded my old PC with a beefy Nvidia GPU (P100), which already lead to impressive results: I could do DSD512 ASDM7EC-super with filters like sinc-MGa or sinc-Lh on an i3-6100, and Roon is running on the same PC! 48k base source material lead to some stuttering now and then, though.
(Side note: P100s can be found rather cheap used compared to what they are able to do. Note, though, that these cards are not meant to be used in a PC and need a non-standard fan construction that will blow air through the card. These are no graphics cards, no monitor connectors, you have to use a separate graphics card or onboard graphics. Even more importantly, Nvidia has marked them as deprecated, and they might soon fall out of CUDA support in new drivers. So think twice before you consider buying such a thing!)
I now changed my CPU to an i7-7700. As I hoped, this lead to reliable playback at all rates and with all filters I tested.
However, I had hoped I could use DAC correction for my iFi Neo iDSD, which is not the case. Or rather, I can’t use it with any 7EC modulators without stuttering; ASDM7 works.
My questions:
As the GPU doesn’t break a sweat, would it be possible in a future HQPlayer version to offload DAC correction to the GPU?
Two of the cores never get above 30% load. Are there any performance optimisations I could try that would lead to a better spread of the load? What I tried yet is setting multicore to 1 and different settings for nblocks (14 yielded the best results), and setting the network backend buffer to 250ms.
If there’s no way to achieve that with my current setup, would an i7-7700k help? That’s the fastest CPU my motherboard can stomach, otherwise I’d have to essentially buy a new computer.
If I would do that, the next issue though is that you’d need to start an update scan which would redo the work. Only if you would start from empty library (clean scan) case, you could then continue with “new only” scan from the previously saved point. So the terminate-and-restart would be rather complex thing, as it is not clear where it was left off, and whether in the range of already scanned there’s some new previously unknown content.
So at the moment the first update scan is quite a bit of effort. But then going forward not much because you can do “new only” scans.
One reason why doing development on Windows is pain. I commonly leave some 20-50 development windows open when I go to sleep for example. And then I’m really upset when I wake up and the machine is sitting in BitLocker password prompt because it decided to reboot due to updates without asking me for permission. In general, Windows needs too much reboots when there are updates. On Linux you can update everything else except kernel without rebooting. And having to reboot due to a critical kernel update is really rare. So something like 200 days uptime is normal.
Ah, I see you have multiple HQp licenses? My config is running a single HQpe instance on a server, and assigning it to an endpoint using config profile, to limit cost. Jplay doesn’t show those as different Audio Outputs, as I have only one HQp address.
All this being said, audio quality using Jplay is top notch, nothing bad to say about it. Much better than my experience with mConnect on iphone, that was a disaster IME. I’d like to see Jplay “sync” its playback queue with HQp rather than being seen as a single stream from HQp point of view. For example, start playback from Jplay, browse to HQp client and see all the upcoming tracks and be able to pickup control from there. Currently, if you for example stop playback on HQp, Jplay will eventually send its next track, its stream doesn’t dissociate from server, it is oblivious to the HQp control state. As I understand it, HQplayer API already offers this feedback for devs to implement.
You have to use HQPClient or HQPDconfig to change the endpoint device as JPLay doesn’t know about these additional profiles.
It’s not fully integrated with HQPlayer, but just sending it’s output to HQPlayer. Seemed to work pretty well when I tried it
With Desktop you get only one, with HQPlayer logo (native HQPlayer). With Embedded you get two, one with Rygel logo (UPnP) and another with HQPlayer logo (native HQPlayer).
It also depends whether you play from local library, or from a streaming service. Streaming services pose additional limitations since the track streams are valid only for short period of time. In this respect it is similar to HQPlayer Client.
I have not tried it in a while, but I imagine if and when they add Profiles it can be a bit of a game changer for many users.
It’s profiles that I feel that the user was asking for though. As Jussi has made that part of the API, they should hopefully be able to make use of it in the future.
I would really like to see HQPlayer output come to other apps like LMS, BubbleUPNP and Symfonium, but would not hold my breath for that to happen
Yes correct, I think for a number of us that is a game changer and makes us use HQPlayer more as it is easier to switch between systems without having to go back to the server and change the settings
Update: I had ordered Supra cables while I was traveling. Testing with them now, with the original Up Gateway and Intona setup. The crackling “vinyl” noise is barely perceptible at DSD512. My conclusion is that the USB board on this May is marginal. Better cables or different sources make a difference, but this should not be happening. I’m going to try to get a replacement USB board, which might not be easy given current import woes.
Yeah, likely some hardware issue with the May’s USB interface. Could be also caused by a ground current, but I assume the NAA is pretty standalone and connected through unshielded (U/UTP) cable.
!