[wdmaudiodev] Re: RTAudio packet streaming is inefficient by design?

  • From: "Vincent Burel \(VB-Audio\)" <vincent.burel@xxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 20 Jun 2018 10:07:04 +0200

Yes, "inefficient by design", since WIN8, this is actually the general
Microsoft Slogan!
They could make flag or T-Shirt, I will buy one ! :-) 

The question that could reply to yours is: 
why the code related to "WithNotification" is present in minwavertstream.cpp
?

Regards
Vincent Burel


-----Message d'origine-----
De : wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Eugene Muzychenko
Envoyé : samedi 9 juin 2018 08:07
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] RTAudio packet streaming is inefficient by design?

RTAudio packet streaming defines packet size as the circular buffer size
divided by the notification count.
KSRTAUDIO_BUFFER_PROPERTY_WITH_NOTIFICATION docs said that notification
count can be only 1 or 2, not more.

KSPROPERTY_RTAUDIO_GETREADPACKET request could return TRUE in MoreData to
indicate that there are more captured data ready to retrieve. But in such
buffer model, it is impossible with a single circular buffer.
If there are no more than two packets in the buffer, a driver may report
only a single complete packet to the client without buffer overflow.

If there is a single complete packet, there is no reason to set MoreData to
TRUE because there is no another complete packet ready to retrieve. There
are two complete packets, there is a reason to set MoreData to TRUE but it
also means the client had not retrieved even the first one, so we definitely
have part of the buffer overwritten.

Additional intermediate buffer is required to implement this feature.
Obviously, double buffering is both less efficient and more complex.

So displacement calculations mentioned in recent thread related to SYSVAD
code, is quite reasonable.

Why number of buffer notifications (and therefore packets in the
buffer) is limited to 2? With more notification points, a driver could use a
single buffer to store captured data and communicate with a client, and a
client could optimize data retrieval.

Is there a plan to increase maximal number of notification points and,
therefore, number of packets in circular buffer?

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

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/

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

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: