[pulseaudio-discuss] Crackling audio with Pulseaudio 4.0 and the simple Pulse API.

[Tanu Kaskinen]

On Thu, 2013-07-11 at 01:13 +0200, Peter Meerwald wrote:

> > buffer handling. Converting o_ss.channels to work_channels isn't enough
> > to fix the issue with speech-dispatcher, however, because there's also
> > another thing issue: when resampling happens before remapping, the
> > leftover buffer handling is completely broken, because it assumes that
> > the leftover data from the resampling phase is supposed to be stored in
> > the remap buffer, while it actually should be stored in the
> > to_work_format buffer. At least the ffmpeg resampler needs the leftover
> > handling with the speech-dispatcher stream. I don't have a simple fix
> > for this, so I'll just revert the patch for now.
> 
> the ffmpeg and libsamplerate code use the leftover logic; I assume 
> speech-dispatcher selects ffmpeg or libsamplerate instead of the default
> speex? or is the bug due to the issue in the peaks resampler?
> 
> Tanu, do you know the constellation that triggers the bug? is #output 
> channel > #input channels?

The ffmpeg resampler is used, because when setting up this machine for
development, I was too lazy to install the speex header package, so
speex is not available in my pulseaudio.

The stream that speech-dispatcher creates is mono 22050 Hz s16le, and my
sound card is stereo 44100 Hz s16le.

> a resampler implementation has several options wrt input and output buffer 
> use:
> (i) it allows short reads, i.e. it is free not to use all samples given 
> in the input buffer
> (ii) it allows short writes, i.e. it is free to not write all samples 
> requested to the output buffer
> (iii) both, (i) and (ii)
> 
> save_leftover() is necessary if the resampler does (i)
> 
> doing (ii) is much less painful for PA, there is just more or less (maybe 
> zero) output sometimes
> 
> > It's by no means impossible to add support for storing the leftover data
> > in the to_work_format buffer, if someone wants to work on it, but the
> > leftover code is hairy already as it is, and this would make it doubly
> > so. I will accept patches that do that, although it would be better if
> > the leftover buffer handling could be simplified. I'm not sure if it's
> > possible to simplify the code without affecting the performance, though.
> > I tried pretty hard when I originally wrote the leftover logic. That
> > said, perhaps a minor performance hit would be acceptable just for code
> > readability.
> 
> maybe we can get rid of the leftover logic altogether:
> * ffmpeg is going to be replaced by libswresample / livavresample; 
> swr_convert() [1] takes all input and buffers it, hence is not type-(i)
> * libsamplerate offers three APIs: simple, full, and callback [2]; it 
> seems the callback interface could be used which is not type-(i)

If we can get rid of type-(i) resamplers, that would be ideal.

> nevertheless, I think any type-(i) resampler could be relaxed (made more
> convenient for PA) by implementing a wrapper to add buffering and not 
> pushing back samples to the remap buffer (maybe this is what you meant by 
> simplifying the leftover buffer handling?)

Yes, that's what I meant: make the buffering strictly internal to the
resampling phase. And by performance hit I mean that you probably will
have to do an extra copy of the input data when there is leftover data,
because the leftover and the new input data will have to be concatenated
in continuous memory area so that the resampler can consume both parts
in one go (trying to process the data in two phases doesn't work,
because the resampler most likely won't consume the small amount of
leftover data).

-- 
Tanu