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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
