[pulseaudio-discuss] source-sink loopback

[Lennart Poettering]

On Thu, 20.08.09 00:52, pl bossart (bossart.nospam at gmail.com) wrote:

> > So, basically: if you configure a latency then you should get
> > something in the area what you asked for but we cannot make
> > guarantees. And the connection between latency and block sizes is even
> > fuzzier.
> 
> D'oh. Looks like if I interface with a timing-critical protocol I'd
> need to hide this inside a module...

When you need equally sized blocks of PCM data then you need to queue
things up (e.g. with a pa_memblockq). A number of modules do
that. Including Jason Newton's equalizer module.

> >> 3. For now the source and sink are synchronous but if they are not,
> >> how can I enable a sample-rate converter to correct for clock drifts?
> >> I see some code for SRC in both the input and output IO threads,
> >> however I don't understand how the tracking would be done.
> >
> > module-combine handles this already. It probably would make sense to
> > copy the basic logic here: in the main thread simply measure the
> > latency of the sink and source every now and then, and then update the
> > sampling rate of the sink input with pa_sink_input_set_rate().
> >
> > (This is actually quite hard to get right, and module-combine doesn't
> > entirely get it right. The problem is getting a somewhat atomic
> > snapshot of both latencies, since in the time between asking the two
> > latencies another memblock might have been sent over.)
> 
> Humm, I didn't realize your definition of latency is different from my
> intuitive definition. I thought in terms of samples, but when I
> checked the code in alsa-sink.c, I saw that the latency is really the
> delta between the wall clock and the audio clock+the delayed samples.
> What this means is that if there's a drift between the wall clock and
> the audio clock the latency reported will gradually increase or be
> reduced Is this correct?

Yes, we don't measure the latency in samples since due to resampling,
network latencies and other times summed up it really is nothing where
the unit "sample" (in the client's sample rate) is appropriate. In
the entire pipeline from the per-application buffer to the speakers
only the per-application buffer itself has actually a latency which
could be measured sensibly in samples (in the client's sample
rate). Everything else is either measured in usec anyway or in a
different sample rate. That's why I chose to unify time units over the
entire pipeline and measure them in usec. If you need them in samples
use pa_usec_to_bytes().

> I guess when you substract both latencies you get rid of the wall
> clock component, which is fine in this case.
> And yes we would need to low-pass filter the deviation to focus only
> on the long-term evolution. The clocks shouldn't be more that 1% apart
> anyway on most systems.

module-combine does not low-pass filter time under the assumption that
the underlying source/sink already does that for their timing and we
don't need to low-pass things on every level again. Most backend
modules (such as the ALSA or Bluetooth one) low-pass filter time by
using pa_timer_smoother -- which however does linear regression plus
spline interpolation instead of doing a classic low-pass or a PLL/FLL.

> > In the rewind callback you you simply must rewind the read pointer in
> > the memblockq. It is called whenever we need to rewrite the hardware
> > playback buffer. i.e. let's say we have 2s of buffer. Now a new stream
> > is added to the mix. We need to remix the whole 2s we already
> > wrote. Then we rewind each stream and ask for the data again and write
> > it to the buffer.
> >
> > If you use a memblockq all you need to do is basically forward this
> > call to pa_memblockq_rewind() which does the heavy lifting for you.
> 
> This part is unclear. What you are saying is that basically
> pa_memblockq_rewind() is the opposite of the drop(), this is just a
> play with the read pointer. However when does the data actually get
> marked as used by the sink and when can these memory blocks be
> reclaimed/reused?

Every sink has a value max_rewind associated with it
(sink->thread_info.max_rewind) which should be used by streams to size
the "history" they keep in their buffers. If you use a memblockq then
you should set its max_rewind parameter to this value (though
converted to the stream's sample params, which
pa_sink_input_get_max_rewind() does for you)

The max_rewind value can change, i.e. when the underlying device is
reconfigured or your stream is moved between sinks. You should
register an update_max_rewind() callback in you pa_sink_input to get
notifications each time that happens and then readjust the maxrewind
param of your memblockq.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4