[pulseaudio-discuss] Assert error in pulsecore/resampler.c:trivial_resample

[Tanu Kaskinen]

On Fri, 2010-07-16 at 23:22 +0200, Maarten Bosmans wrote:
> Hi,
> 
> PulseAudio from git master crashes when I play a sound to a combined
> sink of two 96000 Hz sinks. It does not happen if the slave sinks are
> set to 48kHz. Playing directly two one of the slaves also works.
> 
> My default.pa basically looks like:
> load-module module-alsa-sink device=hw:CA0106,0 sink_name=sink0
> channels=2 format=s16 rate=96000
> load-module module-alsa-sink device=hw:CA0106,1 sink_name=sink1
> channels=2 format=s16 rate=96000
> load-module module-combine sink_name=combined slaves=sink0,sink1
> 
> When I play an audio file to the combined sink, the sound can briefly
> be heard and then PA crashes with the following message:
> Assertion 'o_index * fz < pa_memblock_get_length(output->memblock)'
> failed at pulsecore/resampler.c:1394, function trivial_resample().
> Aborting.
> 
> The complete log output is attached.
> 
> I tried to debug it myself. It seems that every time the crash happens
> o_index * fz is exactly equal to
> pa_memblock_get_length(output->memblock).
> But as the whole function is practically undocumented, I can't figure
> whether it is correct to change the assert to use <=, or there
> something else wrong.

Unfortunately, the problem isn't in the assertion[1]. After spending a
while studying the code, I've come to the conclusion that the output
buffer is too small, but I haven't found how it would be possible,
because the resampler code seems to make sure it's always big enough.
Well, actually I think I know one unlikely explanation: the target
sample rate is more than 128 times the input sample rate.

Why 128 times? The resampler output buffer always contains space for at
least 128 "extra" frames. If I've understood the rounding errors
correctly, the trivial resampler can produce more than those 128 frames
of extra output data if (and only if) the target rate is more than 128
times the input sample rate.

Now, is it somehow possible that the rate difference is actually that
huge? I don't think so, unless there's a bug in module-combine.

Could you check with gdb what are the values of r->i_ss.rate and
r->o_ss.rate when the crash happens?

[1] I'd make the assertion more specific, though, which actually makes
it even easier to trigger:

    pa_assert_fp(o_index * fz + fz <= pa_memblock_get_length(output->memblock) - output->index);

-- 
Tanu Kaskinen