On Fri, September 20, 2013 12:00 am, Len Ovens wrote: > > > On Thu, 19 Sep 2013, Fons Adriaensen wrote: > >> 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. > 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/Clients/LactencyControl/ 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
