[Tizen General] Tizen Audio Stack

Patrick Shirkey pshirkey at boosthardware.com
Tue Sep 17 19:13:01 GMT 2013

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

Could we split is something like the following:

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

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

> 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

More information about the General mailing list