Development Topics > Host Development

Hosting the vamp-example-plugins

(1/2) > >>

Hitmuri:
Hi,

i don't know if it is the right section but i have a problem using the vamp-example power spectrum plugin in an application that i am writing.
i load it and use it that way (it's temporary code ;) )  :


--- Code: ---        loader = PluginLoader::getInstance();
        key = loader->composePluginKey(pluginName, pluginID);
        plugin = loader->loadPlugin(key, sampleRate, PluginLoader::ADAPT_ALL_SAFE);
        outputs = plugin->getOutputDescriptors();
        RealTime rt;
        RealTime adjustment = RealTime::zeroTime;
        if(!plugin->initialise(2, 64, 128))
        {
                cout<<"Error initializing analysis"<<endl;
        }

--- End code ---


--- Code: ---        RealTime rt;
        Plugin::FeatureSet features=plugin->process((float**)(aae->getBuffers()),rt);
        for (unsigned int j = 0; j < features[0][0].values.size(); ++j)
            //here i get the values

--- End code ---

this way i get the values of the spectrum, but the first two values keep increasing over time, and don't seem to be related to the spectrum.

Am i doing something wrong ?

thanks

florent

cannam:
Well, the code looks OK to me at first glance -- although I obviously don't know what aae->getBuffers() will return -- hopefully, the current processing block.

When you say "the first two values keep increasing over time", do you mean the first two values in each returned column?  i.e. features[0][0].values[0] and features[0][0].values[1] ?  If so, I can't suggest any reason for that -- perhaps some example output might make things clearer?


Chris

Hitmuri:

--- Quote from: cannam on June 15, 2009, 15:29:05 ---Well, the code looks OK to me at first glance -- although I obviously don't know what aae->getBuffers() will return -- hopefully, the current processing block.

--- End quote ---

Yes actually it's the buffer (jack_default_audio_sample_t[2][128]) from the jack process.


--- Quote from: cannam on June 15, 2009, 15:29:05 ---When you say "the first two values keep increasing over time", do you mean the first two values in each returned column?  i.e. features[0][0].values[0] and features[0][0].values[1] ? 

--- End quote ---

yes exactly


--- Quote from: cannam on June 15, 2009, 15:29:05 ---If so, I can't suggest any reason for that -- perhaps some example output might make things clearer?

--- End quote ---

Ok if i don't play any sound (i.e the buffer is empty), the values are 0 0 and they don't change.
When some changes occur in the buffer (a sound is played), the values are really strange at first (45.0 / 345.0 / 11.0)
then they go back to a very little value when the sound stops and start increasing if i don't play any sound :

1 2.70579e-13
0 1.10692e-12
0 7.10114e-12
1 1.7577e-12
0 2.41869e-11
1 6.04672e-11
...


Any ideas ?

Thanks for your answer

Florent

Hitmuri:
Hi,

do you have any idea on that particular problem ?
I really don't understand why it doesn't work .

Florent

cannam:
Sorry... I had intended to reply, I must have got distracted or something...

Just to recap, the first two values should represent the square of the magnitude of the DC output of the short-time Fourier transform, and that of the first non-DC bin (perhaps with some factor depending on the windowing). The DC (0Hz) bin just reflects whether the balance of the signal is positive or negative during the analysis period, and its square is not necessarily going to be useful or related to the rest of the spectrum.  The next bin is the lowest separable frequency component (e.g. 43Hz approx in a 1024-point FFT).

Running this plugin myself, the results do look OK.  There is not supposed to be any feedback from one processing block to the next such as might cause a value to keep increasing in the absence of any input.  My first response to the sort of small values you're seeing would be to suggest soundcard converter noise, but a bug is possible (I just haven't seen it yet).

You're using ADAPT_ALL_SAFE when loading the plugin, which means the host SDK is going to do the FFT for you.  Does it make any difference whether you build the host SDK with FFTW support or the built-in FFT?  (It shouldn't, but it's worth a try.)  The option for this is somewhat hidden; I don't especially want distributors using it because it changes the effective license of the SDK, but if you read near the top of src/vamp-hostsdk/PluginInputDomainAdapter.cpp you'll see that adding -DHAVE_FFTW3 to the Makefile should be enough to build it with FFTW instead of the built-in FFT.  (It will run faster then, too.)


Chris

Navigation

[0] Message Index

[#] Next page