[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] STS Question

From: Michael Dickens
Subject: [Discuss-gnuradio] STS Question
Date: Fri, 17 Aug 2007 12:11:35 -0400

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]