At Fri, 26 May 2006 17:33:39 +0100, James Courtier-Dutton wrote: > > Takashi Iwai wrote: > > At Fri, 26 May 2006 12:29:11 +0100, > > James Courtier-Dutton wrote: > > > >> Takashi Iwai wrote: > >> > >>>> 7) Provide better OSS emulation support. E.g. redirect all access to > >>>> /dev/dsp into user space so it can use all the features of alsa-lib > >>>> without needing aoss. (aoss does not work if the application uses > >>>> dynamically linked audio driver plugins. > >>>> > >>>> > >>> A dummy kernel driver just to translate syscalls to communication with > >>> a user daemon is the only possible workaround, IMO. This idea was > >>> denied once quite ago, but I don't see any other good way right now. > >>> > >>> > >> That is my thought as well. When I looked into the idea some time ago, I > >> concluded that is would be a rather large project, so I did not proceed > >> as I have other more important (for me) ALSA features. > >> Can a user space daemon create /dev files, so that the application calls > >> never actually reach kernel space? > >> > > > > No, only the kernel driver can handle certain syscalls like ioctl and > > mmap properly. So, it must be a kernel driver that communicated with > > OSS apps (unless using LD_PRELOAD hack). > > > > The driver interprets each syscall to a certain protocol communicated > > with a dedicated daemon, and the daemon interprets it again to the > > real ALSA access. > > > > > >> If we can create such a pipe, that can forward > >> open/close/read/write/ioctl, that should be enough. We then have to > >> think about shared memory to look like DMA space to the application > >> using us. > >> > > > > mmap would be still tricky, maybe a kind of emulation via read/write. > > > > > > Takashi > > > > 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. > Unfortunately, this might require some kernel memory manager modifications. > Shall I ask about this on the kernel mm list? I don't think it's worthy at this stage at all. 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
