To register and login, use your Google, Twitter, Facebook, LinkedIn, or OpenID credentials.

This is allowing us to stop most spam registrations. We've deleted most of the spam accounts that got through, and we're closely watching for more.

libpd handling of non-interleaved audio buffers

tabolstadtabolstad Posts: 5
edited December 2012 in Pd Everywhere

Am I correct in looking at C code that [processFloatWithInputBuffer] takes the interleaved samples and deinterleaves them before sending them to your patch, only to re-interleave them before sending them back?

Since CoreAudio prefers non-interleaved buffers, it would be nice to skip the extraneous interleaving steps.
A function that handles an AudioBufferList structure directly would make things extra simple for iOS people.


  • reakinatorreakinator Posts: 301

    The Obj-C method your referencing does indeed process interleaved samples, although there is a libpd_process_raw that does not (it is not used in the Core Audio stuff).

    Why do you say Core Audio prefers non-interleaved samples? I was under the impression that the 'canonical' format was interleaved. While we could almost surely get the audio unit to process non-interleaved samples, it would be difficult to notice the performance gain on either iOS or OS X (not sure about how things are working in Android / OpenSL land..).

  • pbrinkmannpbrinkmann Posts: 686 ✭✭

    Another thing is that it's not as simple as interleaved vs non-interleaved. Internally, Pd uses one buffer for input and one buffer for output. Those buffers are non-interleaved, but their sizes are fixed at 64 frames. If your audio unit operates at the same buffer size, then you can skip the (de)interleaving steps (that's what libpd_process_raw is for), otherwise you still have to break your buffer into chunks of 64 frames each (which essentially amounts to interleaving 64-sample sub-buffers).

    Another question is what use case you have in mind. PdAudioUnit and PdAudioController are meant to protect developers from the complexity of CoreAudio, so they should never have to think about buffer formats and such. Maybe we can create a high-level API that does what you need without exposing low-level details like AudioBufferLists.

  • tabolstadtabolstad Posts: 5
    edited December 2012

    @reakinator CoreAudio has two "canonical" formats. AudioSampleType is for i/o and is interleaved. AudioUnitSampleType is for passing buffers around to DSP blocks and is non-interleaved.

    I see that PdAudioUnit just takes from the input unit, sends it to pd, then sends it back out, in that case, it's probably best to leave everything interleaved.

    I'm using pd as part of a larger processing graph, hence my desire for the non-interleaved samples. (Admittedly, I am probably in a very small minority of people using it this way.)

    Performance wise, it probably doesn't make too much difference these days.

  • pbrinkmannpbrinkmann Posts: 686 ✭✭

    @tabolstad You may be in a small minority for now, but I have a hunch that that'll change soon. So, we need to be prepared for this sort of use case. I'm reluctant to introduce additional complexity into PdBase itself, but I would be totally in favor of adding a small utility library that offers a process function that takes AudioBufferLIsts and handles any (de)interleaving under the hood.

  • @pbrinkmann, Yeah, it makes sense to keep the Apple specific stuff out of the main part. I'm going to play with it a little, I also want to see If I can make it run in the background. If I come up with anything good I'll let you know.

  • reakinatorreakinator Posts: 301

    Thanks for the explanation. Yea we're definitely interested in plugging PdAudioUnit into a larger, more complex system. It seems you already have some success doing this, which is comforting.

    I myself have a couple things I plan to try in order to 'stretch' things along these lines: I'm planning to use it in a small Cocoa app and attach other desktop specific audio units. But by all means, please post your specific use cases / desires up here, roadblocks, etc., so we can make our efforts as useful to others as possible.

Sign In or Register to comment.