Do CvNormalBayesClassifier::train() and CvNormalBayesClassifier::predict() dynamically allocate heap memory internally ?
Hi all,
I'm wondering if any folks with knowledge of OpenCV's internals can offer some advice.
I'm looking for a library which offers a few different classifier types like Naive Bayes, SVM, Neural Nets etc.
I need to be able to call the classifiers preditct/classify methods from a high priority and real-time audio callback thread. This means I cannot use methods which dynamically allocate heap memory internally or block/wait. So no locking or waiting on mutexes etc. Essentially I need things wait free.
I looked into using the mlpack machine learning library but it dynamically allocates / requests heap space from the OS all over the place as does libarmadillo which it uses internally for matrix operations.
Basically I need something which allocates all memory for containers and matrices only inside object constructors and is wait free. So no std::vector push backs or Mat(10, 10) type calls inside predict() - preferably not inside train() either.
Otherwise it looks like I'll be climbing through trying to implement a couple of real-time audio friendly classifiers myself......daunting.
Hoping OpenCV might be the answer.
Josh
"I need something which allocates all memory for containers and matrices only inside object constructors and is wait free" -- i'm afraid, all of them do some heap allocation, both in the training and the prediction phase.
(if your problem is binary/2class, you could e.g. try to train an SVM, then get the decision function, and do your own dot-product)
Ah. Suspected this would be the case.
Thanks for the speedy reply regardless berak.
Back to the drawing board.
hang out a bit here, maybe someone else has a different view on it.
Good idea. If anyone else can recommend any other alternatives to me writing some classifiers from scratch It'd be much appreciated. This is for an Msc research project and time is limited so any alternative the the former would be a life saver.
just curious, what are you trying to "learn" there ?
I.e.
User has an audio plugin/synthesizer. The user can vocalise/"beatbox" the sound of a kick drum into a microphone run into an ADC.
First step is onset detection (determine when a sound/note of interest occurs in a buffer stream) - This part is completed and works in real time.
The classifier (naive bayes or whatever) is then either trained (potentially incrementally per buffer) or has its predict method called. The user will have trained the model with a number of instances of their vocalised kick drum sound, snare sound etc. Features built up from various spectral characteristics(feature extraction in real time is also complete now).
Upon classification or an audio a label/class is returned such as 1 = kick, 2 = snare in real-time and corresponding synth sound fires.
Because classify/predict() is called on the audio thread it has to be wait free or the real-time 1 buffer out every 5.2ms (approx) requirement may not be met and this causes audio drop outs (audible glitches and pops etc.) Things need to be run time deterministic I guess is the right description
ah, nice. thanks for explaining !
Naive Bayes may not be the way to go, some sort of clustering or nearest neighbour approach might be best as likely to be a lot of zero frequency feature values occurring using Naive Bayes etc. But this could be mitigated enough to get a working prototype of the full system hopefully.
Then if time allows I can attempt some other classifier types but first and foremost I need to get a real-time prototype running.
Thanks :)