> >Bad idea, there are a load of user-space libraries for this purpose -
> >for example ESD, OSS, ALSA and so forth.
>
> No, you miss the point. If people are having to use
> <linux/soundcard.h> at the moment that suggests that there are ioctl
> definitions or something else system-specific that is needed by user
> space. This could be a candidate for inclusion into libc if that
> would be an advantage. Nobody is suggesting including full sound
> functionality into libc -- that would clearly be absurd.
Actually, I don't think I am missing the point. Usually if you want to do
sound stuff with Linux, you'd better include <linux/soundcard.h> or
whatever. The problem is that it is not portable. I want portability - so
any one can port it to *BSD (for example) and expect a similiar interface.
And besides, I think the libc folks won't accept changes like that anyway
- they are far more concerned with portability of the libc functionality
across different ports - and most of these probably won't have sound
hardware installed.
The only real way to guarantee this is to have an universal user-space
interface that abstracts the sound hardware in such a way that one would
expect to play a Micro$hit .WAV file on Solaris or whatever. Then people
can use the facilities provided simply by doing #include
<multimedia/sound.h> or whatever and they can be sure it will abstract
<linux/soundcard.h>.
Maybe.. I don't know.. it's getting off-topic anyway.
Cheers,
Alex
-- "A mind opened by new ideas cannot return to its original limits"http://www.tahallah.demon.co.uk
- 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/