Hi there,
I am trying to understand some performance measurements I did this
week. I have a test app that decodes audio and writes a decoded buffer
with pa_simple_write(). Depending on the size of the buffer I pass to
PulseAudio, I see a ~20% variation in the core activity (bigger
buffers are better), and I can't really figure out the reason why I am
having this overhead.
It seemed to me that setting minreq to -1 in the buf_attr fields would
select an 'optimal' size, however having looked at the code I realize
PulseAudio selects a fixed value of 20ms. As I understanding it, as
soon as I have minreq=20ms free in the server buffer+queues, a request
will be made to the client and unblock the app. Before I experiment
further, I was wondering what would happen if I set minreq to a larger
value, say 100ms? It would force the queue to drain and my decoder to
provide bigger buffers, which would seem to make sense power-wise. And
why was 20ms optimal in the first place, how was this value
determined? To avoid memory copies, shouldn't minreq be determined by
the granularity what the application can provide, e.g. 30ms for
G723.1, 1152/sample-freq for MP3, etc?
Or is there another parameter that could explain my results?
While I was at it, I realized there's a new routine since 0.9.16
called pa_stream_begin_write(). The comments are not totally clear:
- "This function may be used to optimize the number of memory copies
when doing playback ("zero-copy")". I thought we were already using
zero-copy? What's saved here compared to a plain pa_stream_write()?
Looks to me this is only useful if the application can use the buffer
internally (sort of mmap-like).
- 'It is not recommended letting an unbounded amount of time pass
after calling pa_stream_begin_write() and before calling
pa_stream_write()'. Not recommended as in not safe, or performance
would degrade, or we would run out of memory?
Thanks for your feedback
Cheers
-Pierre
