On Mon, 2010-11-29 at 01:10 +0100, fons@xxxxxxxxxxxxxxx wrote: > On Mon, Nov 29, 2010 at 07:28:45AM +0800, Ng Oon-Ee wrote: > > > The ONLY major ALSA 'feature' which is not supported is memmap. Direct > > access to the sound-card's memory. Pulseaudio's devs are of the opinion > > that this cannot and should not be emulated, and that apps which use it > > are broken in design. I've not come across any latest-version-apps where > > this is still a problem, do you know of any? > > While I would agree with anything else you wrote, if the comment > quoted above refers to ALSA's mmap access mode it is wrong. > > All this mode has to do is provide the client application with > pointers to read/write a period of samples from/to. The memory > pointed to _may_ be directly mapped to a HW buffer, but there > is nothing in the API that requires this - it could just be a > user space memory buffer. ALSA itself provides mmap access to > e.g. USB audio devices, this most certainly does not provide > pointers to any USB hardware. > > Mmap mode can be emulated quite easily on top of another access > mode (although it usually makes more sense to do things the other > way round). > > There is nothing wrong with apps using this mode, and in fact > many do, including Jack. Given that any driver will have either > access to real HW buffers, or will create its own ones in memory, > it's in fact the simplest and most direct way to get to the audio > data. > > Ciao, > Thanks fons, I was under the mmap alsa capability implied direct control over the hardware's memory.
