HQPlayer kick start guide & feature requests

[Geoffrey Armstrong]

Something else to consider for the next version…

 

DACs that work via WASAPI which are capable of PCM 384KHZ and DSD128 show up in Windows playback devices as capable of 192KHZ max (and of course DSD playback which is via DOP for these doesn't show up there).

 

HQPlayer seems to be stopping at the Windows limit of 192khz (DSD64) for these DACs in the Desktop version.

 

For the same DACs played back via an NAA using the NAA version, this restriction is lifted and HQPlayer treats them as 384khz and DSD128 capable.

 

Examples are the Oppo 105D and Grimm LS1 Speakers (built in DAC).

 

Could this restriction be lifted in Windows too?

 

Thanks,

 

geoff

[Miska]

DACs that work via WASAPI which are capable of PCM 384KHZ and DSD128 show up in Windows playback devices as capable of 192KHZ max (and of course DSD playback which is via DOP for these doesn't show up there).

 

HQPlayer seems to be stopping at the Windows limit of 192khz (DSD64) for these DACs in the Desktop version.

 

This is a bug of the WASAPI driver. If the Windows Control Panel / Sound shows DAC capable of 384k, then it works fine with HQPlayer too. Prime example of such is TEAC UD-501.

 

The Thesycon driver shipped with various DACs based on XMOS USB chip has two known bugs that should be fixed:

1) WASAPI is capable of only up to 192k

2) ASIO DSD mode doesn't support any 48k-base rates (3.1/6.1/12.3 MHz)

 

For the same DACs played back via an NAA using the NAA version, this restriction is lifted and HQPlayer treats them as 384khz and DSD128 capable.

 

Linux (and Mac OS X) driver is a completely separate implementation compared to the Thesycon's Windows driver.

 

Could this restriction be lifted in Windows too?

 

There needs to be enough pressure on Thesycon to fix their WASAPI and ASIO drivers.

 

(some manufacturers claim that ASIO DSD would somehow limit the rate to 44.1k-base ones, but that's not true, ASIO supports any imaginable sampling rate you can express as 64-bit floating point)

[Geoffrey Armstrong]

This is a bug of the WASAPI driver. If the Windows Control Panel / Sound shows DAC capable of 384k, then it works fine with HQPlayer too. Prime example of such is TEAC UD-501.

 

The Thesycon driver shipped with various DACs based on XMOS USB chip has two known bugs that should be fixed:

1) WASAPI is capable of only up to 192k

2) ASIO DSD mode doesn't support any 48k-base rates (3.1/6.1/12.3 MHz)

 

 

 

Linux (and Mac OS X) driver is a completely separate implementation compared to the Thesycon's Windows driver.

 

 

 

There needs to be enough pressure on Thesycon to fix their WASAPI and ASIO drivers.

 

(some manufacturers claim that ASIO DSD would somehow limit the rate to 44.1k-base ones, but that's not true, ASIO supports any imaginable sampling rate you can express as 64-bit floating point)

 

Thanks. I'm aware that Linux and Mac OSX drivers are completely different to the Windows drivers and that's why the restriction doesn't apply on those OS's. Somehow though other Windows software is getting around this limit and I was wondering if you could do the same.

[Miska]

Thanks. I'm aware that Linux and Mac OSX drivers are completely different to the Windows drivers and that's why the restriction doesn't apply on those OS's. Somehow though other Windows software is getting around this limit and I was wondering if you could do the same.

 

I don't know what other software does, but do those other software use WASAPI Exclusive mode and what do they tell about device capabilities? HQPlayer just believes what the driver says, if it doesn't say it supports 352.8/384k then such is not available.

 

This is how Sound Properties for UD-501 looks like:

 

I would say from what I've seen, that HQPlayer works quite drastically different way from other software...

[Geoffrey Armstrong]

I don't know what other software does, but do those other software use WASAPI Exclusive mode and what do they tell about device capabilities? HQPlayer just believes what the driver says, if it doesn't say it supports 352.8/384k then such is not available.

 

This is how Sound Properties for UD-501 looks like:

[ATTACH=CONFIG]13707[/ATTACH]

 

I would say from what I've seen, that HQPlayer works quite drastically different way from other software...

 

Yes, they are using WASAPI exclusive mode and event style. I can send native DSD128 to the Grimm LS1's this way via J River. I can also use J River to convert PCM to DSD128.

 

Additionally I can use foo_asio either within Foobar itself or using foo_asio as the output device from J River (which I prefer). This will also allow the above with slightly better sound than J River's Audio and DSP engines.

 

This DAC reports a Max of PCM 192KHZ in Windows Playback devices.

 

Of course none of the above options sound as good as HQPlayer when the DAC is connected via an NAA

[Miska]

Yes, they are using WASAPI exclusive mode and event style. I can send native DSD128 to the Grimm LS1's this way via J River.

 

OK, I don't know what it is doing different. What device capabilities JRiver exactly shows for the devices in question?

 

Additionally I can use foo_asio either within Foobar itself or using foo_asio as the output device from J River (which I prefer). This will also allow the above with slightly better sound than J River's Audio and DSP engines.

 

Of course ASIO is completely separate from WASAPI and doesn't have same limitations. Do you have the same problem with ASIO on JRiver vs HQPlayer?

 

This DAC reports a Max of PCM 192KHZ in Windows Playback devices.

 

This is clearly a driver bug...

[Geoffrey Armstrong]

OK, I don't know what it is doing different. What device capabilities JRiver exactly shows for the devices in question?

 

 

 

Of course ASIO is completely separate from WASAPI and doesn't have same limitations. Do you have the same problem with ASIO on JRiver vs HQPlayer?

 

 

 

This is clearly a driver bug...

 

I don't know if there's anywhere I can check the device capabilities within J River. Also bear in mind that foo_asio uses asio proxy. I think this is a just a way to get non-asio native devices to appear as though they're asio capable in order to use them with foo_asio.

 

Within foo_asio it's necessary to choose DOP for DSD playback with these devices, not ASIO NATIVE, as with the exasound.

 

foo_asio is another way of playing native DSD or converting between DSD and PCM.

[Miska]

I don't know if there's anywhere I can check the device capabilities within J River.

 

How do you know what you can output (IOW ask JRiver to output)?

 

Also bear in mind that foo_asio uses asio proxy. I think this is a just a way to get non-asio native devices to appear as though they're asio capable in order to use them with foo_asio.

 

Is it something like ASIO4ALL? What does it really use for output? IIRC, ASIO4ALL can use KS or WASAPI.

 

Foobar's plugin hassle has always been beyond my patience to collect, configure and understand...

[Geoffrey Armstrong]

J River won't let you output something the end device can't support. In other words no auto- downsampling. It promts you first if that would be necessary.

 

It also tells you exactly what it is outputting and whether it's bit perfect to the file or altered in some way.

 

I think asio proxy behaves a bit like asio4all and outputs WASAPI. I'm only guessing though.

 

The foobar stuff is a hassle for the user to configure as well. Very flexible in terms of what can be done with it though.

[Miska]

J River won't let you output something the end device can't support.

 

So it has some way to show you what you can output when you are selecting what to output?

[bogi]

I think this is a just a way to get non-asio native devices to appear as though they're asio capable in order to use them with foo_asio.

...

I think asio proxy behaves a bit like asio4all and outputs WASAPI. I'm only guessing though.

 

That's he case and the goal of ASIO4ALL to provide ASIO interface for devices without ASIO interface, but foo_dsd_asio has other function.

 

You cannot choose WASAPI or Kernel Streaming in foo_dsd_asio Control Panel. I don't see my integrated soundcard in the Control Panel. I see only ASIO capable devices.

 

foo_dsd_asio is proxy in other meaning than ASIO4ALL. It adds PCM <--> DSD conversion capablilty and also pure DSD upsampling capability between the player and the ASIO device.

 

So my conclusion is that foo_dsd_asio communicates only with devices which support ASIO interface. That are physical devices via driver from manufacturer (like XMOS devices), but also virtual ASIO devices like ASIO4ALL or for example JRiver ASIO interface. We are typically setting physical ASIO devices in foo_dsd_asio, but I mean you could for example set ASIO4ALL in foo_dsd_asio and thus you could provide PCM to DSD capabllity to a device, which is missing ASIO driver interface.

[Geoffrey Armstrong]

So it has some way to show you what you can output when you are selecting what to output?

 

Unfortunately no it doesn't appear to have any indication. If you try to play a file the end device can't handle, it doesn't play and you get a warning "Something went wrong with playback …" It offers to automatically apply a sample rate the device would support by changing the parameters in its DSP studio are. This is where up-sampling of PCM or conversion to DSD can be set.

 

I don't think this is the best approach because it can be quite annoying to receive this message when testing a number of different DACs as it's too easy to forget the limitation of a particular DAC and try to exceed its capabilities.

 

Your approach is better, where in the main interface you limit the sample rate based on the end device and the filter chosen.

[wappinghigh]

I have a dream.

 

I dream of a "pre-configured" embedded Cubox running NAA straight out of the box. That functions like the new Auralic Aires product... but of course *way* cheaper/smaller/better....

 

Controlled by an ipad...

 

Served by an HQ player app that you can download onto and then run on a NAS.....

 

I have a dream...

[Miska]

Served by an HQ player app that you can download onto and then run on a NAS.....

 

All sounded nice (pretty much already done) until this point. NAS boxes usually really don't have enough CPU power to run any real DSP stuff...

[wappinghigh]

^.Huh??? What do you mean?? I've got a QNAP with 5 RAM and runs Linux on an i5 processor.. That not enough CPU power for you??

 

(It's powerful enough to process and play 1080p movie files with 7.1 Dolby digital from a RAID array no problems out via HDMI... No stuttering...)

 

...You can upgrade i5 and i7 QNAPS with more RAM no problems.. see .http://forum.qnap.com/viewtopic.php?f=11&t=88594

[4est]

Is that not a modified NAS then? I am not sure what the advantage would be in doing this. Seems a trade off- no GUI, but directly connected drives...

^.Huh??? I've got a QNAP with 5 RAM and runs Linux on an i5 processor.. That not enough for you??

 

(It's powerful enough to process and play 1080p movie files with 7.1 Dolby digital no problems out via HDMI... No stuttering...)

[wappinghigh]

You just slot in some RAM onto the motherboard like any old PC..

 

There is nothing complicated.. These NAS's are like powerful mini server computers these days....

[wappinghigh]

Is that not a modified NAS then? I am not sure what the advantage would be in doing this. Seems a trade off- no GUI, but directly connected drives...

 

You don't need a GUI.. That's what the iPad app is for..

[4est]

That is what I said... I still see no real advantage in this route, other than that you already own it. If one were to want this route, why not simply build a Linux PC?

[wappinghigh]

^ Well it cuts down the no. of "computers" needed to run in the chain to get music to the NAA.. if Miska won't write UPnP into HQplayer ..because he says he hates UPnP.. (to share a library share on a NAS), then maybe he can get HQplayer running direct on the NAS instead..

[wappinghigh]

That is what I said... I still see no real advantage in this route, other than that you already own it. If one were to want this route, why not simply build a Linux PC?

 

...data loss (running one data disc)...

 

...Large library capacity..

 

...Ability to store all your music with all your other media (like movies).. in the one place..

[4est]

??? Simply put the drives on the main box then... It would seem to me that you are requesting a 'round robin approach to something that has already been worked out.

^ Well it cuts down the no. of "computers" needed to run in the chain to get music to NAA.. if Miska won't write UPnP into HQplayer ..because he says he hates UPnP.. (to share a library share on a NAS), then maybe he can get HQplayer running direct on the NAS instead..

[wappinghigh]

Sure. It's possible to "build" anything.. Like a full blown commercial enterprise Linux Server.. with a 5 RAId array for like 10K.. but these NAS devices are like under a thousand grand..

[wappinghigh]

Anyway.. what's the problem? If it will run on a Linux PC.. it can run on these NAS devices with a bit of a tweek and some instructions how to load it..

[4est]

Data loss and high capacity???

Once again, who said that you cannot run a NAS or RAID on a regular box. Seriously, why pay the high dollar for a pre configured NAS to only replace the distro with a different one. One could readily get better performance with a well chosen hardware set. My Box has an i5 and 4tb of network storage and room to grow. This could easily be any computer on the network. Attempting to support people attempting to run this on various NASs seems like a service nightmare for Miska.

...data loss (running one data disc)...

 

...Large library capacity..