>>> But it does register itself to the OSS subsystem (to
>>> drivers/sound/sound_core.c) like all other sound drivers, so it _is_
>>> part of OSS.
>> no. sound_core is NOT part of OSS. ALSA attaches to it as well. Alan
>> Cox wrote that so that OSS and ALSA could (theoretically) co-exist.
>
>Now I'm nitpicking, but actually only part of ALSA registering to
>soundcore is the OSS-emulation layer.
thats true. but it still means that sound_core.c is not part of OSS.
its funny. looking over that code again, its amazing how much of a
flashback it gives me to when i first started tinkering with audio on
linux, and how utterly out-of-date and absurd it looks now. DSP16?
bwahahaha!
And wasn't soundcore written to
>allow OSS/kernel and OSS/commercial coexists (OSS/commercial drivers
>register to soundcore)...?
alan explicitly wrote soundcore to support distinct, incompatible
sound driver APIs. both OSS/Free and OSS/commercial use the same major
device numbers the last time i looked, and so they cannot be used
together. the source says:
* Top level handler for the sound subsystem. Various devices can
* plug into this. The fact they dont all go via OSS doesn't mean
* they don't have to implement the OSS API. There is a lot of logic
* to keeping much of the OSS weight out of the code in a compatibility
* module, but its up to the driver to rember to load it...
*
* The code provides a set of functions for registration of devices
* by type. This is done rather than providing a single call so that
* we can hide any future changes in the internals (eg when we go to
* 32bit dev_t) from the modules and their interface.
*
even so, its still totally out of date.
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
