HQ Player

[Eugene Muzychenko]

On 5/8/2019 at 8:31 AM, Miska said:

Maybe they didn't want to bother creating DLL/DPLL to generate proper virtual sample clock for the audio and thus don't support event driven WASAPI mode at all.

What exactly do you mean by the "generate proper virtual sample clock"? Kernel Streaming drivers don't need to expose internal clocks directly. They must respond to current stream position requests, VAC does that. VAC also generates notification events if requested, so event-driven mode is fully supported.

 

The only thing that could affect stream timing precision is that VAC reports position change only after the appropriate data portion has been actually transferred. For example, if event period (ms per int) is 3, stream position is updated every 3 milliseconds. Within this period, repeated position requests will return the same value.

[Eugene Muzychenko]

2 hours ago, Miska said:

What I meant by virtual clock is correct timing of the notification events. HQPlayer always uses WASAPI event driven mode

In WaveRT mode, VAC signals notification events when a current half of the RT Audio circular buffer is processed. But Microsoft RT Audio protocol does not allow to specify more than two notification events per circular buffer. So if the System Audio Engine allocates, for example, 20 ms buffer, and Virtual Cable processing period is set to 1 ms, notification events are fired not more often than 10 ms.

 

I will try to check HQPlayer with VAC. Could you please point me what exactly to check? And I can provide full VAC package if you want to check it on your side.

[Eugene Muzychenko]

3 hours ago, lucretius said:

If your sound card supports it, in the Windows Sound panel, under the Recording tab, set the “Stereo mix” or “loopback” device as the default

I would like to add that Stereo Mix may be supported, but disabled by default and not visible. To check its presence, right-click any recording endpoint, and click "Show disabled devices" if not checked:

 

 

 

If the endpoint is present but disabled, enable it:

 

 

[Eugene Muzychenko]

2 hours ago, juanitox said:

i have tried Virtual cable as input device to use the Qobuz app dirrectly with  HQplayer 4  and unfortunatly it sounds not as good as Roon for streaming ..

 

Most virtual audio transports work under Windows Audio Engine that supports format conversion, including resampling. If shared mode is used, you need to pay attention to both playback and recording default formats to avoid conversion.

[Eugene Muzychenko]

On 5/17/2019 at 1:37 PM, Miska said:

I recommend to just try to set VAC as input device in HQPlayer and then try to process from that input to some output (source URI selection).

 

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?

[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.

[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.

[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.).

[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.