[wdmaudiodev] Re: KSPROPERTY_AUDIO_POSITION and position register value relationship

  • From: Eugene Muzychenko <reg.wad@xxxxxxxxxxxxxx>
  • To: Matthew van Eerde <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 13 Dec 2017 14:17:34 +0700

Hello Matthew,

Making an RTAudio client is challenging because there are several flavors of 
RTAudio:

Yes, I understand. In my experiments, basic RT streaming (introduced in
Vista) is reliable enough.

  1.  Packet streaming - 
KSPROPERTY_RTAUDIO_GETREADPACKET/KSPROPERTY_RTAUDIO_SETWRITEPACKET

AFAIK, packet streaming is just an extension to event-driven RTAudio
streaming, right? A client can use these property requests to inform a
driver about client-side progression but the driver should not expect
them.

     *   Event-driven vs. timer-driven -
KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION or KSPROPERTY_RTAUDIO_BUFFER

If a driver supports KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION, must
it also support KSPROPERTY_RTAUDIO_BUFFER too? Or it can
KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION only?

In particular a given piece of hardware might implement, say, two
of these: one of them well, and one poorly, and Windows just happens
to pick the one that worked well.

Is there a description how Windows compares their implementation
quality?

(You can sometimes flush out the precise problem for the one that
worked poorly by running HLK tests on the hardware.)

BTW, is there a way to run new WaveTest, KsPosTest, LatencyTest and
other tests implemented in DLLs, from a standalone test system
(without a dedicated controller machine)? There still are GAudit,
KsTopTest and other EXE-embedded tests that can be run standalone but
WaveTest, KsTopTest, LatencyTest DLLs need an EXE host to be run.

There are always, conceptually, two positions Windows cares about:

Thank you very much for the detailed explanation, I understand this. Now my 
clients use
only buffer position to read/write data because the main goal is
stream stability, not precision timing/synchronization.

KSPROPERTY_RTAUDIO_POSITIONREGISTER is the buffer position.

If position register is supported, must KSPROPERTY_AUDIO_POSITION[EX]
always return it in WriteOffset, or there may be noticeable difference
between these values?

Regards,
Eugene

******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/

Other related posts: