[MeeGo-ivi] audio architecture example

[Marco Ballesio]

Hello,

On Wed, Feb 16, 2011 at 6:11 AM, Jalics, Laci <laci.jalics at delphi.com> wrote:
>
> I've created a thought starter slide here on audio routing/policy management.
> http://wiki.meego.com/images/Audio_arch1.pdf (couldn't attach it do to posting size limitations)

Great doc, I have a few questions / suggestions (maybe I'll have more
in the future, but it's just to begin ;) ).

> Essentially all the architectures that I've seen have a dual processor solution: a low speed micro to handle power moding, CAN bus, and early audio in vehicles.  DSPs are common in automotive systems as well.  So, I've created a diagram that starts to capture the hw/sw architecture relating to audio routing and control.

- Are audio/video codecs running on the DSP? In such a case you need
to draw a connection bw GStreamer and the core, possibly showing the
presence of DSP-specific plugins (for instance, something like
gst-openmax or gst-dsp). It should be up to the adaptation layer to
deliver them.

- HTTP streaming is not effective for audio latencies (I really don't
suggest you to use it if it can be avoided). RTP is definitely better,
as it allows standard NTP syncronisation across the network entities
through RTCP packets (not handled by pulseaudio so far, but from
GStreamer). Depending on the degree of reliability and abstraction you
may want to connect the "rear seat" with either GStreamer or
pulseaudio, but RTP is definitely the transport you want to use.

- You could expand "Policy Manager" (I'd suggest Resource Policy
Framework) into decision point and enforcement points. Of the latter,
you'll need at least two separate ones:
  - VEH enforcement point.
  - Pulseaudio enforcement point.
  - What is the MOST driver supposed to do that cannot be done in
ALSA/pulseaudio with the MOST plugin? In case it's not possible to
aggregate the layers, you'll probably need a third enforcement point
here, otherwise you can handle the thing through the pulseaudio
enforcement point.

> The vehicle processor on the left controls the DSP as well as manages the dedicated hardware blocks relating to early audio and external blocks (tuner, chime, CD, HD radio, ...).

So if understood well the architecture, FM radio data never goes
through the CPU (direct I2S connection)... how are you planning to
route it to the "Rear seat" then?

> Once the main processor wakes up becomes the master audio manager by controlling the vehicle processor via an SPI interface.  Within the main processor exist the policy manager that needs to manage PulseAudio, the Vehicle Processor and the Most bus. I tried to identify the control lines and the audio data lines.
>
> I'm particularly interested in how the MeeGo Policy Framework and PulseAudio support this type of architecture.
>
> The diagram is not perfect, but I'm hoping it will stimulate discussion.

It's already an excellent starting point.

Regards

> No worries,
> laci
>
> Laci Jalics
> Engineering Group Manager (Platform Group) Delphi M/C 483-300-130 3000 University Drive Auburn Hills, MI 48326
> Phone: 248-732-1825
> Fax: 248-836-1774
>
>
>
> **************************************************************************************** Note: If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ****************************************************************************************
> _______________________________________________
> MeeGo-ivi mailing list
> MeeGo-ivi at lists.meego.com
> http://lists.meego.com/listinfo/meego-ivi
>