[pulseaudio-discuss] Resampler rewinding

[Tanu Kaskinen]

On Tue, 2019-06-11 at 22:08 +0200, Georg Chini wrote:
> Hi Tanu,
> 
> the first diagram should look like this:
> 
> DIAGRAM FOR HARDWARE SINK 1 BEFORE STARTING THE MOVE
> 
> +---------------------------------------------------------------------------------+-----
> >           client stream memblockq                                               |
> +---------------------------------------------------------------------------------+-----
>                                                                                    ^ read index
> 
> +------------------------------------------------------------+--------------------+-----
> >  client history_queue                                      |    queue length    |
> +------------------------------------------------------------+--------------------+-----
>                                                               ^ read index         ^write index
>                                                                                    
>   
>                                                     +------------------------------+
>                                                     | data in the client resampler |
>                                                     +------------------------------+
> 
> +--------------------------------------------------+
> >  client render_memblockq  |     queue length     |
> +--------------------------------------------------+
>                              ^ read index           ^ write index
> 
> ----------------------------+
>     |      dma buffer        |
> ----------------------------+
>     ^ hardware playback position,
>       can't rewind beyond this point
> 
> This is why I do not need to take the render memblockq length into account when
> rewinding the history queue. (When rewinding during a volume change, the history
> queue is also rewound by the same amount as the render memblockq plus the data in
> the resampler. Then the resampler bit is fed back into the resampler.)
> 
> The third diagram is correct again, before finishing the move, the read pointers are
> out of sync and will be re-synchronized when pa_sink_input_drop() is called the next
> time during FINISH_MOVE.

I don't see why history_queue length should be in sync with the
render_memblockq length. I find your scheme harder to understand,
because the usual rule of the write position of a downstream buffer
matching the read position of the next buffer upstream doesn't hold. In
your scheme the read index of history_queue doesn't point to the
location from which the resampler reads data. Could you change this bit
in your code?

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk