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
