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@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.