Re: [linux-audio-dev] CSL-0.1.2 Release

[Abramo Bagnara <abramo alsa-project org>]

Paul Davis wrote:
> 
> >I'd define "to abstract" as to find a model that can describe correctly
> >the underlying reality.
> 
> Thats not the way I am using it in the current context. Abstracting
> computer audio for applications means (to me) removing all specific
> details about audio hardware and presenting a model that appropriately
> enables them to do what they need to do. The current state of Linux
> audio applications and their dependence on audio parameters is a
> direct result of OSS; it is *not* a reflection of the only way to
> write audio software. The fact that applications care about things
> like 16bit samples versus 24bit samples is just one example of this
> effect.

This is not abstraction, but the opposite thing: "specialization".

You're not making a conceptual transition:

circle, hexagon, triangle -> geometric shapes

but

circle, hexagon, triangle -> sort of squares

I think it's the wrong approach for something that aim to be generally
adopted and want to last in the next few years, but this does not hurt
your freedom ;-)

> >Your model describes a partial reality, a too partial reality in my
> >opinion.
> 
> Your model describes a world that has already been shown to be full of
> problems and complexity. Other *existing* models that are as simple as
> the one I propose have been shown to work for much more powerful audio
> applications than we have on Linux at the present time.

I think it's not the right approach to try to lobotomize an existing
world to not cope with its complexities.

In real world this is often called "fascism" (and in Italy we are
experts of that, you know) but fortunately here I'd call it only a
design mistake ;-))))

> >Not if this part is not mandatory but used only when needed.
> >
> >I explain better:
> >- an object has zero or more properties
> >- a property has a set of accepted values
> >- the object client may manipulate this set
> >- each object has a policy to choose for each property a value from its
> >current set
> >
> >As you see:
> >- objects don't need to have properties
> >- clients are not forced to cope with properties (also if object has
> >some)
> >
> >I hope to have undermined your stainless belief.
> 
> You have not.
> 
> The model for audio on Linux that I would like to see evolve is one in
> which there are no properties to be manipulated by ordinary
> applications. There are ports on which data is delivered in a standard
> format (99% of the time) using ordinary language constructs (variable
> assignment and pointer walking, for example). There are callbacks to
> deal with the conditions that an application may need to know about
> (data ready/required, buffer size changed, sample rate changed;
> possibly xrun).
> 
> There is one class of application, which I'll call an "engine" which
> does need to interact with objects that have mutable properties (such
> as objects representing/controlling audio hardware). An application in
> the "engine" class drives all other applications via a callback
> model (which supports both in-process and out-of-process callbacks).
> 
> Properties such as sample format, channel count, interleaving,
> stop/start, xrun handling, sample rate, and so on are the concern
> solely of the engine. Non-engine applications do not control them,
> cannot control and do not care about them. The only exception is
> discovering (not control) the sample rate, since that is integral to
> the temporal nature of audio data.

You're simply saying that some (most?) objects have no properties. This
is supported by my model. But other do have some. This is the truth.

Then when you will discover other exceptions you'll invalidate your
model. And believe me, this will happen.

> Finally, I also support a world in which the ALSA "shm" PCM device
> interoperates fully with an "engine", so that programmers who for some
> reason choose to make their life more complex can still see their
> programs run when an engine is in charge of the audio h/w (and
> obviously, when an engine is not, too).
> 
> In the last couple of weeks, I have gained a religious fervour about
> this. I strongly believe that the model represented by ALSA is a

A german once says that "Religion is the opium of the people"...

Can I say now that "religious fervour" does not helps software
development and constructive discussions? ;-))

> superb design for a HAL (including its role as a "S(oftware)AL" too).
> At the same time, I consider ALSA is too rooted in h/w based concepts
> to be the right general audio API to take Linux into the future. Any
> such API would still use ALSA as an underlying layer, but would not
> expose it (ALSA) to anything except the engine class of applications
> (and even then, only a small subset of ALSA's "model").

> Nothing I have said should be construed as being "anti-ALSA" - on the
> contrary I am utterly in favor of ALSA in every way and cannot wait
> for its adoption into the kernel. But that is very different than
> saying that I am in favor of applications being written to use ALSA as
> the API for audio (or OSS or aRrts or CSL or SDL or ...).

And I agree that ALSA is not suitable for this job in its current form
(I say this to remove residual doubts).

-- 
Abramo Bagnara                       mailto:abramo alsa-project org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!