At Fri, 26 May 2006 18:30:36 +0100, James Courtier-Dutton wrote: > > Takashi Iwai wrote: > >> For mmap, all that happens is that the application asks for a mmap > >> address from the kernel. > >> If we could get the kernel to manipulate shared memory, so that the mmap > >> address given to the application is shared with the daemon, surely that > >> would work. > >> > > > > The sharing of memory between the app and the daemon is easy via a > > simple mmap invoked from both sides. But, sharing the mmapped buffer > > from a sound driver between the daemon and the app over yet another > > driver is a tough problem, because the buffer is strictly bound to the > > sound card hardware. > > > > > We need to consider first the basic design more deeply. > > For example, even if we get the mmapped buffer, it's not enough for > > the whole operation, especially when the period/buffer size doesn't > > match with whta OSS requires. > > > > > > Takashi > > > > I was thinking more along the lines of User App -> OSS kernel shim -> > userland daemon buffer, one buffer per user app -> alsa-lib. > So, the mmap would not be a real mmap, it would be a simple matter of > tricking the User app into thinking it is mmapped. It would be a double > buffer really. Then it's as same as what I thought. This implementation is pretty easy. Let both side call mmap just like POSIX shm does. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
