doing mixing in the kernel only "makes sense" because the current API
sound apps are using now is not exactly friendly. The only place we can
inject code between the binary app and the output is through LD_PRELOAD
hacks or in the kernel itself.
mixing in the kernel is bad for the usual "keep it in userspace, man"
reasons. even more so because mixing wants to use stuff like
3dnow/kni/mmx/vis which are generally a pain in kernel space.
> I'd have thought you'd want to be able to open the soundcard as many
> times as you want and 'grab' a subset of the available channels.
well, the sound apps should be making calls to a library that says "give
me a list of cards" "ok, give me a few output channels". none of this
open(/dev/*) ioctl() stuff. And that would be the advanced apps, nearly
all would just say "hey, I don't care, give me an output stream to
whatever output the user expects sounds to come out of."
notice that some newer chips only support 16bit stereo 48khz data. Any
bets as to the number of apps that won't work because they don't expect
this format and are talking directly to the driver? If there was a nice
library in their path, it could happily be resampling for them.. people
that are directly mapping the dma buffers will have to deal, but thats
the price they pay.
> The only other approach would be to allow one open, export all channels,
> and then have a super-esd that subsequently re-exports to apps.
we have the source. we have _lots_ of options. the hard part is making
it simple/useful. For reasons still unknown to me, the sound universe
seems to be one where over-engineering is painfully easy. (I've done it
myself with previous projects :))
ESD has the right basic model, but needs work and updating.
-- zach
- - - - - -
007 373 5963
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/