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 .... Regards Tom. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Uimonen, Jaska > Sent: Wednesday, September 18, 2013 1:04 AM > To: Patrick Shirkey; Tizen List > Subject: Re: [Tizen General] Tizen Audio Stack > > Hello, > > I'm kind of answering to Tom here. > > I agree that having both jack and pulse will increase latency, but.. > > I still fail to see how you are making this bluetooth latency thing go away > with > jack. There's still the bluetooth socket or possibly alsa over I2S to > bluetooth chip > etc. We don't have too much control what is happening in the bluetooth (will > it > be jack or pulse) and the delays are varying heavily depending what particular > device you are connecting to bluetooth. > > If we have 30ms of processing time, to me it sounds plenty(?). Anyway if we > want to make this more reliable we have to give more realtime priorities to > pulse and make the internal buffering to drivers small enough . If after this > things are not working there's something wrong in the buffering scheme of > pulse. I mean, we are just taking buffers from alsa, possibly processing and > sending to bt socket and vice versa. > > You could maybe get pulse hick-ups by sending 100000 volume events or > similar, but also you could get both jack and pulse behaving bad by writing > bad > kernel driver (if we don't have hard real-time, which we probably won't > have). I > don't see how running processing inside pulseaudio dsp thread would produce > more latency than running the same processing inside jack (?). > > I'm just saying that I think this particular bt use case doesn't justify > moving to > only jack solution. And moving to only jack solution would bring you more use > cases to solve with jack that are now solved in pulse. > > br, > Jaska > > > P.S. I can also try to do some measurements myself about the latencies inside > pulseaudio with the bt handsfree. The bt handsfree should work quite ok in > current tizen ivi. I hope I would have more time... > > P.S.S. Is there any hard facts about the amount of latencies introduced by > jack > and pulse combination? I'm running it in my own laptop and quickly I'm not > noticing too much difference to running pulse only. it is pretty fast and > responsive. I haven't yet tried the bt handsfree though... > > > > > ________________________________________ > From: [email protected] [[email protected]] on > behalf of Patrick Shirkey [[email protected]] > Sent: Tuesday, September 17, 2013 10:13 PM > To: Tizen List > Subject: Re: [Tizen General] Tizen Audio Stack > > On Wed, September 18, 2013 4:06 am, Counihan, Tom wrote: > > > >> > >> On Thu, September 12, 2013 10:03 pm, Uimonen, Jaska wrote: > >> > Hello, > >> > > >> > Sorry for coming so late into this discussion... > >> > and maybe starting to dig into the can of worms. > >> > > >> >>I didn't want to push that option as I fear it could open a can of > >> >>worms especially as there are a couple of Intel guys in the PA team > >> >>who are paid to work on PA and Tizen integration and I don't want > >> >>them to think they are under attack. > >> > > >> > Don't know If I'm one of the guys referred by this, but there's no > >> > guys who are paid for working especially with PA. We are working on > >> > solution that will do the use cases the industry wants. Valid use > >> > case is not "I want Jack", but "I want Jack, because PA can't do > >> > this and that". We are very willing to discuss whatever solution > >> > makes sense, so don't mind the politics :) > >> > > >> >>To really cut to the chase: > >> >> > >> >>- JACK is aimed at enabling realtime multimedia production in a > >> >>modular environment > >> >>- PA is aimed at audio management in a consumer environment where > >> >>realtime is not the core concern > >> > > >> > So which are you thinking a car or phone is more: consumer > >> > environment or multimedia production system? > >> > > >> > >> Typically they are both consumer environments and PA is the obvious > >> choice for managing the audio system. > >> > >> > I have seen mobile phones doing call audio streaming in user space > >> > with PA. > >> > I'm just saying phone audio is not that real time critical as audio > >> > recording in professional studio. And I don't see many hard real > >> > time media production related activities happening in car or mobile > phone. > >> > I could be wrong and every audio related stuff happening around > >> > tizen is valuable :) > >> > > >> > >> I can see a use case for professional audio in both environments but > >> I don't think it will be the default for most users. > > > > In automotive IVI systems we have strict latency constrains to meet > > VDA specification for hands-free phone communication in the car. This > > leads into signal latency optimized designs, ensuring phone uplink and > > phone downlink signals will be routed and processed within 50 msec > > within the device (= mobile phone AND sound system in the car). This > > is stripped down to 20...30 ms left for audio processing (incl. async. > > sampling rate > > conversion) and routing after the BT transmission (between the mobile > > phone and the sound system in the car) and way down to the loudspeaker > > resp. the microphone. If you miss these conditions, hands-free phone > > calls out of the car will be a mess. > > Just to confirm, we need to assign upto 30ms for the data transfer process > between device and sound system including i/o and then worst case 20ms for > audio processing round trip latency from input back to output inside the CPU? > > Could we split is something like the following: > > output: > 2.5 ms : audio converted to BT signal > 15 ms : audio transferred to car stereo via BT > 2.5 ms : audio converted to analog output via speaker > > input > 2.5 ms : mic input received converted to digital signal > 15 ms : input transferred to device via BT > 2.5 ms : input routed via PA/JACK > 2.5 ms : input processed by call management application > 2.5 ms : input transferred from call management application to GSM antenna > > I'm probably missing a couple of steps or my numbers are out. Can you > elaborate? > > > > So while a dual combination of Jack and Pulse may be technically > > achievable, we need to be cognisant that every additional component > > causing signal latency between connected handset and the automotive > > speaker system may make it challenging to achieve such non-functional > > requirements. > > > > I agree this is a core concern. > > Do you have some results that you can share on the performance and stability > of PA/Tizen in this specific case? > > JACK can be run at very low latency. The best I have heard of is periods of 16 > but that was achieved a few years back on custom hardware. Recently we have > seen widely reproducible periods of 64 on modern ARM devices with correctly > written drivers and realtime kernels which translates into sub 2.5ms latency. > That is mostly with Raspberry PI but also recently on Picuntu too. I expect > any > new Intel cores will also have the same or better performance. > > PA can be tuned for low latency too at the expense of power consumption and > possible stability issues but do we have a spare 5ms out of 20ms for adding > JACK into the mix? > > If we remove PA from the equation for handling i/o directly a tuned JACK setup > could potentially provide additional buffer to play with for scenarios that > require it. > > However the policy code and other useful features of PA are well written and > understood so maybe it would be viable for JACK to communicate directly with > the PA API for some functionality? > > > > > -- > Patrick Shirkey > Boost Hardware Ltd > _______________________________________________ > General mailing list > [email protected] > https://lists.tizen.org/listinfo/general > --------------------------------------------------------------------- > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for the sole > use of the intended recipient(s). Any review or distribution by others is > strictly > prohibited. If you are not the intended recipient, please contact the sender > and > delete all copies. > > _______________________________________________ > General mailing list > [email protected] > https://lists.tizen.org/listinfo/general -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ General mailing list [email protected] https://lists.tizen.org/listinfo/general
