[LAU] Testing JACK and PA latency

[Len Ovens]

On Fri, 20 Sep 2013, Patrick Shirkey wrote:

> On Fri, September 20, 2013 12:00 am, Len Ovens wrote:
>> I am no expert either, but, if pa has access to an audio device that jack
>> can get best latency of -p128 and jack is working with a device that can
>> work with -p64... add pa-jack to the mix and jack will only work at -p128
>> even with a device it could normally work at -p64 with.
>>
>> Add to that the same -p128 device has problems with the wifi giving xruns
>> forces those xruns across the pa-jack IF. If I turn that device off in pa
>> tha problems go away. Also the amount of CPU time used by PA rises a lot
>> when connected to jack.
>>
>> Just my personal observations.
>>
>
> PA CPU time is quite heavily dependant on the amount of latency. Smaller
> period sizes require PA to query the graph more frequently which pushes up
> CPU load.

Yes, I found that too. Really, it has only been since the end of 2012 that 
pa-jack bridging has been usable without too much fiddling. So there are a 
lot of things no-one knows. Bridging pa to jack changes the way pa works 
significantly. PA makes some default assumptions. 44.1k (I changed mine to 
48k, both default and backup). Pa will do on the fly sample rate change if 
needed to mix two streams or to match an input stream to a sink. This will 
affect cpu use as well as latency even if latency is locked to jack. PA is 
built to hide differences between source and sink from the user, both 
levels an rate. Latency comes after that... To get the best out of pa or 
pa-jack, the user needs to follow some rules... the ones I know of are:

  - turn off (in the pa config) all audio devices not being used. The one 
jack uses can be left on because as soon as jack grabs it pa can't really 
see it anyway.

  - set the sample rate the same in jack, pa, and any app pa talks to.

  - in the case of playing back files... try (  :P  ) to use files with the 
same rate too. (pretty hard to do... and not worth recoding to achieve, 
put up with the extra cpu load)

  - Try to find tools that deal directly with jack (better than audacity 
does please!)

  - Set jackd-sink/source to only two channels (or minimum needed) and no 
auto-connect (probably) Cpu use goes up with number of channels of course.

  - Other things I have yet to find.

I can think of only two normal uses for pa-jack (I am sure there are more, 
but I tend to tunnel vision in these things :)
  1) for running desktop apps through jack for simplicity of setup. This is 
something a firewire user might do for sure, but it is handy in other 
cases as well.

  2) remote audio transport as in broadcast use. This requires more 
thought because latency becomes more important. It is often better to use 
more than one machine for this. A standard use may have a number of 
code/decode steps at the same time. Think two audio files being decoded, 
two more for a skype line (one decode and one encode), some audio 
processing to sweeten the output and then encode the stream for output. I 
found 20ms (as per qjackctl) was hard to get without trouble (xruns, or 
runaway stutter from pa). Older P4 machine at 2.4Ghz, ice1712 audio, using 
idjc on the jack side no sweetening. The one person I have worked with on 
this runs his phone app on a second computer (teamspeak I think) and runs 
an audio line into his mixer from that. So no PA :)

I would really like to try netjack with opus encoding as a method 
providing remote content. I may have to "roll my own" to try it any time 
soon though. But I don't know how well netjack deals with systems behind 
routers.

--
Len Ovens
www.ovenwerks.net