According to Ignatios Souvatzis:
>
>Hi Brett,
>

Hello...

>
>What would the semantics of such an mmap be? 

I would imagine what they are doing is mmap'ing the driver dma buffer
into user-land.  I have not seen any code yet (I think I have tracked
down some possible driver sources but have not looked) but I would
imagine the way to do it is to have a mmap'ed region with a head and
tail pointer and the data.  The userland code looks at the tail and
updates data after this, carefully updating the tail pointer.  The
kernel land code dumps dma blocks to the sound device and updates the
head pointer.  All sound stops when (head == tail) and the buffer is
circular on the size of the mmap.  I am not sure this is correct - I
may be way off with how this thing works, I do really need to have a
look at the Linux code.

The scheme does have the advantage of not requiring large amounts of
data to cross the kernel/user boundary.  

>Maybe virtual time-warp into a buffered version of the input stream?
>

I don't think that this would be useful, I believe the main aim is to
reduce the kernel/user data transfer.

>Just mmapping the hardware registers doesn't give us much, IMHO, with
>the exception of reduced hardware independence of userland code. But I
>might be wrong.
>

I think mmap'ing the dma buffer would result in a performance gain.

-- 
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
  "Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.