On 6/28/07, Matthias Kretz <Matthias.Kretz@...> wrote:
> setting XINE_PARAM_AUDIO_AMP_LEVEL on a running stream can have very big
> latencies. Same for rewiring to a differnt audio_port and changing the
> parameters of an audio post plugin.
> AFAICS the problem only turns up with net_buf_ctrl. It seems that net_buf_ctrl
> buffers the packets in the audio_port or so (i.e. buffers them at after all
> processing steps).
net_buf_ctrl doesn't add a buffering layer, the only thing it does is
playing with the clock.
When the clock is stopped, output fifos are fullfilled by decoders,
then decoder loop are locked, and the demuxer continue to fill the
fifos between demuxer and decoders.
During normal playback, there is probably less buffers in the audio
output fifo, and the latency is smaller.
Anyway xine post plugins are not designed to be "real time", the
latency problem is a well known issue, the concept of "real time"
plugins has been discussed for years.
> Instead I think it should buffer either the input stream in front of the
> demuxer or if it really needs to be buffering audio/video buffers then only
> right after the decoder and before all processing steps.
Most of the buffering is done between the demuxers and the decoders.
> Even though I was able to use net_buf_ctrl I still have not understood how it
> works, so if nobody wants to look into this I need at least some guidance how
> to fix this...
IMHO something that could be interesting to try would be to limit the
amount of audio data in the output fifo to an amount of time (let's
say 0.5s for example). I mean the audio fifo push function could lock
if the audio data contained by the fifo represent more than 0.5s.
This way you could parameter the maximum processing latency.
Either do that or implement real time post plugins.