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
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?
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
URL to WDMAUDIODEV page: