On Thu, Jan 05, 2006 at 03:24:18PM +0100, Jaroslav Kysela wrote:
> On Thu, 5 Jan 2006, Heikki Orsila wrote:
> This sentence makes this in my mind: real people = lazy people.
Yes, but it has good reasons too. The real point of userspace libraries
and programs rather than kernel space is saving effort. Laziness in
programming is good so long as programs are readable and correct.
Your success must be measured according to the number of bugs with ALSA
programs and the time used to develop ALSA support for them. Right now
it looks very bad to me. Even libao can't handle ALSA well, and knowing
some XMMS developers they have hard time with ALSAs complexity. KISS.
> The error codes are documented well.
That's a bad excuse for requiring buffer underruns to be handled
specially because it's not a fatal error. Errors should be handled
as close to the error source as possible, and the ALSA lib is the
logical place to handle underrun by default (unless the application
really is interested in handling underruns specially). Passing errors
through unreasonably many layers causes more complexity for programmers.
> > err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
> > err = alsa_simple_writei(); /* handless signal brokeness automagically */
> > alsa_simple_close();
>
> Well, it's better to create only "fast parameter setup" and "default error
> recovery" functions.
As long as all applications PCM code can be written into 10-20 C lines.
That includes: opening device, writing pcm data and closing the device.
> > Basically ogg123/mpg123 like applications would only need 3 alsa calls.
> > Now everyone reimplementing their own buggy versions of simple mechanisms.
>
> While "official" examples exists for a long time.
btw. your official examples don't work on simple PCM playback didn't
work when I last time tried. Sorry, I can't remember details because it
is so long ago.
--
Heikki Orsila Barbie's law:
[email protected] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[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]