[Kernel] OMAP5 ABE (Audio Back End) and Pyra Prototype V3
Dr. H. Nikolaus Schaller
hns at goldelico.com
Tue Mar 18 09:11:48 CET 2014
thanks for these clarifications! This confirms that we have to think more about it to
find the best compromise...
Am 17.03.2014 um 11:09 schrieb Peter Ujfalusi:
> On 03/16/2014 10:43 AM, Dr. H. Nikolaus Schaller wrote:
>> I have studied the OMAP5 docs a little more and the ABE is more or less what
>> the DSP in the OMAP3 could have been used for: shutting down the CPU and
>> running audio functions autonomously.
> ABE stands for Audio Back End and it consists of AESS or AE (Audio Engine
> SubSystem), McPDM, McBSP, DMIC, McASP.
> Yes in essence AESS is a DSP. It can move data around, do resampling, mixing, etc.
>> Unfortunately this has some consequences:
>> * there are only 3 McBSP ports - we need them all for: Bluetooth, FM-Radio,
>> UMTS modem
>> * the codec port is a McPDM - which is a TI proprietary format (on
>> OMAP3+TWL4030 it was a PCM channel)
>> * the only MCPDM compatible codecs appear to be the TWL6040/6041
>> * I am not sure if the ABE-Firmware for the "AE" is a binary BLOB or just some
>> control settings - so some Freedom enthusiasts may complain about that
> It is a blob, yes. It contains the AESS binary and it also contains additional
> information like audio controls, routes, etc.
> In a same way as most WiFi cards have Firmware we need to load the DSP code to
> the AESS to be able to use it.
> The code to support AESS is not yet upstream. It has dependency on ASoC
> Dynamic Firmware.
Ok! I think we will needs some time until we have the Pyra hardware to
test things. So maybe mainline will be 3.16 or 3.18 when the Pyra is finalized.
> I'm maintaining the AESS support (only OMAP4 is tested, OMAP5 should not be
> hard to get it working) here:
> The branch 'next-bnw/ti-audio-next-3.13' is the latest rebase I did, I'm
> planning to do this for the 3.14 as well soon.
> The base-bnw/* branches are just topic branches and they are merged to form
> the next-bnw/* snapshots and also my personal working branch:
> peter/topic/ti-audio-next-bnw-wip (which is the same as the 3.13 snapshot
> The firmware is not in there, I think I'm going to place it and push that as well.
Yes, tracing the firmware is a little difficult. There appears to be an Ubuntu
>> This means:
>> * if we want to use the ABE (to save power while playing sound or phoning
>> around) we must use the TWL604x
> Also AESS helps with resampling, routing, mixing. With McPDM/twl6040 (no AESS)
> for example if you want to play audio to the speaker (or line-out) you need to
> play 4 channel audio and place the stereo data to channel 3 and 4. Channel 1
> and 2 is going to Headset/Earpiece.
> With AESS you would have separate PCM for this so you do not need to care
> about this. There are other things as well, but can not recall them all.
>> * if we don't use it we maybe can use the McASP for I2S
> Note that McASP is only TX, it can not receive data. It also lacks AFIFO which
> can cause audio underruns when the system is stressed...
Oh, that is good to know! So we will only have 3 McBSPs we need for
* Audio codec (speaker/line)
* Bluetooth (headset)
* FM radio
So we have to sacrifice one. Unless we can use the McPDM interface for Audio
>> * if we don't use it we have to write a lot of software to make audio work
>> * if we use the TWL604x it must very likely be placed on the CPU board
>> (HDI/micro via multilayer) - which means we must route audio over the B2B
>> connectors (which isn't a big problem for speakers but maybe for headphone,
>> microphone and line-in)
Well, it would be more flexible to have the audio codec on the CPU board. Then,
people can develop other boards and choose their own codec scheme that best
fits to the CPU.
>> * if we use the TWL604x we can't use the simple potentiometer for loudness
>> control as in the OpenPandora but must do that with buttons and in software
That is something ED must comment on...
>> (maybe one of the Cortex-M4 cores can control that even if the A15 system hangs?)
>> Hm. I think this needs much more thoughs and discussions than is urgent for
>> the next Pyra Prototype (which will *not* have the real CPU board, just an
>> adapter to the EVM - so it will not yet have a working audio subsystem).
>> So I think the best will be to just (temporarily?) add a Class D amplifier
>> (LM4666) for Protoype Version 3 so that we can at least test the speakers in
>> their enclosure.
More information about the Kernel