In-vehicle/Roadmap/AudioManagement

Revision as of 10:56, 22 March 2011

Policies for routing and prioritizing various audio sources inside a vehicle to provide entertainment on the one hand and to avoid driver distraction and bring important information to the driver's attention on the other are an integral piece of in-vehicle infotainment systems.

At a course grain level, we will have up to 7.2 speakers. In conjunction with this, we have to cater for dedicated audio jacks on for instance front and rear arm rests. We add to this complexity with the need to integrate BT head sets. In terms of input, we can have a number of Mics for the obvious need, but also to support advanced echo cancelation - take the scenario of a cabrio from rest to 180mk/hr and the wind break noise, we need to get to a scenario where one could take a hands free call with minimum interference.

If we can picture the deployment scenario of the multitude of channels from above, then we extend this with the concept of zones. Zones are roughly equivalent to passengers. As such we need a policy control framework for controlling dynamic management of these zones. For instance, ramping down radio for incoming HFP call and the inverse when the call terminates.

In general, this area can be broken up into two coarse grained areas; audio processing itself and audio policy management.

In terms of processing, we need to cater for a DSP view of the world and an optimized opcode view of the world. In today's deployment, a multitude of filters will be applied to the channels to improve sound quality and reduce cost, for example where one wants to use cheaper speakers. We have to cater for a variety of audio re-sampling scenarios. Build in echo cancelation etc...

From a policy management perspective, we need a flexible framework to handle needs for ramping, corking, and mixing. So, along with the HFP mentioned above, we need to cater for all those gongs and bells you experience today when you fail to belt-up, lights on with door open etc...

From a MeeGo Architecture perspective, we have today PulseAudio as our server, Alsa underneath, Gstreamer from a framework perspective, and from a policy perspective we have a very interesting addition with the Policy Framework: http://conference2010.meego.com/session/policy-framework-flexible-way-orchestrate-multiple-functionalities-meego-devices So, PulseAudio, Gstreamer and Policy framework experts would be greatly appreciated.

Design Proposal

Highlight the key components here - for example, PA, GST, Policy Framework, ALSA - and show the interations for the architecturally signification use cases Sequence diagrams and component diagrams to go in this section - focus on IVI, highlight the deficiencies and potential required patches etc..

Laci Jalics has created an architecture diagram to capture the hardware and software architecture related to audio routing and control.

Use Cases

Use Cases will be broken out into this section to give a clear overview of what Automotive Audio Management requires.

Add Brief Description of Audio Control - Very simply usescases, just sat in front of my car radio and identified these.

Add description for Automotive Audio processing. One of the key areas to cover here is Audio Policy control - i.e. mixing, ramping down radio when inbound hands free

Open Question

Where is IIR and/or FIR filtering best handled - GStreamer or Pulse? GStreamer has some implementations, is that the most appropriate place?

References

File:Meego-policy-framework-developer-guide.pdf

PA hands-on

Audio zones

The simplest form of audio zone division within the car environment would be:

-Zone 1: front for driver. Navit audio streaming to front speakers. Speakers are attached to standard Line-Out from main automotive connector.

-Zone 2: rear for passenger(s). Movie player (Totem) audio streaming to rear headphones. These are USB headphones attached to one of 4 USB connectors.

Agenda is to use basic Meego 1.1 release on Russellvile platform and explore how far would one get with just a basic configuration changes – no new packets and no code change. So here is manual configuration for "back seat":

1. Firstly check what audio devices are available (with USB headphones attached):

$aplay -l

... Card 0 ... HDA

... Card 2 ...USB headset

2. Secondly set volume levels high for both using alsamixer tool:

$alsamixer -c 0

$alsamixer -c 2

3. Start Totem to play some audio.

4. Bring PA command application:

$ pacmd

-once started you will get prompt like: >>>

-see what sinks are available (see index for sink associated with device)

>>>list-sink

-probably will get index 1 and index 2 for HDA (card 0) and USB headset (card 2) respectively

-now check for inputs attached to sinks with:

>>>list-sink-inputs

-for example will get that sink 1 (HDA) has attached input with index 6 (can be any number) that would be Totem player.

-now you want to move that input to another sink. In example above sink 1 is HDA and sink 2 is USB headphones. Move input of sink 1 (that would be Totem with index 6) to sink 2:

>>>move-sink-input 6 2

-if you want to move it back to original sink 1 (HDA)

>>>move-sink-input 6 1