[pulseaudio-discuss] pa_stream_seek ... not

[Mads Kiilerich]

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
> operation...
>    

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 
the API.

/Mads