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

[Alejandro Gonzalez]

Hi Amanda, 

I'm just a beginner in PA but if you still need this information, here
it is:

On Sun, 2011-06-05 at 07:52 -0500, Lin, Mengdong wrote:
> I have two questions:

> 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);
>              ...  
> 
This functions are used as function pointers on the pstream.c, here is
where they are initialized on the stream:
./src/pulsecore/protocol-native.c @ pa_native_protocol_connect 

    pa_pstream_set_recieve_memblock_callback(c->pstream,
pstream_memblock_callback, c);


You can find the calls to this function at:
./src/pulsecore/pstream.c
static int do_read(pa_pstream *p) 
 
they appear as:
                    p->recieve_memblock_callback(
there are 2 cases where this function is called, on my case I hit the
first condition:
(p->read.index > PA_PSTREAM_DESCRIPTOR_SIZE) {
        /* Frame payload available */

but you can find the other case a few lines below. 

Regards, 

Alejandro.

> Thanks
> Amanda
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss