[alsa-devel] Monotonic timestamps

[Jaroslav Kysela]

On Fri, 11 Apr 2008, Lennart Poettering wrote:

> > +int snd_pcm_hw_params_can_forward(const snd_pcm_hw_params_t *params);
> > +int snd_pcm_hw_params_can_rewind(const snd_pcm_hw_params_t
> > *params);
> 
> Hmm, I am not sure if this function this way is really such a good
> idea. For example, for the PA backend for libasound/ioplug there might
> be part of the delay buffer that can be rewound and part of the buffer
> that cannot. Just think of an RTP output device. The part of the
> buffer that is maintained on the sending side might be rewindable. But
> as soon as the audio data entered the network, it might not be
> rewindable anymore, although that network "buffer" will still
> contribute to the latency.
> 
> I'd prefer some API that can tell me how much of the data actually is
> rewindable. For hw devices this would return the same size as the
> buffer size. For others it might return something smaller, and 0 for
> devices that do not support rewinding at all.

Ok, I got the idea. I've added snd_pcm_rewindable() and 
snd_pcm_forwardable() functions to alsa-lib.

> > Also note, that forward/rewind returns always 1 for current alsa-lib, 
> > because rewind was implemented in the dmix plugin. But I can imagine, that 
> > this check can be required for some compressed streams.
> 
> I assume for most of ioplug it will not return 1, right?

The rewind/forward implementation in ioplug is actually broken, because it 
moves only internal pointer without notification to real external plugin. 

						Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.