On Thu, September 19, 2013 11:48 pm, Len Ovens wrote: > 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. > I'm wondering if this might work: 1: initiate signal pulse (500hz) in jack_delay (out) -> pa source (in) -> custom app (in) 2: trigger *new* response signal at different frequency (400 hz) from custom app (out) -> pa sink (out) -> jack_system (out) -> jack_system (in) -> jack_delay (in) The frequency of the signal could be modified at various points in the graph to provide more timing information? Could the custom app communicate with jack_delay or maybe they could pass a time stamp in the signal or write it to a log? It starting to sound a lot like mtc now. Surely we are not the first to have encountered this issue? -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
