HQ Player

[asdf1000]

18 minutes ago, Le Concombre Masqué said:

 I don't need to download and install libgmpris package. And then the hqplayerd package.Right?

 

Correct. It's all done for you with the bootable image.

 

Remember above I told you to look at the section "See the section "Downloading and configuring bootable image"... that means you can ignore the section above it...

 

[Miska]

3 hours ago, Le Concombre Masqué said:

Better look dumb than remain stuck : After I have downloaded the hqplayer-embedded image and wrote the image on a flash drive (and got to the point pictured above) I don't need to download and install libgmpris package. And then the hqplayerd package.Right?

 

It is all self-contained and ready to use. You just boot it up, configure it through /config web page and you are done.

 

If you don't know the IP address, you can login as root and run "ifconfig" to see what address it has got from DHCP. From next release onwards, you can also check IP from the HQPlayer Client (included with HQPlayer 4 Desktop).

 

[DancingSea]

13 hours ago, Em2016 said:

 

No worries. But did you know you can combine Audirvana with HQP,  using Embedded (via UPnP)?

 

Free to try the Embedded version, 30 days

 

I had no idea. I’ll check it out, thanks!

 

Are there specific instructions of how to set it up for HQPlayer & A+?  I’m curious for sure.

 

Swinsian continues to work great as a HQP library manager (thank you Bob Stern!).  If we can get an iOS remote, I promise to stop complaining 😂

[DancingSea]

7 hours ago, Ales Prochazka said:

 

The addition of this functionality is not planned.

Please understand that this is not my main activity.
The goal was to create a simple remote control for HQPlayer with focus on local file playback.

 

Any hopes for an iOS version ?🙏

[Ales Prochazka]

34 minutes ago, DancingSea said:

 

Any hopes for an iOS version ?🙏

 

Unfortunately, it's not very likely.
The entire application would have to be re-written.

 

[lucretius]

8 hours ago, Eugene Muzychenko said:

 

I installed 4.02, but it's not obvious how to force it to record from a live audio endpoint instead of a file.

 

As soon as I select WASAPI in either input or output section (prior to choosing a particular endpoint/device), I immediately get the "Input and output devices cannot be the same!" error message that re-appears immediately as I click "OK".

 

Setting either or virtual hardware endpoints as input and output, specifying "input:default/48000/2" or "audio:default/48000/2", changing Windows default audio endpoints, I cannot get HQ Player to record. As I click "Play", the appropriate icon becomes active, but nothing else changes in the window. Player window seems to be frozen until I click "Stop".

 

Last log messages are the following:

 

& 2019/05/19 14:10:22 Play
# 2019/05/19 14:10:22 clMainWindow::startPlay(): clHQPlayerEngine::Play(): Transport == NULL

 

If Virtual Cable endpoint is selected for input, VAC Control Panel shows a very short (less than a second) streaming, then the stream terminates.

 

Maybe I'm missing something important, but a quick read of the manual didn't help. Could you please tell what I'm doing wrong?

And should the player with live audio input work as a repeater, sending recorded data directly to the output endpoint?

 

From the log, it looks like the transport wasn't "loaded".   Look for my posts earlier (from #14460 onwards) and see if that works.

[Miska]

8 hours ago, Eugene Muzychenko said:

Setting either or virtual hardware endpoints as input and output, specifying "input:default/48000/2" or "audio:default/48000/2", changing Windows default audio endpoints, I cannot get HQ Player to record. As I click "Play", the appropriate icon becomes active, but nothing else changes in the window. Player window seems to be frozen until I click "Stop".

 

When you have input URI and press enter, the URI is loaded to the transport and appears on the playlist view below if successful. When it is loaded (appears on playlist), you can start playback. During the loading operation HQPlayer enumerates the current device capabilities and checks that the device seems OK.

 

8 hours ago, Eugene Muzychenko said:

# 2019/05/19 14:10:22 clMainWindow::startPlay(): clHQPlayerEngine::Play(): Transport == NULL

 

This tells that there was no playlist or other transport loaded. A bit like CD player with empty tray when you press Play.

 

[Eugene Muzychenko]

10 hours ago, Miska said:

When it is loaded (appears on playlist), you can start playback.

 

Now I got the transport ("audio:default/48000/2") in playlist, but shared mode definitely doesn't work. As I click the playlist item, the player shows an empty progress bar for 8..10 seconds, then returns in the previous state.

 

  2019/05/19 23:10:17 WASAPI output device period (default/min, ms): 10/3
  2019/05/19 23:10:17 WASAPI output using device default WASAPI period size
  2019/05/19 23:10:17 WASAPI output trying to use 10 ms for WASAPI period size.
  2019/05/19 23:10:17 WASAPI output initialize audio device using 192000/20 (32), 2 channels
+ 2019/05/19 23:10:17 WASAPI input engine running...
  2019/05/19 23:10:17 WASAPI input open audio endpoint GUID: {0.0.1.00000000}.{f4897752-451e-429b-b551-7588a5865f66}
  2019/05/19 23:10:17 WASAPI input currently using: 'Microphone (High Definition Audio Device)'
  2019/05/19 23:10:17 WASAPI input type: Microphone
  2019/05/19 23:10:17 WASAPI input engine initialized
  2019/05/19 23:10:17 WASAPI input device period (default/min, ms): 10/3
  2019/05/19 23:10:17 WASAPI input using device default WASAPI period size
  2019/05/19 23:10:17 WASAPI input trying to use 10 ms for WASAPI period size.
  2019/05/19 23:10:17 WASAPI input initialize audio device using 48000/20 (32), 2 channels
  2019/05/19 23:10:17 WASAPI output buffer size 1920
  2019/05/19 23:10:17 WASAPI output engine started at 192 kHz / 20 bits / 2 channels, 1920 frames buffer (2/2 channels)
  2019/05/19 23:10:17 WASAPI output engine starting at: 192000
# 2019/05/19 23:10:17 WASAPI input failed, trying another format (if available)
  2019/05/19 23:10:17 WASAPI input initialize audio device using 48000/24 (32), 2 channels
# 2019/05/19 23:10:17 WASAPI input failed, trying another format (if available)
  2019/05/19 23:10:17 WASAPI input initialize audio device using 48000/16 (16), 2 channels
# 2019/05/19 23:10:17 WASAPI input failed, trying another format (if available)
  2019/05/19 23:10:17 WASAPI input initialize audio device using 48000/20 (32), 2 channels
# 2019/05/19 23:10:17 WASAPI input failed, trying another format (if available)
  2019/05/19 23:10:17 WASAPI input initialize audio device using 48000/24 (32), 2 channels
# 2019/05/19 23:10:17 WASAPI input failed, trying another format (if available)
  2019/05/19 23:10:17 WASAPI input initialize audio device using 48000/16 (16), 2 channels
# 2019/05/19 23:10:17 WASAPI input failed, trying another format (if available)
? 2019/05/19 23:10:17 WASAPI input no formats available - trying shared mode
  2019/05/19 23:10:17 WASAPI input mix format: 44100/32/2
  2019/05/19 23:10:17 WASAPI input sampling rate: 44100 (44100)
  2019/05/19 23:10:17 WASAPI input buffer size 512
  2019/05/19 23:10:17 WASAPI input engine started at 48 kHz / 16 bits / 2 channels, 487 frames buffer (2/2 channels)
  2019/05/19 23:10:17 WASAPI input engine starting at: 44100
# 2019/05/19 23:10:17 WASAPI input clWinEngine::Execute: IAudioCaptureClient::GetBuffer(): got 448 frames, expected 512 frames, flags 1: The operation completed successfully.

! 2019/05/19 23:10:17 WASAPI input IAudioClient::Reset()
  2019/05/19 23:10:17 WASAPI input engine uninitialized
- 2019/05/19 23:10:17 WASAPI input engine stopped
  2019/05/19 23:10:27 End of track
& 2019/05/19 23:10:27 Next
  2019/05/19 23:10:27 Audio transport: rate=48000 channels=2 format=auto buffer=0
  2019/05/19 23:10:27 Input set channels: 2 (2)
  2019/05/19 23:10:27 InputSDM packing: 1
# 2019/05/19 23:10:27 clReadAudio::Open(): clWinEngine::InitAudioBase(): CoCreateInstance(IMMDeviceEnumerator)
  2019/05/19 23:10:27 Idle request
  2019/05/19 23:10:27 Stop request (tail)
& 2019/05/19 23:10:27 Stop...
  2019/05/19 23:10:29 WASAPI output engine uninitialized
- 2019/05/19 23:10:29 WASAPI output engine stopped
- 2019/05/19 23:10:29 Playback engine stopped
& 2019/05/19 23:10:29 ...stopped
  2019/05/19 23:10:29 Set volume: -18

 

Default format for the Mic endpoint was set to 44100/16/2. When I changed it to 48000/16/2, the player successfully started to record from the endpoint.

 

BTW, the Microphone pin supports 48000/16/2 (I checked it via Kernel Streaming), so WASAPI exclusive mode must work with this format, but it doesn't.

[Miska]

5 hours ago, Eugene Muzychenko said:

BTW, the Microphone pin supports 48000/16/2 (I checked it via Kernel Streaming), so WASAPI exclusive mode must work with this format, but it doesn't.

 

Usually problem with motherboard devices is that they expose multiple WASAPI endpoints but all share a single clock. Trying to set format different from the set default format on any of such endpoints typically fail... (because they cannot run for example microphone and line out at different sample rates)

 

But overall, I would just ignore such hardware, it is pretty useless for audiophile uses and purposes anyway. I've done most of my testing with devices like RME ADI-2 Pro.

 

[Eugene Muzychenko]

2 hours ago, Miska said:

they expose multiple WASAPI endpoints but all share a single clock. Trying to set format different from the set default format on any of such endpoints typically fail... (because they cannot run for example microphone and line out at different sample rates)

 

What exactly do you mean by the "share a single clock"? WASAPI endpoints are created on top of KS pins. Each KS pin is logically independent, and can have its own clock, or the clock can be shared between different pins (it depends on underlying KS driver).

 

Most modern hardware audio adapters have independent input/output pins. You can, for example, record from the Mic pin at 24000 or 44100, and play to the Speakers pin at 48000 or 96000.

 

The default/shared endpoint formats affect only shared-mode endpoint access. If the endpoint is accessed in exclusive mode, shared formats don't matter.

[Miska]

Just now, Eugene Muzychenko said:

What exactly do you mean by the "share a single clock"? WASAPI endpoints are created on top of KS pins. Each KS pin is logically independent, and can have its own clock, or the clock can be shared between different pins (it depends on underlying KS driver).

 

Hardware sample clock going to the I2S lines. In Exclusive mode there's no rate conversion or clocking from the audio engine, but just data stream from the driver, driven by the hardware DMA engine.

 

1 minute ago, Eugene Muzychenko said:

Most modern hardware audio adapters have independent input/output pins. You can, for example, record from the Mic pin at 24000 or 44100, and play to the Speakers pin at 48000 or 96000.

 

I'd be curious to see such hardware implementations. So far, DMA buffers for audio controllers are typically shared between channels and interrupts are generated every N samples from the hardware ring buffer... And generally there's only one clock generator in the hardware...

 

2 minutes ago, Eugene Muzychenko said:

The default/shared endpoint formats affect only shared-mode endpoint access. If the endpoint is accessed in exclusive mode, shared formats don't matter.

 

Yes and no. With proper hardware things work as expected in Exclusive mode. With most motherboard audio devices however the driver refuses to change hardware parameters through one WASAPI endpoint in exclusive mode, likely because other endpoints stick to the default format. Maybe they don't even test drivers in exclusive mode, who knows...

 

[Eugene Muzychenko]

3 hours ago, Miska said:

Hardware sample clock going to the I2S lines

 

AFAIK most universal audio chips have no pins with their ADC/DAC clocks exposed.

 

3 hours ago, Miska said:

I'd be curious to see such hardware implementations.

 

Hmmm. Most modern universal audio chips have multiple independent codecs, SDOs and SDIs, support multiple hardware streams at different sampling rates (derived from 44100 and 48000 by multiplying/dividing) at the same time. I tested several desktop/notebook models with built-in audio chips (Realtek ALC892, ALC888, ALC899, Conexant Cx20561 etc.) directly via KS interface, and all of them are able to record and play at different sampling rates, at the same time.

 

4 hours ago, Miska said:

DMA buffers for audio controllers are typically shared between channels

 

Multi-stream codecs use combined stream frames in a single DMA stream, so the driver packs/unpacks particular stream frames.

 

4 hours ago, Miska said:

And generally there's only one clock generator in the hardware...

 

Yes, this master clock forms the basic 44100 and 48000 frame rates, and particular sampling rates are derived from these basic rates by multiplying/dividing to integers.

 

4 hours ago, Miska said:

With proper hardware things work as expected in Exclusive mode. With most motherboard audio devices however the driver refuses to change hardware parameters through one WASAPI endpoint in exclusive mode

 

Neither the hardware nor the driver knows what is the "exclusive mode". This is a local WASAPI term. Windows Core Audio uses Kernel Streaming layer to implement all higher-level interfaces (WASAPI, DirectSound, MME etc.). In both shared and exclusive mode, Audio Engine issues the same KS requests to create and maintain a stream. The difference is only in buffer sizes and some minor details.

 

You can check it, using KS-aware audio applications (AudioResampler, WinAMP/Foobar2000 players with KS plugins, KS version of Audio Repeater etc.).

[lucretius]

13 hours ago, Eugene Muzychenko said:

Now I got the transport ("audio:default/48000/2") in playlist, but shared mode definitely doesn't work. As I click the playlist item, the player shows an empty progress bar for 8..10 seconds, then returns in the previous state.

 

Are you still having problems getting it to work (in shared mode)?  What sound card/DAC are you using for output?  What back end (ASIO or WASAPI)?  I think the back end for the output device has to be different than the backend for the input device -- this works for me: ASIO for output, WASAPI for input.

 

Otherwise, not meaning to insult, I can look for obvious things, if you could post pics of the Sound panel: Playback and Recording and the Advanced properties tag of the devices in question,  the HQPlayer Desktop settings, and the Home page of HQPlayer Desktop after the stream is loaded.

[Miska]

9 hours ago, Eugene Muzychenko said:

Hmmm. Most modern universal audio chips have multiple independent codecs, SDOs and SDIs, support multiple hardware streams at different sampling rates (derived from 44100 and 48000 by multiplying/dividing) at the same time. I tested several desktop/notebook models with built-in audio chips (Realtek ALC892, ALC888, ALC899, Conexant Cx20561 etc.) directly via KS interface, and all of them are able to record and play at different sampling rates, at the same time.

 

They usually do that by running sample rate conversion and mixing, which is something we don't want. In audio hardware we use, there are two hardware oscillators, usually 22.5795 MHz and 24.576 MHz for 44.1k and 48k families respectively. And the hardware switches which one of the two clocks is used to run I2S lines and DMA engine.

 

I'm totally not interested on any Realtek, Conexant or similar crap. Just elaborated my experience of format change failing with such interfaces using WASAPI Exclusive (just for normal playback as well). Typically IAudioClient::IsFormatSupported() claims to support format, but then later IAudioClient::Initialize() with such format fails (with the exact same WAVEFORMATEXTENSIBLE struct).

 

 

But this is anyway not relevant for the topic...

[Outlaw]

Is there a way to use Tidal with the latest version 4 of HQPlayer ?

[Miska]

16 minutes ago, Outlaw said:

Is there a way to use Tidal with the latest version 4 of HQPlayer ?

 

At least from Roon it works fine, just like before. So in that sense functionality has not changed.

[Eugene Muzychenko]

22 hours ago, lucretius said:

What sound card/DAC are you using for output? 

 

I use mainstream audio adapters (Realtek, Conexant, C-Media etc.). I'm not an audiophile, just an audio software developer. :)

 

22 hours ago, lucretius said:

What back end (ASIO or WASAPI)?

 

WASAPI.

 

22 hours ago, lucretius said:

I think the back end for the output device has to be different than the backend for the input device

 

The player complains if input/output backends are the same, but WASAPI doesn't have such limitation. If underlying KS pins can be used at the same time, they can be used via WASAPI as well, regardless of access mode (shared or exclusive).

[Eugene Muzychenko]

16 hours ago, Miska said:

They usually do that by running sample rate conversion and mixing

 

Datasheets of relatively modern HD codecs don't mention conversion/resampling or mixing. Could you please tell where you got such information?

 

16 hours ago, Miska said:

I'm totally not interested on any Realtek, Conexant or similar crap.

 

I'm not suggesting you take an interest in them. The only thing I wanted to mention, is that such adapters are used in millions of PCs worldwide, Windows Core Audio supports them fully, and WASAPI successfully works with them all, either in shared or exclusive mode. So if HQPlayer fails to record from such adapter, it means a peculiarity (or even a bug) in player's code. Even if this problem doesn't occur with audio adapters typically used with HQPlayer now, it may occur in the future, unexpectedly.

 

16 hours ago, Miska said:

Typically IAudioClient::IsFormatSupported() claims to support format, but then later IAudioClient::Initialize() with such format fails

 

Now I don't remember how exactly IAudioClient::IsFormatSupported() works in exclusive mode. If it  uses KSPROPERTY_PIN_DATARANGES/KSPROPERTY_PIN_CONSTRAINEDDATARANGES, the driver often returns "statically" supported format range (for example, 44100..192000), while given format may not be actually supported right now, so the subsequent stream creation fails. It it uses KSPROPERTY_PIN_PROPOSEDATAFORMAT, the driver should return the same result as if the pin was accessed for streaming. If you want, I will trace IAudioClient::IsFormatSupported() to determine which driver request it actually sends.

[Account Closed]

5 hours ago, Outlaw said:

Is there a way to use Tidal with the latest version 4 of HQPlayer ?

Yes with Roon as the front end.

[Account Closed]

Jussi,

 

Could you and Eugene please take all this back and forth to another thread or to PM. This stuff is making it hard to follow this thread. I don't wish to be rude but it does seem off topic here or at the very least tangential.

 

Thanks for understanding.

[Le Concombre Masqué]

On 5/19/2019 at 7:43 PM, Miska said:

 

It is all self-contained and ready to use. You just boot it up, configure it through /config web page and you are done.

 

If you don't know the IP address, you can login as root and run "ifconfig" to see what address it has got from DHCP. From next release onwards, you can also check IP from the HQPlayer Client (included with HQPlayer 4 Desktop).

 

if I go to Authentification in the config web page and type hqplayer/password I get a blank page forever, be it for system or user. If I type those wherever else authentification is asked for, it keeps asking username/password again and again. About says Trial just fine.

 

Side note 1 : No Closed Form 16M I have just rediscovered as the 7th wonder of the world?

Side note 2 : Though when I trialed NAA with 2 MBP via wifi I found no benefit, the SQ being the one of the connected MBP (I had a SD card with OSX back then), I am puzzled for I can only respect those who underwent the NAA route to have the least active computer connected to the DAC: both D4 and Embedded are the other way around. Or the Nirvana is to be found with a 3 computing devices set-up : GUI/heavy lifting/NAA?

[AnotherSpin]

1 hour ago, Le Concombre Masqué said:

if I go to Authentification in the config web page and type hqplayer/password I get a blank page forever, be it for system or user. If I type those wherever else authentification is asked for, it keeps asking username/password again and again. About says Trial just fine.

 

Side note 1 : No Closed Form 16M I have just rediscovered as the 7th wonder of the world?

Side note 2 : Though when I trialed NAA with 2 MBP via wifi I found no benefit, the SQ being the one of the connected MBP (I had a SD card with OSX back then), I am puzzled for I can only respect those who underwent the NAA route to have the least active computer connected to the DAC: both D4 and Embedded are the other way around. Or the Nirvana is to be found with a 3 computing devices set-up : GUI/heavy lifting/NAA?

 

What is No Closed Form 16M?

[AnotherSpin]

Miska, 4.0.3 desktop works fine within Mojave. One small bug(?) - when I change volume with keyboard keys volume knob size changes every few steps. Also, if I change SDM pack in input device setting from DoP to none next time I open preferences it is set to DoP again. I do not use any input device. Is it done by purpose?

[Miska]

8 hours ago, Eugene Muzychenko said:

I'm not suggesting you take an interest in them. The only thing I wanted to mention, is that such adapters are used in millions of PCs worldwide, Windows Core Audio supports them fully, and WASAPI successfully works with them all, either in shared or exclusive mode. So if HQPlayer fails to record from such adapter, it means a peculiarity (or even a bug) in player's code. Even if this problem doesn't occur with audio adapters typically used with HQPlayer now, it may occur in the future, unexpectedly.

 

It is not just recording, but also the same for playback. I'm not going to spend a lot of time trying to chasing ghosts for something outside of my scope. I've found that changing default audio format from control panel makes that particular format work through Exclusive mode with such audio interfaces. I don't know what the driver is doing inside.

 

As long as audiophile and pro-audio devices work as expected, I'm fine. Luckily most of the time these provide ASIO drivers.

 

[Miska]

5 minutes ago, AnotherSpin said:

Miska, 4.0.3 desktop works fine within Mojave. One small bug(?) - when I change volume with keyboard keys volume knob size changes every few steps.

 

Maybe that's the text underneath changing size, so you likely get same result also with mouse. I need to play with size policy of vertical size of the text widget... All numbers should be equally tall, but looks like it is not the case...

 

20 minutes ago, AnotherSpin said:

Also, if I change SDM pack in input device setting from DoP to none next time I open preferences it is set to DoP again. I do not use any input device. Is it done by purpose?

 

If you have input backend disabled (set to none), it just falls back to defaults. If you have some device selected, it should stick. Only practical effect of DoP for input is a little bit of extra CPU load when running with inputs because of the DoP detection code.