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@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
