Analyze audio with a timerCallback


#1

Hi all, 

 

I'm trying to analyse blocks of audio periodically (say every 500ms), then save or display the results. I tried the following, but my host crashes when the timerCallback() function executes...

 

1. Declare float* channelData as a public member of the PluginProcessor.

2. Update channelData each time processBlock executes.

3. In the PluginEditor set up a timerCallback which uses *ourProcessor = getProcessor() to access the processor. 

4. Copy the ourProcessor->channelData variable to the timerCallback function and then run some analysis on it in the PluginEditor.  

 

I've been looking for tutorials and GUI update posts, but I haven't had much luck. Can anyone give me any advice on where I'm going wrong?

 

Cheers


#2

channelData is a pointer to what though? 

Is it a separate buffer into which you're copying the audio data - or does it point to the buffer provided to your processBlock() function by JUCE? 

 


#3

Ah, sorry. I wasn't allocating anything to the pointer, just literally pointing it to the buffer provided by the AudioSampleBuffer in the 'processblock' function when "buffer.getSampleData (channelNo)" is called. 

 

 


#4

I've kinda resolved this problem now by just simply doing all of my audio analysis in the processor using a Timer, but I now have another problem which is that it sometimes takes longer to run the analysis than it does to call the timer, so if I'm extracting things like MFCCs from the block, by the time the next timerCallback happens, my analysis method is still running. This means I have to leave really long gaps (up to 2000ms) between analysed audio frames, or the host crashes. 

Is there a way I can analyse congruent frames without crashing? 

 

Thanks!  


#5

The way I would do it - and of course this goes pretty deep and I don't know the specifics, but hopefully something I say helps.

 

Do your analysis in the processblock but I don't know why you need timers there. Just shift the data around, figure things out, and save them to variables which you declare in the audio processor.

Then, you can use the timer in plugin editor to read those variables.

 

I do this for example to track overall signal level and display it as animation in the editor.


#6

Thanks for your suggestion. The reason I was using a timer in the processor is because when i run my analysis code in the processBlock routine, the host crashes because the analysis takes too long to complete (I'm actually extracting quite a lot of audio features). I thought the best way to do this would be to just extract features periodically, but do it less frequently.

Even with the timer though, if I set the period to around 200ms and the extraction class takes longer to compute, I still get glitches and ultimately the whole thing crashes. Just wondered if there was a way around this. 

 


#7

In ProcessBlock you know the sample rate. Why not use that for calculating relative timings? As turntable suggested, keep your eyes on the MFC pattern: store results in the processor class and view them in the editor (which can run at a relaxed speed of 25 - 30 fps).


#8

Yea you really dont need a new timer. You've got one running already - the processBlock and the samplerate.

 

I'm not entirely sure that is exactly your problem, but I think you should be able to figure out quite a lot of data about the audio before it starts slowing down, so I just imagine you are doing something in the processblock that is bottlenecking the whole thing. Maybe you already know to do this, but just go through commenting out line by line until you find the offending lines, then you'll know where the problem is.

 

Take everything you can out of the processBlock and just send the data to other places for processing, if possible. Don't do anything graphical in the processblock.

 

Good luck.