Ross and Conner, It's absolutely true that each callback must respond in a certain amount of time. The maximum execution time of each callback is something you need to consider. Ross' language is more precise, but maybe some arm-wavy examples will help:
- If each callback does the same amount of work (e.g., each call does an FFT on all the incoming data), then each callback likely takes about the same amount of time. In this case, moving to another thread *probably* won't help (although, depending on the system, it might, especially if you are anywhere near the allotted time you have for each callback). - If some callbacks do different amounts of work (e.g., filling a buffer and doing one FFT every three or four callbacks), then the maximum time is much larger than the average. In this case, passing the audio to another thread and doing the work there will likely help, because the additional buffering helps to "spread the work around". bjorn On Fri, Jun 12, 2015 at 4:25 AM, Ross Bencina <rossb-li...@audiomulch.com> wrote: > Hey Bjorn, Connor, > > On 12/06/2015 1:27 AM, Bjorn Roche wrote: > >> The important thing is to do anything that might take an unbounded >> amount of time outside your callback. For a simple FFT, the rule of >> thumb might bethat all setup takes place outside the callback. For >> example, as long as you do all your malloc stuff outside the >> callback, processing and soon can usually be done in the callback. >> > > All true, but Connor may need to be more careful than that. I.e. make sure > that the amount of time taken is guaranteed to be less than the time > available in each callback. > > An FFT is not exactly a free operation. On a modern 8-core desktop > machine it's probably trivial to perform a 2048-point FFT in the audio > callback. But on a low-powered device, a single FFT of large enough size > may exceed the available time in an audio callback. (Connor mentioned > Raspberry Pi on another list). > > The only way to be sure that the FFT is OK to run in the callback is to: > > - work out the callback period > > - work out how long the FFT takes to compute on your device and how many > you need to coompute per-callback. > > - make sure time-to-execute-FFT << callback-period (I'd aim for below > 75% of one callback period to execute the entire FFT). This is not > something that can be easily amortized across multiple callbacks. > > > The above also assumes that your audio API lets you use 100% of the > available CPU time within each callback period. A safer default > assumption might be 50%. > > Remember that that your callback period will be short (64 samples) but > your FFT may be large, e.g. 2048 bins. In such cases you have to perform > a large FFT in the time of a small audio buffer period. > > If the goal is to display the results I'd just shovel the audio data > into a buffer and FFT it in a different thread. That way if the FFT > thread falls behind it can drop frames without upsetting the audio > callback. > > The best discussion I've seen about doing FFTs synchronously is in this > paper: > > "Implementing Real-Time Partitioned Convolution Algorithms on > Conventional Operating Systems" > Eric Battenberg, Rimas Avizienis > DAFx2011 > > Google says it's available here: > > http://cnmat.berkeley.edu/system/files/attachments/main.pdf > > If anyone has other references for real-time FFT scheduling I'd be > interested to read them. > > Cheers, > > Ross. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- Bjorn Roche @shimmeoapp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
