[alsa-devel] Monotonic timestamps
perex at perex.cz
Mon Apr 21 12:47:48 CEST 2008
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 Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel