[pulseaudio-discuss] pa_stream_seek ... not
mads at kiilerich.com
Wed Dec 23 15:41:22 PST 2009
Lennart Poettering wrote, On 12/22/2009 07:00 PM:
> On Mon, 14.12.09 20:16, Mads Kiilerich (mads at kiilerich.com) wrote:
>> The streams.h documentation tells how the write pointer can be moved
>> with pa_stream_write() - and reset with pa_stream_flush().
>> But AFAICS there is no way to move the write pointer without writing
>> anything. pa_stream_write() has assertion on data not being NULL and
>> doesn't move the pointer if nbytes is 0.
>> Is there some kind of trick that can be used?
> One option is to simply cache the seek position locally and then use
> it the next time you write again.
>> Would it make sense to change PA so pa_stream_write() accepts a NULL
>> pointer if nbytes is 0 and then just moves the write pointer?
> Not sure if that really is advisable. We should minimize the traffic,
> and thus I'd say that seeking without writing is a redundant
That is good points. But I think there are good counter arguments and
that my proposal makes sense anyway:
I assume that PA already maintains a pointer to where the next write
should happen. Changing that pointer without doing anything else can't
be an expensive operation. Maintaining state and functionality for
"should I make a relative seek on next write" in applications would be
more complex and introduce extra (but cheap) code in the hot code path.
Seeks are generally an exception which doesn't happen often, and an
extra redundant operation in that case is acceptable. IMHO.
pa_stream_write() does two things: seek and write. It is obvious what to
expect if you make a seek without writing anything - that requires no
explanation. It is obvious that making two calls to a function is more
expensive than one, and that combining two calls to one is an
optimization which should be done if relevant. But it is surprising and
counter-intuitive that pa_stream_write() can't "write" a zero-length
chunk like for example write(2) can.
The current behaviour has a special case which need documentation. The
behaviour I propose will remove a special case and no extra
documentation is necessary, and it will thus reduce the complexity of
More information about the pulseaudio-discuss