[arch-general] Opinions on pulseaudio [WAS: PulseAudio in [testing]]

[Ng Oon-Ee]

On Mon, 2010-11-29 at 01:10 +0100, fons at kokkinizita.net 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.