On Fri, September 20, 2013 9:47 am, Len Ovens wrote:
>
> 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.
It's been working for me on fedora and debian since 2009 at least (apart
from that nasty bug that slipped in mid last year). Maybe you are running
ubuntu?
> 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 :)
Pulse Audio is the official sound management tool/layer for at least 4
high profile mobile operating systems. The PA developers have invested a
lot of time and effort on making it functional and useful in both desktop
and mobile environments. In addition there is a lot of Policy Kit
functionality that is extremely unlikely to find it's way into JACK. There
are certain members of LAD who would likely give up FLOSS altogether than
accept the policy kit functionality of PA in JACK.
In addition PA and JACK teams have different development priorities that
require contradictory trade offs to be made. I don't see this as a major
issue as long as PA and JACK coexist peacefully and things are getting
pretty good in that regard. As you rightly note things are more stable now
that they have ever been.
Myself and some other professional audio devs working for large
multinational companies that have a vested interest in high performance
mobile operating systems are seeking to isolate performance bugs with the
combination so that JACK and PA can be run in unison at low latency on
systems that currently do not have ootb support for JACK. If that turns
out to be an unattainable goal then we will find a way to at least make it
possible so that JACK and PA can be used interchangeably.
I have been running the latency test now for a few hours straight and I
have seen varying numbers reported down to as low as 5ms and as high as
1300ms. I would like to find the cause of the erratic behaviour. After
carefully monitoring jack_delay and top it appears to be PA that is at
fault but I am not yet able to pinpoint the cause.
Changing the sample rate from 44100 to 48000 in /etc/pulse/daemon.conf did
not fix the problem. This device is an onboard hda_intel 2 channel card.
Surprisingly for me it is performing well at 64 frames/period. Given that
I saw similar results at 1024 frames/period my suspicions are with PA.
Still the erratic behaviour might be a priority issue, kernel/driver issue
that is causing the problem and not related at all to PA. At the moment I
am just guessing as to the real cause of the observed behaviour.
It would be useful if other people have the time to run the test procedure
on their systems too to get a better overview of how widespread the
problem is.
Here's what I am doing:
Preliminary step:
vi ~/.pulse/client.conf
add the following line:
autospawn = no
TEST PROCEDURE
1: Connect the headphone/speaker output to the mic input with a physical
cable. You could use the sytem mic directly but then you have to listen to
an annoying signal tone at approx 600hz so the cable is a more pleasant
experience.
2: console: pulseaudio -k
3: start jack with the following settings or as low as you can go 64/48000/2
4: console: pulseaudio -D
5: console: jack_iodelay
6: console: ecasound -f:32,2,48000 -b:64 -i alsa -o alsa
7: disconnect system_capture (in) from pa_source (in)
8: connect system_capture (in) to jack_delay (in)
9: connect jack_delay (out) to pa_source (in)
open up gkrellm so you can monitor the system load
open up a console with top to monitor system load and application load
check the output from top against the console messages from jack_delay
Do you get wildly fluctuating results too or is your system stable at a
specific latency measurement?
This is a real issue not an academic theoretical exercise. Anyone who has
the time to provide feedback will be making a useful contribution to the
progress of Linux Audio Development.
If you do feel inclined to participate please also report your system stats:
PA/kernel/sound device/jack/cpu/mem/video/etc...
If for any reason you do not see any value in this process I will
appreciate if you start a new thread for that discussion.
> 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.
>
In our tests we have found netjack to be incredibly useful for a large
range of high performance/high bandwidth processes. In general I prefer to
use JACK but there are also completely valid business and corporate uses
for PA that cannot be ignored if we want to see wider adoption of JACK.
--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
