On Mon, 9 Jan 2006, René Rebe wrote:
> > I don't think so. The library can do such conversions (and alsa-lib does)
> > quite easy. If we have a possibility to remove the code from the kernel
> > space without any drawbacks, then it should be removed. I don't see any
> > advantage to have such conversions in the kernel.
>
> Also, when the data is already available as single streams in a user-space
> multi track application, why should it be forced interleaved, when the hardware
> could handle the format just fine?
Because the conversion doesn't cost anything. Trying to avoid it by
making the API more complicated (I would even say confusing) is extreme
overkill.
Each feature of this kind requires two additional API
calls (one for checking in which way the hardware works and another to
set the device to use the feature). It's also possible to implement the
feature in a way that requires more new calls. By adding support for
dozens of features like this it's easy to create an API that has 1500+
calls.
Even worse this kind of features weaken the device abstraction provided by
the API. The applications will have to check for this and
that and provide support for 100s of special cases that may be required by
certain devices.
IMHO this has already happened with ALSA. Normal
programmers (other than few of the world class gurus) have no way to
understand the API. I would consider myself at least moderately
experienced sound programmer (25+ years of programming experience and more
than half of it on sound). However even after two years of more or less
intense learning I don't know what is the preferred way to use ALSA. I
think this is a general problem because practically all ALSA applications use
different ALSA API calls.
Best regards,
Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
