Crackling during playback of a libPd patch - esp. related to keyboard presentation

Question

I've integrated a libPd patch in iOS.

When entering a text field, and presenting the keyboard there's some crackling sounds.

How would I go about debugging this?

NB I've tagged this question with Objective-C and iOS, however this question may require knowledge in all four tags - libPd and Pure Data well:

What is Pure Data

1. Pure Data is a powerful programming language for the manipulating of audio from core mathematical concepts. It's widely used games as well as DJ and other music focused applications. Some example apps that are built with Pure Data and libPd are: The Rj Voyager app from RjDj and the Inception App from Warner Brothers.

2. libPD is a method of embedding Pure Data patches (developed using the visual interface) within an iOS app. Controlling the Pd interface is done via a publish/subscribe message interface similar to OSC or MIDI. .

The GitHub page for libPd is here: https://github.com/libpd

What help am I looking for?

I'm not sure where to start debugging this. Someone who has integrated and used libPd on iOS could surely share experience. It could be related to the following:

• How threading works, and how it interacts with the main queue
• What sample rates work best given the target devices
• What debugging tools are available.
• Other advice earned through deep experience.

Answer 1

I don't know anything about PD, but it seems likely that the presentation of the keyboard is causing you to be CPU-starved for some reason. You might try:

• verifying this still happens when in release and not attached to a debugger (log messages cause long delays when attached to the debugger, which alone can cause hiccups like this)
• profiling your code using Instruments to see if you're inadvertently using a whole lot of CPU at once or
• increasing buffer sizes so PD doesn't need CPU as often.

Answer 2

I was experiencing the same symptoms in an app I'm working on. I did manage to ascertain a couple of things early on. My recent changes involved sending alot of messages to pd during app init. I noticed when debugging that when I reduced the amount of messages sent, the sound improved. Also, I didn't see this in the simulator, only on the device.

The libpd example PolyPatch was pretty useful in this case, if you increase the amount of patches that can be generated. I found that the sound was breaking up with many patches open, in exactly the same way as in my app. This is quite simply where the overhead of using libpd takes its toll on performance. What's also clear is that simplifying a patch (so it contains less objects) impacts performance. But by far the biggest hit is creating a new, separate patch. So you won't want to be creating huge numbers of patches. Debugging does of course take a toll too.

44.1khz works pretty much everywhere as far as sample rates go (it's the pd standard too). And there's nothing to stop you debugging the libpd code right there in xcode, i've done that a few times. Other than that, there is the issue of debugging patches. You can either set up your patch with test versions of your objects directly in pd, or you should be able to set up libpd to view the same output as you would normally see in pd's main window in the console (you just need to make sure that you have something like this

[PdBase setDelegate:_dispatcher]; 

in your code - it's all in the dox of course). Then you just pepper your patch with print messages as required...

Hope it helps, and is still relevant after 3 mths...!