Re: Testing JACK and PA latency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user




[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux