[LAD] JACK + PA Latency

[Patrick Shirkey]

On Mon, September 30, 2013 11:30 pm, Fons Adriaensen wrote:
> On Mon, Sep 30, 2013 at 10:15:24PM +1000, Patrick Shirkey wrote:
>
>> I'm asking for additional suggestions on how to authoritatively test
>> this
>> combination and provide definitive results. I realise that it is a
>> fairly
>> difficult question but it is part of a big push for wider adoption of
>> open
>> source pro audio solutions so I hope that you will all feel it is worth
>> the effort to solve this problem too.
>
> In a system such as the one you are testing latency is determined by
> the amount of buffering, and nothing else. C-states shouldn't enter
> in the picture as long as the CPU wakeup time is a small fraction of
> a period (1.333ms in this case). If the wakeup time is too high, the
> whole setup just fails. In other words, if you measure e.g. 100ms
> of latency, that can only mean that somewhere along the pipeline
> 100ms of audio is being stored. It can't be the result of a CPU
> being 100ms late - that would interrupt the signal instead.
>

The graph is about as simple as I can get it without writing a custom app.

jack_delay -> pa source
pa_source ->  PA Stream Buffer
PA Stream Buffer -> alsa
alsa -> ecasound in
ecasound in -> ecasound out
ecasound out -> alsa
alsa  -> PA Stream Buffer
PA Stream Buffer -> pa_sink
pa_sink -> jack_delay

The most obvious potential violator is the bridge code between PA and ALSA
because it's the one place that no one really seems to understand well at
the moment.

Does anyone here have experience with that code/functionality?




--
Patrick Shirkey
Boost Hardware Ltd