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

[Paul Davis <pbd Op Net>]

>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. 

>ALSA API *is* an abstraction suitable for PCM streams (hardware,
>software, network oriented, etc.). Probably not the best doable (and I'm
>very interested in improvements), but likely one of best available.

Yes, I agree with this. But I don't think that PCM streams as
presented by ALSA are the right model for computer audio.

>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.

>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.

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
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 ...).

--p