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

[Paul Davis <pbd Op Net>]

>No, they don't. They asked to me to make this feasible. The point is the
>ability to send sample in advance and then retract them if it's needed
>(by example because another event occurred). This help to reduce
>latency. Obviously the alternative is to generate audio "just in time"
>with a tiny chunk size, but this may have a negative impact on
>performance.

the semantics of snd_pcm_rewind() can be handled within a callback
model. the application simply uses its own buffering rather than
relying on that of the library. the application does whatever it wants
with the data until a callback delivers it "just in time" to the audio
h/w.

what i don't like in the ALSA model for this is that the notion of a
buffer with a pointer to where the next set of data will be
read/written is buried inside the same library that handles audio
i/o. this is the wrong level, IMHO.

clearly, it would be silly to have every app that wants to do this
reimplement the code. but that doesn't mean that providing a way to
overwrite data in some kind of data staging area should be part of
alsa-lib (or some wrapper).

--p