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

Peter Meerwald pmeerw at pmeerw.net
Tue Jun 17 07:10:47 PDT 2014


Hello David,

> > > Third iteration.
> > 
> > paplay --latency-msec XXX audio_s16_2ch_44k1.wav
> > on beagleboard-xm @ 1 GHz, kernel 3.15

I want to re-benchmark with SHM off, at first sight it appears that load 
is LOWER (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

look at the error path of pa_srbchannel_read() in do_read(), file 
pstream.c:

    if (re == &p->readsr) {
        r = pa_srbchannel_read(p->sr, d, l);
        if (r == 0)
            return 1;
    }

re->memblock is acquired above, but not released in case of error;
the fail exit path releases the memblock if necessary

the return value of 1 looks suspicious too (should be -1 or 0 I think)

return 1; -> goto fail;
works for me, patch following

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

my runtime library has backtrace(), but returns zero data; may some 
misconfiguration, resorted to printf() debugging :)

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)


More information about the pulseaudio-discuss mailing list