embedded sound architecture question

[Lorenz Kolb <alsa-dev@lkmail.de>]

On Wed, 2007-05-09 at 14:20 -0700, John L. Utz III wrote:
 > On Wed, 09 May 2007 22:47:34 +0200
 > "Joachim Förster" <mls.JOFT at gmx.de> wrote:
 > > My question is: Does the architecture described below make sense/is
 > > reasonable with ALSA and Linux?
 >
 > i think you might have to answer an earlier question first; 'does it
 > make sense to call this an ac97 controller?' I dont recall seeing a
 > ring buffer as part of the ac97 standard. i'd suggest that you take the
 > time to flesh out completely how the ring buffer is supposed to replace
 > dma and ram while still presenting an ac97 set of verbs because i am
 > stuck with the gut feeling that you will some important things will
 > have to be really different.

Hi, I am the "Hardware-Guy" in the project.

And I am quite sure there is no limitation on what to built into the 
AC'97 controller (from a specs point of view)
The controller's job in the AC'97 standard is afaik mainly a parallel to 
serial conversion. As the codec's link is serial.
But I am not quite sure, if you do understand: we have complete control 
of what the hardware-part does. So our main idea is: presenting some 
sort of "dedicated" RAM to the system.
So what does memory mean for a system: it is a bunch of addresses 
offering both a read() and a write() (maybe also a burst_read() and 
burst_write()).
The only question is: will Linux-kernel be able to see our dedicated 
memory as memory and does this way make sense for ALSA.
It is not a question of "is this possible for a AC'97 controller?".
We are not building a simple/stupid AC'97 controller as it can be found 
on billions of mainboards, but in some parts it sticks to the rules of 
AC'97 (at least in case of the interface towards the codec, as the codec 
is an AC'97). So actually it is an AC'97 controller, as it drives an 
AC'97 codec.
So what are the benefits of the idea not using "normal" DMA?
Each write/read to memory normally "freezes" the CPU, either because the 
CPU does this read/write or because the Bus is occupied. Having an 
dedicated memory in the controller avoids this quite well. The CPU 
freezes only whenever it writes data to the controller's memory (or 
reads from it). Accessing the memory from the controller does not have 
an effect on the bus and thus neither cpu nor memory nor bus become 
occupied.
The main reason why we do not want to rely on the cpu is because it is 
for an embedded system. So we do not talk about giga-hertz. We talk 
about a system with a 100 MHz bus architecture and a PowerPC with 300 
MHz. And the system has more tasks than only playing some audio...
So the design goal is minimizing the system load while offering a 
maximum of features (with an affordable amount of logic).

Greetings,

Lorenz Kolb