Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 08 2001 - 16:06:27 EEST


>> the point about "totally synchronous operation" is that its defined by
>> the audio stream handled by the audio interface. when we say that
>> we're ready for the "producers" to "get" and the "consumers" to "put",
>> then to me this implies only one thing: there are "nframes" of
>> data/space available to move audio data from/to the audio
>> interface. as soon as you try to split this up into two different
>> "waits", its very hard to enforce that this condition is being met.
>
>This need to be separated. Conditions may be different and we need to
>satisfy all to proceed (think for an HW PCM producer and a diskstream
>producer).

This cannot be satisfied in any general way.

IMHO, there is only one condition that matters in an audio program:
the audio interface has data/space available. if the application is
not ready to use it (or cannot prepare its data in time), then there
is an error. all other waitable-conditions are outside of the scope of
a generic audio-based "glue" API.

does anybody else think that abramo's model of multiple components
"waiting" on different conditions can work?

>This is exactly what I mean: an audio component will know its source
>buffers and destination buffers and then it will fill the channels it's
>interested in.

audio components in the proposed LAAGA model don't have destination
buffers when interacting with the rest of the world. they supply data
in a fixed format and ask for it to be written to a *channel*. they
don't play any role actually doing this. similarly for collecting
data, they suply a buffer and ask for it to be filled. in both
directions, this is something handled entirely by the server
implementation, not the audio component.

>Like in ALSA PCM API, where we have no function separated by channel.

Actually there are: snd_pcm_area_copy() and snd_pcm_area_silence().

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue May 08 2001 - 16:29:51 EEST