[alsa-devel] On non-rewindability of resamplers

[Alexander E. Patrakov]

26.04.2014 07:32, Raymond Yau wrote:
> 2014-04-25 22:09 GMT+08:00 Alexander E. Patrakov <patrakov at gmail.com 
> <mailto:patrakov at gmail.com>>:
>
>     25.04.2014 12:19, David Henningsson wrote:
>
>         I understand that you have a mathematically perfect approach
>         to this, as
>         well as other algorithms. This would indeed be the best goal,
>         but given
>         an imperfect world, where we're forced to choose between
>           1) no rewinding at all
>           2) imperfect rewinding in the sense that it sometimes can
>         produce
>         hearable artifacts
>
>         ...I'm not sure 1) is always the right choice...
>
>
>     Understood. But IMHO (2) with a warning would be better than the
>     current situation of (2) without any indication of the problem.
>
>
> Does extplug or ioplug plugin support rewind ?
>
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_external_plugins.html
>

Both plugins currently pretend to support rewind. Extplug shouldn't do 
that at all if we are talking about perfect handling of rewinds, and is 
OK as it is if we accept an imperfect output of the correct length (but 
I don't want to accept this). Ioplug shouldn't support rewind if mmap_rw 
== 0, and I can't say yet what to do with mmap_rw == 1. Running the test 
program posted earlier in this thread on top of lfloat + jack produces 
silence (good!), but, depending on the jack settings, the program either 
hangs or runs faster than it should. So still a bug, but I am not sure 
if it is of some fundamental nature.

> 1) DCA plugin convert 6 channel to compress audio at fixed sample rate
>
> seem only allow sequential write and no random write
>

Right. The same applies to any LADSPA plugin.

Still, there is a funny thing that I want to share. Even though the 
dcaenc library only allows sequential writes, here is what happens on 
ALSA rewind followed by a write. When processing a rewind, extplug moves 
the slave application pointer. Upon reveiving a write, extplug submits 
the newly-written data for encoding, and then writes the result (which 
unfortunately contains some samples from the rewound part of the sound) 
over the previously encoded data, thus correctly discarding part of the 
old data. So the end result is of the correct length, with one or two 
broken DTS frames (copy-pasted from old and new DTS data) in the middle. 
Still bad, but this is different from the ioplug-based a52 plugin, which 
simply ignores rewinds, but pretends that it succeeds.

> 2)  The I/O-type plugin is a PCM plugin to work as the input or output 
> terminal point, i.e. as a user-space PCM driver.
>
> mmap_rw specifies whether the plugin behaves in the pseudo mmap mode. 
> When this value is set to 1, the plugin creates always a local buffer 
> and performs read/write calls using this buffer as if it's mmapped.
>
> does this mean ioplug can have its own local buffer which is different 
> from the slave ?
>

Ioplug doesn't have a slave. It just transfers data to somewhere.

> e.g. a52_pointer seem use delay of the slave
>

What a52 has is not really a slave in the traditional ALSA sense. And 
the encoder in ffmpeg allows only sequential writes.

> 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.

-- 
Alexander E. Patrakov