On Mon, 27.08.07 22:47, Nikita V. Youshchenko (yoush at cs.msu.su) wrote: > > It's always the same issue. We cannot reliably emulate mmap'ed audio > > device access. Neither with ALSA nor with OSS. > > > > It's not a problem specific to PA. It's the same issue with almost any > > non-hw driver for libasound. > > May I be a bit currious and ask why? > Isn't mmap'ed device just a buffer where application writes data, and audio > driver picks data from (or vice-versa for capture)? No, traditionally you get direct access to the hw playback buffer by mmaping it. I.e. the PCI memory is directly mapped into your process memory. For devices like USB however this works differently and the buffer you mmap is merely a bounce buffer which is than used to pass the data to the USB controller. Hmm, but actually you are right, the ALSA mmap API is a lot more flexible than the OSS mmap API and would allow proper emulation for PA. I've added this to my TODO list now. The problem with OSS mmap is that it lacks commit/begin and also silently assumes that there is no further latency between the mmap buffer in the actual speakers -- which is obviously never true on a sound server, and not even on normal hw, where additional filters usually delay output a couple of samples. However, ALSA exports latency information about that, so this might indeed be fixable cleanly for our pa plugin for libasound. So in summary: OSS mmap can only be used sensibly for PCI and ISA hw devices. ALSA is much more flexible and can use mmaping as a flexible zero-copy data transfer method. > http://www.redhat.com/archives/fedora-desktop-list/2007-January/msg00080.html Yes, I know. Monty is actually a collegue of mine. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
