Why does a VOIP sink input's current latency become "0" after moving to a new sink? I saw endless "rewind" in log

[mengdong.lin@xxxxxxxxx (Lin, Mengdong)]

I have two questions:

> size_t pa_memblockq_get_length(pa_memblockq *bq) {
>     pa_assert(bq);
> 
>     if (bq->write_index <= bq->read_index)
>         return 0;
> 
>     return (size_t) (bq->write_index - bq->read_index);
> }
> 
> So to return 0, the write_index and the read_index are likely equal.

1. Why can the read_index exceed the write index? Does it mean if the sink input cannot feed data fast enough (queue underflow), the sink keeps reading forward and the "read_index" exceed the "write_index"? This means invalid data will be read by the sink.

2. Who can trigger the "Requesting rewind due to rewrite"? The sink or the application?
I traced code and found it was triggered by a "SINK_INPUT_MESSAGE_SEEK" message, and so the sink input keep seeking forward. But I'm lost in function " pstream_memblock_callback" that posts the message? Who can call "pstream_memblock_callback" and when?

 static void pstream_memblock_callback(pa_pstream *p, uint32_t channel, int64_t offset, pa_seek_mode_t seek, const pa_memchunk *chunk, void *userdata) {
       
        if (chunk->memblock) {
            if (seek != PA_SEEK_RELATIVE || offset != 0)
                pa_asyncmsgq_post(ps->sink_input->sink->asyncmsgq, PA_MSGOBJECT(ps->sink_input), SINK_INPUT_MESSAGE_SEEK, PA_UINT_TO_PTR(seek), offset, chunk, NULL);
             ...  

Thanks
Amanda