Re: Is it time for remove (crap) ALSA from kernel tree ?

From: Carlo Wood
Date: Sun Jun 24 2007 - 18:44:21 EST


On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio API
> - is more flexible
> - provides OSS as emulation
> - supports more hardware

I sent a patch to the ALSA developers 4 years ago.
It was never included in the kernel :/

Here's the comment from a script that I once wrote to
make some closed-source dinosar code run (speech recognition)
on modern linux:

# Note that ALSA (Advanced Linux Sound Architecture), the sound drivers that
# replace the older OSS as of kernel 2.5, also introduce a problem for some
# soundcards: unlike the OSS drivers, the ALSA drivers limit the recording
# buffer to the hardware limit of your sound card. For example, the SB Live!
# only has two 'period' buffers (called fragments before), and although
# viavoice requests an 'arbitrary number of periods, size 1024 bytes', it
# only gets two periods of 1024 bytes: 2048 bytes in total! The ViaVoice
# engine however doesn't even process sound until it sees at least 6102 bytes.
# The 'solution' for this is to increase the buffer size (from 1024 to say
# 8192), this script also takes care of that. Unfortunately, also that is
# possibly not enough: the sound is read from the hardware in chunks of
# 'period size' and having only two buffers this is often causing an underrun.
# When ALSA sees an underrun... it stops the sound stream.

My (four year old) patch can be found here:

http://www.xs4all.nl/~carlo17/alsa/index.html

I STILL think that ALSA should restart the stream after an underrun,
but I am not someone who asks twice :p usually.

--
Carlo Wood <carlo@xxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/