Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]

On Sat, Aug 01, 2015 at 09:03:57PM +0200, Pavel Machek wrote:

> That still leaves these reasons to route it though the CPU:

> * ability to record calls

This is usually done by routing the audio to both the baseband and CPU
simultaneously - this gives you the recording without taking the
latency hit in the call data path which makes life a lot easier.  

It's not that the hardware *can't* route audio to the CPU usually, it's
that call quality is extremely sensitive to any additional latency in
the path and mobile communications are inherently at the high end of
what's acceptable so system designs generally pay attention to ensuring
that no additional latency is introduced (like will tend to happen if
you have a general purpose OS pushing data around, or in general extra
copies).

> * ability to do signal processing on the data, like echo cancel for
>   speakerphone (or perhaps changing your voice to female one)

Right, typically if the system was intended to have these things (I'd be
surprised to see something ship without at least echo cancellation)
there would be some dedicated DSP in the data path implementing them
already.  Some of the applications really need extremely low latency
sample by sample operation which requires a dedicated processor anyway.
This is often part of the baseband, though there can be audio DSPs
elsewhere instead or as well.

> * ability to do advanced stuff like GSM-to-VOIP gateway.

Yes, though that's a completely different use case and is going to have
latency problems anyway.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]