HQ Player

[Luca72c]

Hello, i'm a newbie here, thanks to everyone!

I would like to know if it would be possible - and how - in hqplayer to crossover a stereo signal to 8 channels and then to send 4 of these channels to a NetworkaudioD (or ASIO) device and the remaining 4 channels to another NetworkaudioD (or ASIO) device, so to work around the limitations on sending 8 channels of DSD to a multichannel dac.

Sending 4 channels of DSD256 to a single receiving device (BBB, multichannel XMOS, etc...) + 4 channels to another separate receiving device, then sending all 8 channels to the dac, should work, if possible... or not?

Is there any other working way to send DSD256 8 channel flow to a multichannel dac?

[Luca72c]

6 hours ago, Miska said:

Yes, should work fine for example with exaSound and Merging. With Merging it should be possible to do also more than just 8 channels.

 

Uhmmm. Is there a DIY way? I don't want to buy a commercial dac...

[Luca72c]

1 hour ago, Miska said:

 

Certainly there's always a DIY way, it is only about how much effort you are ready to throw in...

 

One is to implement your own USB interface. Or alternatively use suitable SoC where you can get out serial data streams you can reshuffle as necessary using FPGA or CPLD and then use/write suitable ALSA driver to expose that to networkaudiod. Personally I would avoid USB to the maximum extent possible and go latter way and skip USB altogether and go straight from Ethernet to DSD pins (or via 4x I2S).

 

Long ago I did similar for high speed ADC's, using PCI to local-bus interface and custom Linux drivers. Worked actually very nicely.

 

I agree on avoiding usb, in facts i am going for a bbb i2s input in my 9038 dac. But as now, it's locked to 192khz pcm for 8 channels. 

I'm not able to do any proper alsa driver or kernel design and i think that's not such an easy thing to do, considering not even  people like Miero or Acko managed to issue an 8 channel dsd capable bbb software... 

Something like that would very welcome and not only by me! 

[Luca72c]

2 hours ago, Miska said:

 

You can't externally do anything about it. It is just some yet another Windows braindeadness...

 

On my Win 10 Pro's it works fine. And I'm not sure why some systems are having issue with this...

 

 

Strange... It's more than 1 week we have this thread filled by so many problems on Mac platform, with OSes not allowing roon connections, Hqp4 not even starting, incompatibilities, hardware not working properly, communication failures, etc... Many of them solved after many attempts, logs, others never solved at all. But nobody ever said there's something bad about Mac OS itself.

Problems with Linux too, i see - still no trace of blame to Linux.

Now, for a couple of Windows user who notified some problems and after a single failed attempt, we are talking about Windows braindeadness? Is this a sort of prejudice? 😉

Anyway, i'm using W10 and no problem at all, everything working like a charm from first installation, including roon support. Never had a single problem with all audio softwares i tried, like LMS, BHE, Hysolid, Roon, HQP, most using external control and separate player (squeezelite/Roon bridge/NAA). Very good old Windows! 👍

Thank you Miska for your work, Hqp is really an exceptional player, best of all

[Luca72c]

On 7/31/2019 at 1:09 PM, LowOrbit said:

Hi

 

As per my  post from a couple days ago - I have experimented extensively with Ryzen 3700X on X570 mobo. It seems it doesn't improve on your 2700X as far as running EC modulators. I can almost get 44.1 x 256 SDM running, but never totally smoothly. Always quite brief glitches. I can run any filter with ASDM7EC at DSD128, and that seems the sweet spot for reproduction. Sounds terrific.

 

Looks like the AMD chips just don't boost to high enough core speeds for a stable period of time to deliver the DSD256 experience we crave with the current HQP code. 

 

Going back to Intel may be the only way right now. Good to hear that the 9700K can hit the target, even if it needs some GPU assistance for the heavier filter loads.

 

Did you try disabling SMT on 3700X?

Were your test conducted using Miska's multicore optimised EC modulators version or first, non-optimised version?

More, nobody tried 3900X with hqplayer yet?

[Luca72c]

3 hours ago, LowOrbit said:

Yes, most of my testing was with SMT off. Tried Creator Mode, Game Mode and set up manual OC. Nothing got me to DSD256 with ASDM7EC without stuttering. All other Modulators - fine. All Filter variants fine (at least at redbook source rates).

I am using Desktop 4.1.0.1.

 

Very strange, as another user reported being able to play DSD256 with EC modulators on a 4 Ghz overclocked Ryzen 5 2400GE (and RTX2080 CUDA offload, that should not affect EC modulators)...

Something in your system was not running at full potential, i think. Maybe a too early AGESA version is to blame, as you suggest

[Luca72c]

I don't know what kind of optimization has been introduced in 4.1.1  but it stutters with any EC modulators and DSD128 xtr-i2s on my i5-4570S pc. 4.1.0 was ok instead, even using ASDM7EC in DSD128 xtr-i2s no stuttering even if cpu usage is very high (>60%)... 

So i agree with Yvlena: it seems a regression, at least for pc performance

[Luca72c]

4 hours ago, Miska said:

What OS are you using if you see regressions? Stock Win 10 with High Performance or Ultimate Performace power profile? Please make sure you don't have any "OS optimization" products in use that could screw up HQPlayer operation, such as CPU core allocations...

 

With my i7-7700K, poly-sinc-ext2 + ASDM7EC work to DSD256. Single stage poly-sinc-xtr also almost works and with CUDA to RTX2080 it of course works.

 

Desktop 4.1.1 just syncs up with Embedded 4.11.2.

 

Simply stock win10, no optimizations, no "optimizers", no power profiles selected (so i guess default), no gpu. 

But all conditions absolutely identical for 4.1.0 and 4.1.1

[Luca72c]

1 hour ago, Yviena said:

Yeah CUDA is active I can verify it by checking actual GPU usage, and it does go up when using xtr so it seems to be working, Nvidia driver is the 436,xx branch so newest one.

But reverting to 4.1.0.1 everything is fine, With 4.1.1 it stutters without touching anything regarding core allocation, I do see the CPU usage in 4.1.1 maxes out at 18% while older build was using 19-22%.

Maybe when you did your optimizations depending on which CPU you used, could have led to regressions on AMD if for example you used Intel, probably hard to check without acquiring a 3700x/3900x

 

Looks like regressions are on Intel cpus, too... 

[Luca72c]

6 hours ago, Miska said:

 

Strange... And I assume thus you don't have "CUDA offload" enabled in settings either? Just Multicore DSP set to "Auto" (grayed)? Maybe Windows is misreporting CPU topology or something, but your CPU is quite straightforward quad core without hyperthreading. Can you check HQPlayer log file and tell what "CPU core mask" is reported?

 

You should be getting higher load on cores 0 and 2 and somewhat lower load on cores 1 and 3.

 

 

No cuda offload; win10 1903; multicore dsp grayed or selected (same result); cpu core mask 00000000000000000000000000001111; load higher on cores 0 and 2, lower on 1 and 3. Total cpu load is not higher than using 4.1.0.1, but with 4.1.0.1 the load is equally distributed between the 4 cores. 

Maybe here is the problem: using 4.1.1, 2 cores are lightlier loaded and 2 cores are too much heavily loaded... So this could cause stuttering

[Luca72c]

17 minutes ago, maya said:

Debian 9,  Jussi  original 4.9.158 jl+ kernel ,  i5 7500 HQPe 4.11.2 stuttering  with DSD 128 7EC ext2 and CPU allocation two are 90% the rest two 30-40% 

 

But in HQPe 4.11.1-31 no stuttering at all, sounds  great ! 4 cores average at 50-70% 

Kernel which I compiled with bfq sheduler plus other optimizations happened being  also OK

So maybe it is CPU related ?

 

 

 

 

 

 

 

So if desktop 4.1.1 behaves ecactly as embedded 4.11.2, obviously it stutters... 

No windows strange behaviour, then: same results in linux and macos. I think maybe people is too inclined to blame windows everytime something goes wrong... 

[Luca72c]

14 minutes ago, fred_com said:

Yes, this build works better, thanks! There is no stutter when multicore set to "on" without the CUDA. And it looks like the load is more evenly distributed between real cores.

 

As for the core parking - I've installed Ultimate Performance profile, and Park Control also, but it still stutters once I disconnect RDP session. Seems like some weird Windows doing, indeed. And it's not the case for Ubuntu.

 

The ASDM7EC is still out of reach, though

 

... But it"s the case for Debian, as previous post clearly shows. So the problem should not be in windows - or only in windows

[Luca72c]

20 hours ago, Miska said:

There's now new build with some small extra tunings and support for SMT/HyperThreading (homeless extra threads are placed there now). You can also now disable core allocations by setting environment variable HQPLAYER_COREPINNING to value "0" before starting HQPlayer.

 

 

 

Miska, i don't know what you did but this 4.1.1.1 version is very good on my i5-4570s pc (2.90 ghz!) 

Reproducing a 24-96 song in dsd128 with xtr-2s and adsm7EC i have the following:

- multicore dsp disabled: only 41% total cpu load, cores 1 and 2 heavily loaded, cores 0 and 3 nearly unloaded at all, a short stutter every 30 seconds

- multicore dsp grayed: only 39% total cpu load (it was 60% in 4.0.1 and 63% in 4.1.1!), load evenly distributed among cores, no stutter at all

- multicore dsp enabled: 60% total cpu load, cores 0 and 2 heavily loaded, cores 1 and 3 lightly loaded, but no stutter at all just the same! 

With 4.1.1 all 3 modes were heavily stuttering... 

You're going the right way! 

[Luca72c]

10 hours ago, DancingSea said:

Just wanted to point out that I stumbled over to Jussi’s website and noticed he’s having a Black Friday and Cyber Monday sale of 15% off new HQP 4 licenses, and 25% off upgrade licenses.  It runs midnight to midnight UTC time each day.

 

Where did you see that? I can't find any discount on www.signalyst.com...

[Luca72c]

4 minutes ago, rickca said:

You need to enter coupon code cyber19 according to signalyst.com website.

 

Thank you, i didn't notice the news... 

[Luca72c]

Hello Miska, i remember some months ago you were planning to purchase a 3950X pc to better study software optimization techniques for multi-core AMD Ryzen cpus. How is it going? Are you reaching any achievement?

[Luca72c]

Aren't shortly outcoming Comet Lake-S cpus more promising, with higher core count and improved ipc/single core frequency? Why so much interest about 9900KS?

[Luca72c]

1 hour ago, Miska said:

 

Yeah, VST doesn't fulfill those requirements...

 

For example usually VST plugins have graphical user interface, which is not possible on headless embedded device. Which could be even using ARM CPU architecture instead of x86-64.

 

 

What about VST plugins support for desktop version only?

Embedded always had its special features that desktop had not, no problem then, so why worry about this one now? It would be a pity to lose a requested feature in desktop just because embedded can't have it too.

VST Plugins don't make much sense in an embedded device, so just leave it without them (so far) and make them available for desktop users...

[Luca72c]

37 minutes ago, Miska said:

VST is PCM-only, and practically Windows- only. So VST for only for HQPlayer 4 Desktop on Windows and only for PCM doesn't sound sensible at all.

 

38 minutes ago, Miska said:

Also many VST plugins are limited in sampling rates they support and many other restrictions. It would just impose horrible number of restrictions without much benefits.

 

Wouldn't it be possible to apply plugins to the (pcm) files before oversampling and/or conversion to DSD are performed? If possible, this would override all format and sampling frequency restrictions, or at least make them much less problematic.

Just guessing, as i know nearly nothing about how Hqplayer works internally...

 

About compatibility, i see dozens of VST plugins for Mac and many for Linux too, so why you say they're practically Windows-only?

 

44 minutes ago, Miska said:

Of course same DSP things make sense on an embedded device as makes sense on desktop.

 

I see embedded devices as headless, light, small and not always powerful devices performing a specific function - maybe i'm wrong about that. But in my point of view, being able to perform an Hqplayer DSD conversion is an hard task for an embedded device yet (expecially for ARM devices), adding VST plugins seems like asking a bit too much; being it an headless device, in addition: the limitation would be inherent to that configuration, not your fault... But maybe i'm wrong, as i said.

Anyway, who should absolutely want VST plugins option could simply use desktop version... Embedded users can't have them now either, even using desktop version: so it would be an additional chance even for them, not anything less.

 

But as Zauurx said, you're the Master, so of course it's ok if you don't feel like doing that 👍

[Luca72c]

22 hours ago, Samuel T Cogley said:

The 48k flavors are typically not supported by Windows drivers.  My understanding ( @Miska  knows better than I) is that the Windows driver(s) only support the 44.1k flavors for esoteric reasons.  I have not tried the D90 on an Apple or Linux host.  I might do that at some point.

 

I think the problem is with Topping gears or maybe drivers, as i've had various XMOS based usb diy dacs using Thesycon drivers and i've been always able to play 48k-based files on my Windows system, without any resampling and using various software players (including hqplayer, of course)...

[Luca72c]

6 hours ago, bogi said:

 

We are not speaking about playing 48k based PCM files without any resampling or with PCM upsampling. We are speaking about 48k based DSD rates such as 6.144MHz, 12.288MHz, 24.476MHz. You can get such DSD rates by means of PCM->DSD upsampling.

 

Yes, i was talking about those too. I always played them on xmos and amanero transports using windows drivers, just had problems sometimes when passing from 44.1k based frequencies to 48k based ones and vice versa, a bit like you say - that led me to think it's a usb transport related issue more than driver related...

[Luca72c]

1 hour ago, AnotherSpin said:

 

I have HQP Desktop, but I can not figure out how I can run Qobuz through it... Would you give more detailed info? Thank you 🙂

 

Detailed and comprehensive infos would be welcome here too. I tried using output from Qobuz player into hqplayer input (via loopback virtual audio cable audio device), based on the experiences shared in this thread. It works but it's a pain, cumbersome, unstable and more there's the input frequency i often have to change when a new file is playing. Really not useable.

So i think surely i'm missing something... Can we have precise and clear directions on how to do that using virtual audio cable (or other softwares, but no additional hardware) on a single Windows machine? Is the frequency changing thing fixable in any way?

[Luca72c]

7 hours ago, Miska said:

 

Windows audio API doesn't support slaving sampling rate. ASIO does though, but many drivers don't. USB Audio Class has similar limitation, so you need a side channel for this information.

 

I have implemented such feature for RME ADI-2 (Pro) driver on Linux, and this is feature of the ADI-2 firmware.

 

Pretty flexible way is to have an input side NAA with the USB Audio Class 2 support, where NAA appears as a USB DAC.

 

 

I'm not a PC programmer so i'm just guessing, but Qobuz (and others) windows player surely passes frequency info to the audio driver and frequency specification probably get passed to the physical audio device too, so how it is done? There is a sort of "frequency sensing"? Isn't it possible to implement something like this in Hqplayer?

More, Roon seems to pass frequency infos to Hqplayer too, so there is a way (or many) that can be implemented.

Taking another way, maybe Hqplayer could incorporate a sort of virtual driver that makes it appear as an audio device to the system, like virtual audio cable does. For example, AcourateConvolver seems to do something like that, so it should be possible...

Sorry to insist, but i believe that being able to play audio from various software PC sources like Qobuz, Youtube, Kodi, etc... via Hqplayer in a stable and easily useable way (=without having to use an input hardware/NAA, separate PC for the player, and so on) would be a great and appreciated plus for many users!

[Luca72c]

2 hours ago, Miska said:

 

Yes, but that driver would need to be developed and maintained for three different platforms, and would need to bypass OS interfaces for the way back to application which makes it especially tricky.

 

That is because it is ASIO driver and not WDM one?

 

 

 

Would that be feasible/acceptable for you to implement?

 

2 hours ago, Miska said:

 

And I think @Geoffrey Armstrong has made a way to use Kodi with HQPlayer to at least some extent.

 

 

Thank you. Could you please point me to a specific thread/page?

[Luca72c]

11 minutes ago, Miska said:

 

ASIO driver theoretically yes, but it is useful only to limited extent. For example Tidal's application doesn't support ASIO, Spotify doesn't support ASIO, etc.

 

And ASIO is Windows-only, so it would end up being useful in a very limited way.

 

 

So if i understand well, programs like AcourateConvolver could not be used for Tidal or Spotify streams? That was unexpected to me...

Anyway, different drivers for different OSes seems a normal thing for an application/device to me, i guess many of these kind of differentiations are already implemented in Hqplayer versions. As i said, i'm not able to identify different levels of complexity in programming things, that's why i ask