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
