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

[Tanu Kaskinen]

On Thu, 2013-07-11 at 11:04 +0100, Ian Malone wrote:
> On 11 July 2013 10:38, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
> > On Thu, 2013-07-11 at 01:13 +0200, Peter Meerwald wrote:
> 
> >> 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).
> >
> 
> I'm writing from a position of complete ignorance here as to what this
> code has to interact with, so maybe it's just not possible in context,
> but isn't a ring buffer able to solve the concatenation problem
> without copying? Of course maybe this is exactly the leftover samples
> handling you're talking about.

It's just not possible in this context. The resampler backend
implementation (usually an external library) can't read from a ring
buffer, and even if could, the input data does not come from a ring
buffer that could be directly fed to the backend implementation.

-- 
Tanu