[alsa-devel] On non-rewindability of resamplers

Raymond Yau superquad.vortex2 at gmail.com
Mon Apr 28 08:57:53 CEST 2014

>> 3) Do pulseaudio keep a copy of client 's buffer ?
>>  when do pulseauido mix two or more client's buffer ( before write to
the sound card or after receive data from client )
>> seem pulse plugin is not rewindable too
> That's a limitation of the pulse plugin, originating from ioplug design.
The pulse API does allow rewinds (see the last two parameters of
pa_stream_write), but ioplug with mmap_rw = 0 essentially ignores ALSA
rewinds, i.e. it is impossible to know in alsa-plugins/pulse/*.c that a
rewind has to be processed.

Once the appl_ptr is rewinded to the nearest position from hw_ptr, it is
the responbility of the application to write at least one period of audio
immediately for some card.

Data is routed, converted and mixed from several sources before it is
passed along to a final output


Playback and record streams always have a server-side buffer as part of the
data flow. The size of this buffer needs to be chosen in a compromise
between low latency and sensitivity for buffer overflows/underruns.

as pulseaudio only recommend application to use a reasonable size (e.g.
pulse plugin allow client to select extreme small buffer size which sound
card cannot support) pulse plugin should increase the constraint to a
reasonable size which are supported by most sound card

(e.g. minimum period time of snd-ymfpci is 5ms)

The server-side per-stream playback buffers are indexed by a write and a
read index. The application writes to the write index and the sound device
reads from the read index. The read index is increased monotonically,

How do the sound device reads from the read index ?

while the write index may be freely controlled by the application.
Subtracting the read index from the write index will give you the current
fill level of the buffer.

look like this buffer still contain the audio in original format sent by
the client if the difference is the fill level and can be used for per
stream softvolume

Seeking in the Playback Buffer

A client application may freely seek in the playback buffer.

PA_SEEK_RELATIVE_ON_READ - seek relative to the current read index. Use
this to write data to the output buffer that should be played as soon as

what is current read index ?

do the read index mean the place which pulseaudio start to perform
reasampling, downmixing/upmixing and mixing of all clients ?

Does pulseaudio internal resampler support rewind ?

More information about the Alsa-devel mailing list