On Thu, 19 Sep 2013, Patrick Shirkey wrote:
On Thu, September 19, 2013 7:19 pm, Hartmut Noack wrote:
Am 19.09.2013 10:46, schrieb Patrick Shirkey:
Moving this thread to LAU as it seems to be a more generic issue now:
I am testing the round trip latency when using PA and JACK together. I
have the following connection graph:
jack_system (in) -> pa_source (in) -> audacity (in) -> audacity (out) ->
pa sink (out) -> jack_system (out)
Unless your research is completely academic I do not see a practical use
for its results on the user-side.
This is entirely professionally motivated and will also have major
benefits to academia too. I'm seeking suggestion on how to go about it not
arguments for why or if this is a useful thing to do... ;-)
For Audacity latency is not a big
issue.
You can replace audacity with *any* application that can provide (near) 0
internal latency and full duplex pass through.
I expect the sample rate is to remain the same from one end to the other?
With pulse (or at least some of the apps that work with pulse) that is not
a given.
My first thought would be an analog solution, scope the sound going in and
coming out. Send short pulses of sound through. Anything that is purely
with in the computer would require two measurements, both starting and
ending in jack. So the length of time from jack-alsa-cable-alsa-jack would
be added to jack-pulse-app-pulse-jack. I don't know If you would be
measuring jack twice when you shouldn't but that part of the journey is
probably the best known.
just a thought, jack-alsa-cable-alsa-jack-pulse-app-pulse-jack might give
valid results.
There are some things that could be removed to figure out just parts of
the path. Jack-pulse-pulse-jack for example. I don't know if pulse deals
differently time wise with it's internal routing than with a app though.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
