On Mon, Jun 18, 2012 at 08:49:55AM -0700, Chris Robinson wrote:
On Monday, June 18, 2012 9:31:04 AM Andrew Eikum wrote:
Yeah, I experimented with ADJUST_LATENCY, as it seems to be the trick to getting lower latencies. Then we have to maintain our own buffer, which is why I switched to using the write callback, to have Pulse tell us when it's ready for more data from our internal buffer.
You shouldn't need a shadow buffer with ADJUST_LATENCY. Just write it to pulse as the app writes it to mmdevapi. Why delay? It can handle the buffer sizes.
Are you sure? You said above:
Right, which is why you can't rely on what PulseAudio sets for the buffer/tlength size...
Is there any guarantee that Pulse /will/ give us a sufficient buffer?
From the API docs[1], it just "tries to assure" that we have the
requested buffer size, which actually means nothing.
And even worse, Pulse's API doesn't let us set both the buffer size and the latency[2]. Since we need to set the latency, we can't request a buffer size at all. So we have to rely on Pulse's default buffer size, and I don't think we can depend on that being sufficient in every single case and configuration. So we need the local buffer.
This also avoids the timing problems with the write callback. The most you'll need is a temporary storage buffer for when an app writes an incomplete period.
Yeah, the new design would only use the local buffer if not all of the data fed to mmdevapi will fit into the Pulse buffer. I remember trying this method and it failing for some reason, but maybe it'll work this time around.
[1] At least, I think that's what the docs say. I still have no idea what these structure members actually do. http://freedesktop.org/software/pulseaudio/doxygen/structpa__buffer__attr.html
[2] http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/LactencyControl