[pulseaudio-discuss] [PATCH 00/12] A new ringbuffer based protocol for PulseAudio

[David Henningsson]

On 2014-06-17 01:01, Peter Meerwald wrote:
> Hello,
>
>> Third iteration.
>
> paplay --latency-msec XXX audio_s16_2ch_44k1.wav
> on beagleboard-xm @ 1 GHz, kernel 3.15
>
>          srbchannel              iochannel
> XXX     PA      ALSA    paplay  PA      ALSA    paplay
> 20      FAIL    FAIL    FAIL    30.0    19.3    7.7
> 30      20.9    14.5    3.8     24.5    15.1    6.8
> 40      15.8    11.1    2.8     17.5    11.4    4.9
> 60      7.8     5.4     1.4     9.1     5.6     2.6
> 80      6.0     4.0     1.1     7.0     4.2     1.8
> 100     4.9     3.2     1.0     6.0     3.4     2.0
> 150     2.6     1.8     0.6     3.2     1.8     1.2
> 200     1.7     1.2     0.5     2.0     1.2     0.8
>
> I disabled srbchannel by setting module-native-protocol-unix argument
> srbchannel=no
>
> so there is an improvement, esp. for low latency
>
> the FAIL manifests itself in
> D: [alsa-sink-TWL4030 HiFi twl4030-hifi-0] source.c: Processing rewind...
> E: [alsa-sink-TWL4030 HiFi twl4030-hifi-0] memblock.c: Assertion 'pa_atomic_load(&b->n_acquired) == 0'
> failed at pulsecore/memblock.c:532, function memblock_free(). Aborting.
>
> this is quite reproducible, and only occurs with srbchannel=yes
> --latency-msec 23 is OK, while --latency-msec 20 crashes within seconds
>
> I have not really looked into it (yet)

Okay, this needs fixing, obviously.

The patch adds some handling of the special srbchannel memblock. But 
that should work the same regardless of latency.

Other memblock handling, i e audio data, should remain unchanged 
regardless of which channel it is sent over.

Maybe it's some kind of race condition that was already in the code, but 
only shows itself now that we have a faster transport medium?

For a start a backtrace would be helpful. I haven't seen anything 
similar here so far.

>> Changes since previous version:
>>
>>   * it's now srbchannel (Shared RingBuffer) instead of srchannel
>>     (srchannel could easily be read as src-hannel)
>
> internal variables and function still named srsomething, should probably
> be renamed srbsomething
>
> e.g. in struct pa_pstream:
> pa_srbchannel *sr, *srpending;
> bool is_srpending;
>
> sr_callback(), check_srpending() in pstream.c

At the time I thought sr was still a reasonable short form of 
"srbchannel" but maybe it's better with srb...

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic