[gst-devel] pulsesink optimizations

[Lennart Poettering]

On Thu, 15.10.09 12:58, Wim Taymans (wim.taymans at gmail.com) wrote:

> With newer pulse we can't really use buffer_alloc to write directly into
> the pulse shared memory from the decoder because there is no api to
> allocate such a chunk, there is pa_stream_begin_write() but that can
> only be called once AFAIK.

Hmm, so you'd like to see some API in PA that allows you to allocate,
ref, unref multiple memory blocks at the same time and independantly
of each other?

Internally that's what happens anyway, so we could definitely add
that. The main reason why I didn't expose this directly is that this
doesn't mix well with allowing the user to pass subsets of the
allocated buffers to pa_stream_write(), unless we add a completely new
function pa_stream_write_preallocated() that takes the buffer pointer,
and index into it and a length. Which would be kinda clumsy, wouldn't
it?

Also I am a bit afraid of how the semantics of PA's and Gst's buffer
handling might collide there. In PA memory blocks can actually change
location in memory at any time. To lock them into an accessible place
for a time you have to call an _acquire() function first and
afterwards a _release() function, and in between your code should not
do communication with other threads or other 'slow' stuff. This would
not mix well with Gst's own buffer handling, would it?

The current PA API makes clear in a way that the buffer should be
allocated using pa_stream_write_begin() only very shortly before the
actual _write(). (or at least it was my intention to make that
clear). But if I export the whole memory block allocation API then
this would be really hard to express in the API so that people whose
memory allocation scheme is incompatible with this would not simply
call _acquire() right away and then delay the _release() until the
very last moment.

The scheme that is now part of the PA API is also designed to be
somewhat similar to how ALSA's mmap() API for playback work: when you
want to write your data you ask for a pointer, and then push your data
into it, and then commit this. I kinda assumed that Gst would gain
support for alsa mmap eventually and it would make sense to follow the
same scheme. What's the plan with that?

Hmm, if all this zero-copy stuff is being rethougt for gst, maybe
keeping alsa mmap io in mind might be a good idea. After all of the
various alsa features the mmap io stuff is actually one that didn't
trigger many problems when PA started to make heavy use of it. So I
can only encourage its use ;-)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4