Audiokit: AKFrequencyTracker hogs cpu, 45-50% pegged.

[ghost]

I have a fairly complex audio graph of AKplayers, mixers, boosters, compressors, limiters, etc.
I set them up and then call Audiokit.start().
I have controls to start / stop instruments.
Even when no sound is playing, the CPU is at ~44%. When sound is playing, increases to about 50-55%.
Only when I call Audiokit.stop() does the thread go away and CPU goes to effectively zero (1-2%.)

Why is audiokit hogging cpu when no sound is played? I can understand a small amount of constant load but 44% seems excessive.
This causes my device to heat up, my battery life to go to hell.

Another potentially related issue may be that when the device is warm to hot, the audio stutters a lot... probably because of the AURemoteIO thread getting throttled?

What am I missing?
-g

[aure]

I'll take a look at the frequency tracker. Its probably not the most efficient code but I didn't think it was so bad before, perhaps something got borked.

[sieren]

@ghubaddole any specific function call in that stacktrace? Like was it sp_ptrack_compute ?

[sieren]

@ghubaddole the frequency tracker is based on code here: https://github.com/PaulBatchelor/Soundpipe

Unfortunately none of it uses SIMD or NEON optimizations (or abstraction layers like vDSP) because the main goal was portability I suppose.
It might be worth asking @PaulBatchelor if there's anything you could do to optimise it.

@aure Do we have any rules when it comes to the Soundpipe Library? I was thinking of optimizing some of that code using Apple's vDSP library, which obv we couldnt merge upstream because it'd make the code platform specific.

[aure]

We have our own copy of Soundpipe embedded into AudioKit, so we can do stuff like this. I wouldn't mind making a copy of one of Paul's things, like sp_ptrack, and calling sp_ptrack_vdsp or sp_ptrack_apple.

[sieren]

@ghubaddole no worries, but it may take a while before I have the time to sink my teeth into this.

[sieren]

Hey, sorry if I wasnt clear. By a "while" I meant its probably going to take a few weeks before I have the time. I'm currently traveling and have literally zero time to look into this.

[PaulBatchelor]

@ghubaddole If you really need this done quickly, you may benefit from studying the code yourself?

The code for the ptrack algorithm is contained inside of a single C file and a header file (which gets amalgamated into a single header "soundpipe.h" via command line one-liner). I'm posting them here in case anyone wants to take a look at it.

Here they are in the Soundpipe master branch:

https://github.com/PaulBatchelor/Soundpipe/blob/master/modules/ptrack.c
https://github.com/PaulBatchelor/Soundpipe/blob/master/h/ptrack.h

Here is some sample C code using it:

https://github.com/PaulBatchelor/Soundpipe/blob/master/examples/ex_ptrack.c

Here is ptrack in AudioKit:

https://github.com/AudioKit/AudioKit/blob/master/AudioKit/Core/Soundpipe/modules/ptrack.c

I imagine if you are building AudioKit from source, you could use a drop-in replacement of ptrack, assuming the external inputs/outputs are the same.

As you can see in the top of the C source file, the original creator of the algorithm is Miller Puckette (probably as a PD object somewhere?), and was ported as Csound Opcode by Victor Lazzarini. Those are the two people you'd want to contact to really get insight into what is going on, and places to optimize.

@sieren is a very talented developer who does this stuff professionally. I have no doubt they will do amazing things to optimize this particular algorithm in AK if/when they get the time. Sometimes we all need to be reminded again from time to time that the contributors to AK do so out of the goodness of their heart, with no compensation beyond a pat on the back. This particular kind of optimization does take a non-trivial amount of time and expertise to do, and people get paid very well in the industry to do tasks like this. It would be awesome if it were to get done, but there is ZERO obligation for it to happen.

[sieren]

Worth noting that just because I promised I'll take a look at it, does by no means mean I can actually get this job done. I've joined AudioKit because I don't code as part of my dayjob anymore and this is a fun way to stay up to date. But these kinds of optimisations are challenging, given I haven't written DSP Code in years.