Audio Driver (with bounty!)


13.1 ABE Overview
The audio back end (ABE) module is a subsystem that manages various audio and voice uplink and
downlink streams between the initiator
13.1.1 AE Subsystem
The AE is the core of the ABE subsystem. It performs the real-time audio processing within the ABE:
• Mixing
• Muxing
• Volume control
• Smooth muting
• Sampling rate conversion
• Side-tone equalization
It sounds like AESS is a small part of ABE. If the ABE sets up how to connect to ram and other parts of the system for AESS to do the work with the sound and output it to speakers, then ABE would need to be set up before AESS?
I don't know how much work is involved in putting those components into ready states. The code might have been consolidated. It might have been missed that you need both parts.
It's amusing that naming is the hardest part of software/hardware development.
-edit-
Good work on the **mobile** development
 
I finally got some time to work on this and I got some news!
View attachment 39456

Before you get too excited: no, I haven't been able to play sound yet :( but I've made some realizations.

The old Linux-3.8 driver actually have 2 audio "platform drivers":
  • omap-pcm.c - introduced in 2008 with support for Nokia N810
  • omap-abe-mmap.c - added in 2012 as a "ABE low power" driver.
ABE (Audio BackEnd) is somehow related to AESS. Maybe one of them is a component of the other? I haven't looked it up

The Letux port of the audio driver only has 1 "component driver" (it has changed name from "platform" to "component"):
  • omap-aess-pcm.c
It looks to be a port of omap-abe-mmap.c. I can't blame anyone for going with the driver that clearly states that it's meant for the ABE/AESS when porting the code and disregard the older driver.

However, it looks like there's a symbiosis between the drivers happening in the old code.

One of the problems I've had on a newer kernel is that I couldn't even begin to play any streams unless I chose the "OMAP ABE Media LP" device. Choosing this device triggers some special branches in the omap-aess-pcm.c code to let the kernel know about the hw constraints of the device. If I chose any other device, that branch was not hit and the kernel refused to play.

I started investigating what code did the same thing on the older kernel, and I found that it was done in 2 places. In omap-abe-mmap.c when using the "OMAP ABE Media LP" device and in omap-pcm.c otherwise.

It's clear to me that parts of the old omap-pcm.c driver has to be ported over to omap-aess-pcm.c, but I don't know what yet.

I'm based off of https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-aess-noprint-v9 if anyone else want to help out!
I tried using the letux/aess-v13 head, but things have changed in the kernel memory management and I wasted about a day debugging stack corruption. I wouldn't recommend it.

That's it for now. Sorry for the delay
Just a quick note: I have a 3.15 kernel working on the PandaES. It still has omap-pcm.c but no omap-abe-mmap.c
So this might be a key to get things solved.
 
Just a quick note: I have a 3.15 kernel working on the PandaES. It still has omap-pcm.c but no omap-abe-mmap.c
So this might be a key to get things solved.
Looks like that Linux-3.15 repo is simply missing the two commits that adds omap-abe-mmap.c: https://github.com/Risca/linux/commits/omap5_uevm-3.8/sound/soc/omap/omap-abe-mmap.c
Notably, the second commit is some kind of big bang "Just fix it" commit before release (my interpretation).

However, if you've successfully been able to use the AESS on that branch, it means that omap-abe-mmap.c is not really needed. Mind you, I was not able to load the AESS firmware when I tried running a kernel from there. The firmware format might have changed between Linux-3.8 and Linux-3.15. Unfortunately, I've been unable to build a new firmware based on Linux-3.15 branch :/

The story continues...
 
Looks like that Linux-3.15 repo is simply missing the two commits that adds omap-abe-mmap.c: https://github.com/Risca/linux/commits/omap5_uevm-3.8/sound/soc/omap/omap-abe-mmap.c
Notably, the second commit is some kind of big bang "Just fix it" commit before release (my interpretation).

However, if you've successfully been able to use the AESS on that branch, it means that omap-abe-mmap.c is not really needed. Mind you, I was not able to load the AESS firmware when I tried running a kernel from there. The firmware format might have changed between Linux-3.8 and Linux-3.15. Unfortunately, I've been unable to build a new firmware based on Linux-3.15 branch :/

The story continues...
Yes, the firmware format must always match the kernel expectations. It appears that you have to run /root/build-aess-fw to build the firmware binary from source. It is included in the omap-audio-3.15 branch. What I don't know is if it works on the OMAP5. Just tested on the PandaES (where I have access to the handsfree speaker through expansion connector J6).
 
Back
Top