I’m in the process of debugging some OSX audio issue(s). I’ve fixed
a few bugs in the OSX audio module (and also OSX/Darwin for USRP),
that might occur in unusual circumstances. But I’m still seeing the
same issue: when using an audio source, I get audio overruns -
meaning that the audio data is coming in too fast - when the FG I’m
using has any significant processing, e.g. 2 or 3 FIR filtering
operations. I’m using a Core 2 Duo iMac @ 2.16 GHz, and the CPU
utilization is ~50% of 1 processor, so I doubt that the issue is not
enough CPU time.
This issue can be repeated, with enough waiting, when using any scope
or not, so it’s not in the scope or message queue.
I’ve fixed the obvious multi-thread mutex protection issues in the
OSX audio module such that the audio source keeps generating data no
matter overflow or not, so I doubt that the OSX audio module is an
issue any longer.
Thus I started reviewing “gr_single_threaded_scheduler::main_loop()”
from gr_single_threaded_scheduler.cc. Starting on line 165, the code
reads
+++++++++++++++
if (d->source_p ()){
// Invoke sources as a last resort. As long as the previous pass
// made progress, don’t call a source.
if (made_progress_last_pass){
LOG(*d_log << " Skipping source\n");
goto next_block;
}
+++++++++++++++
I enabled debugging in the OSX audio module and logging in the
scheduler (and moved logging to std::cerr, so-as to get both outputs
in the same stream) and can thus review/“see” the data flow in from
the audio source and through the FG.
With that code in place (not commented out), reviewing the debugging
output, the audio module is slowly accumulating extra data in its
buffers, which eventually leads to an overflow. What seems to be
happening is that, because the scheduler is making progress with each
pass - just a little bit here and there-, and thus
“made_progress_last_pass” is ‘true’, the scheduler is not getting
source data often enough to avoid the overflow. The scheduler “pipe”
bursts with new audio data, then trickles until nothing further can
be processed, which for some reason takes a “long” time, then bursts
again and repeats.
If I comment the “if (made_progress_last_pass){” part out, recompile
and reinstall, then I can run the exact same programs without audio
overruns. Reviewing the log, the data is coming in as fast as it is
being processed - no more, no less. The audio buffers never hold the
data long enough to overflow. The scheduler “pipe” bursts with new
audio data, then reduces to a trickle for a bit until new audio data
is available, then bursts again. The “burst” and “trickle” pattern
repeats much like with the code in place, but “much faster”.
Since the source is what regulates the FG throughput (and/or a
throttle, if needed), IMHO the source should be allowed to enter data
into the scheduler “pipe” as often as it needs to. This would seem
to keep the scheduler’s pipes “more full” than the current
implementation, reducing the chances of data overflow or underrun.
I have not tested this to see if it happens on Linux or Windows.
Thoughts? Questions? - MLD