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
