[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