19 Sep
2013
19 Sep
'13
4:21 p.m.
On Fri, September 20, 2013 12:00 am, Len Ovens wrote:
On Thu, 19 Sep 2013, Fons Adriaensen wrote:
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.
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer…
Yes, this is another metric I am testing for so it would be nice to have a
single app for both measurements.
With the graph that Fons has suggested it seems like it should be possible
to do it all in one go even while modifying the period size and other
system configuration settings.
An automated method for all of the above would be very useful for a lot of
professional use cases.
Something along the lines of "JackPulse Latency Test" (JPLT).
--
Patrick Shirkey
Boost Hardware Ltd
Don't know - I'm by no means a PA
expert... and I don't know
your Jack period size. Given PA's reputation I'd expect more:
1024 samples would mean that PA imposes almost the same RT-
requirements on apps as Jack does, and it was designed *not*
to do that... But maybe the jack <-> PA interface doesn't
use the same amount of buffering that PA normally adds.
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.