If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
It's not necessarily "better" to do mixing in the kernel instead of in userspace.
The maintainers of Linux won't allow any floating-point operations in the kernel, because that would require a save/restore of FPU state on entering a system call and on returning from a system call, which has a performance cost.
Incidentally, the original developer of of OSS (Hannu Savolainen) seems to have GPLed the current upstream OSS (OSSv4) now, so it's not the license that's keeping it out of Linux upstream anymore. Instead, it seems to be the issue of in-kernel mixing that's the problem (and maybe other problems too). According to Hannu's comment here (search for "OSS does this by" to find the comment), the mixing code runs with interrupts disabled and does its own save/restore of FPU state. That alone is probably sufficient to prevent it from getting merged into Linux upstream.
Switching the audio via the Xfce Mixer works well enough. Why can't the mixer be extended without affecting the sound APIs.
Again, then the functionality of Pulse is then simply re implemented i the Xfce mixer. Not eliminated, re-implemented. The code doesn't go away.
You are confusing implementation specific issues with architectural requirements. If the specific implementation of Pulse is sub-standard then that can be fixed but the functionality needs to be implemented somewhere. If not in Pulse, then elsewhere, but definitely no in the driver itself.
Shifting the code means you've moved it, not eliminated it.