30 Sep
2013
30 Sep
'13
4:04 p.m.
On Mon, September 30, 2013 11:30 pm, Fons Adriaensen wrote:
On Mon, Sep 30, 2013 at 10:15:24PM +1000, Patrick
Shirkey wrote:
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
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.