Hi,
A quick update for those who are following this thread.
We are tracing the audio latency when running a combination of JACK and PA.
We are currently looking at the PA Stream Buffer as a potential bottleneck.
During testing I have seen latency as low as 4ms round trip but also as
high as 1300ms and the results are not stable on my hda_intel sound
device.
If you want to replicate my test suite you can use the following
instructions:
+++++++++++++++++++
Testing JACK + PA Latency
+++++++++++++++++++
graph: jack_delay -> pa_source -> ecasound -> pa_sink -> system_out ->
cable -> system_in ->jack_delay
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
On Fri, September 20, 2013 12:31 pm, Patrick Shirkey wrote:
>
> On Fri, September 20, 2013 11:38 am, Counihan, Tom wrote:
>> Hi Jaska,
>>
>> Apologies in advance for top-posting.
>> Ok, I think I need to re-wind this a little.
>> I don't think I suggested removing Pulse in my correspondence - I don't
>> have any authority in this regard.
>> Patrick started this thread, and I read the spirit of his JACK
>> statements
>> as to offer choice to the user - which I like.
>> His proposal to offer this choice was a mixed-architecture.
>> I asked about the bluez HFP/A2DP - JACK integration with one purpose in
>> mind. To understand if JACK itself could stand on its own without pulse
>> -
>> as a choice, not as a request to remove Pulse. Leave the consumer decide
>> that.
>> I am aware of commercial solutions today that have chosen JACK over
>> Pulse.
>> But I didn't want to turn this conversation into a JACK vs. Pulse debate
>> -
>> quite honestly I'm not intellectually equipped to have that
>> conversation.
>> But I did try and share some latency requirement I'm aware of that may
>> have resulted in these decisions.
>> The reason I asked this Bluez/JACK question is, IMHO from a production
>> perspective, I would suspect a device manufactor would desire one or the
>> other, but not a hybrid.
>> The reason for this being purely one of fiscal implications.
>> 1. It would result in more cost to maintain extra code base for
>> bug-fixes
>> etc.
>> 2. QA cost increased as a result of more permutations/combinations.
>> 3. Extra moving parts in the architecture will increase risk in terms of
>> stability.
>>
>> So in summary, I was answering Patrick's request for feedback on a JACK
>> inclusion question with a perspective of a device manufactor and an open
>> question to this thread whether a standalone alternative was feasible. I
>> have no desire for a Jack/Pulse hybrid (sorry Patrick), but I am
>> intrigued
>> by a standalone Jack alternative choice. The Bluez integration seems an
>> open. I suspect also the Murphy policy manager is also an open. There
>> may
>> be more lurking ....
>>
>
> FYI, I have started latency tests here with my desktop system to try to
> get some hard data. Preliminary results are mixed. I am running a closed
> loop at 64 frames/period on an onboard hda_intel device using jack_iodelay
> out -> pa -> ecasound -> pa -> jack system out -> jack system in ->
> jack_iodelay in.
>
> I have seen round trip latency as low as 5ms but the measurements are
> fluctuating wildly upto 1300ms. I am tracing the cause of the erratic
> behaviour and have asked for some additional test results from the LAU
> community to rule out localised issues.
>
> 5ms round trip (2.5 ms each way) is promising if we can stabilise the
> system but CPU load is upto 70% on my test machine so that will also need
> some work. In comparison the same system with PA disabled shows
> significantly less CPU load but I haven't run a full comparison test yet
> to get latency results.
>
> Another thing that is interesting is I have been running the test for
> several hours while browsing and doing other normal user activity and
> everything has been quite happy so far. That suggests a certain level of
> stability has already been achieved even with a consumer grade audio
> device and proprietary nvidia drivers :-)
>
>
>
> --
> Patrick Shirkey
> Boost Hardware Ltd
> _______________________________________________
> General mailing list
> [email protected]
> https://lists.tizen.org/listinfo/general
>
--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
General mailing list
[email protected]
https://lists.tizen.org/listinfo/general
