Of course it would be better if someone would implemented it in the audioin function but if you need an immediate solution, I’d just put it in testapp directly (Perhaps do the init calls in setup() and the rest of the mic code in the update() or other methods).
Thanks again falcon. This link is very interesting.
What kind of issue did you find?
At the begging I found there was a big lag in the response, because of choosing less samples than needed.
Then I have found that the fragment size is always a multiple of 192 (that’s why I get 1920 or 2212 samples instead of the 2048 asked). That means discontinuity if the audio samples and a strange FFT depending on the phase of the signals.
As I see now in the link, Aaron Ardiri is creating a thread from callback function with an infinite loop inside (activated by a timer) and building a larger buffer to store the samples and populating all the fragments:
// create the PCM audio thread
err = pthread_create(&g_snd_thread, NULL,
application_pcm_callback, (void *)NULL);
if (err != 0) return 0;
frames = ps.buf.block.frag_size >> 1; // 16bit, 22Khz, mono
frags = 4;
buffer_size = ps.buf.block.frag_size * frags; ===
// lets fill the buffer with random values (white noise)
total_frames = frames * frags;
for (i=0; i<total_frames; i++)
buffer[i] = (signed short)(rand() % 0xffff);
What I was doing different was:
getting just one frag of frames
calling the Audio_input_get_data from update() [not from a timed callback]
Setting a timer, and activate or desactivate it, whenever he is getting WINDOWS Events (g_timer_active = 0 or 1);
It seems it may work. But what I do not know is where to fill the timer (on , off) in OF.
In fact, is it required in OF ??
If you could drop SDL, then would it mean that OpenAL or FMOD (or any other OF sound library) could be implemented in ofxQNX and work both for input or output?
Thanks falcon. This hyperlink is really interesting.
That kind of factor did you find?
During the begging I found on a search engine was plainly a big lag inside the response, due to the fact of selecting less samples than required.
Then I have found which the fragment girth along with length is a multiple of 192 (that’s the causes why I get 1920 or 2212 samples rather of the 2048 asked). That means discontinuity if or when in case the appear samples and a unusual FFT depending in regards to the stage of the says to.
As I see now inside the hyperlink, Aaron Ardiri is generating a thread from callback work along side some kind of countless loop inside (triggered from a timer) and in addition designing a larger buffer to keep the samples along with populating the the fragments:
I will try it because soon since I find some things fixed while using the sound input. This is certainly my first attempt of designing a spectrogram software for the playbook alongside OF.
The Software runs fast!!!
This is working really, really well. I was able to get up and running within hours of receiving a dev alpha device, and that’s including time to port my codebase from oF0062 as well as get everything setup in Windows (I have a Java problem on OSX that makes it awkward/impossible to do BB10 dev there right now)
Anyway, I have an issue where the app is continuing to run after switching away from it. I’ll be delving into ofxQNX to see if I can solve it myself, I just wondered if anyone had already run into it.
Alright, that was simple. If I ever figure out git I’ll submit my changes, but in the meantime it’s a matter of handling the NAVIGATOR_WINDOW_ACTIVE and NAVIGATOR_WINDOW_INACTIVE events in ofAppQNXWindow. I don’t know if ofBaseApp::windowEntry is *supposed* to be used for this purpose, but I’m just calling qnxApp->windowEntry(1) for active and qnxApp->windowEntry(0) for inactive, and making sure I do something appropriate in my mainApp::windowEntry override.