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
