I started new project for the Linux. Code name is 'The Ultra Sound
Driver'. Primary goals are:
1) Create fully modularized sound driver which will support kerneld.
2) Create new Ultra API which breaks most of limitations of current OSS API.
3) Create Ultra Library (C,C++) which covers Ultra API for applications.
4) Create Ultra Manager - interactive configuration program for driver.
At first point - I don't assume recoding of current OSS/Lite
driver. New Ultra driver is written from my sources from The Linux
Ultra Sound Project (http://www.pf.jcu.cz/~perex/ultra). I assume only
that lowlevel code can be ported from OSS/Lite driver.
If you are interested with this project, please, check URL
http://ultra.jcu.cz for more details. I created two mailing lists - one
for user support and second for developers. Info about mailing lists is
on the Web. I hope that some people join to me (I need both type of
programmers/hackers - kernel & application)). I worked alone (with
occasional hacking of few peoples) for 4 years on previous a little
bit experimental project which was only for Gravis UltraSound cards :-(((
It's not good for great work, but I made couple experiments how can good
Linux sound driver looks - GUS cards are enough complicated. I need some
people to revision of my work (especially API), of course. I think that
new Ultra API must be more universal and robust than OSS have. Again,
join to me... Yes, we can make sound better...
Maybe I have three questions related to this project:
1) Anyone knows about main reasons why OSS/Lite must be only one sound
driver/API for Linux? (I hope that this question turn on some
discussions about current OSS/Lite API - maybe we can move to ultra
mailing lists).
2) Anyone have good reason why sound driver can't exist only as group
of kernel modules? I think that it's now time for modularized kernel.
2) I see in this mailing list few messages about problems with sound DMA
buffer mmaping to user space and freeing mmaped DMA buffer.
I support mmaped access, too. I'm not expert for kernel memory manager,
but looks like mmaped area and file is asociated with inode, but these
things are independent. If file was closed mmaped area can still exist,
but I (probably wrong) free DMA buffer when file is closing (releasing).
My question is: Can I detect at which point application unmap memory
area? Is there any callback for it or some like this?
Jaroslav Kysela
-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu