Re: [Discuss-gnuradio] Throttle block form wav files

[Murray Thomson]

On 3 September 2015 at 17:04, Murray Thomson <address@hidden> wrote:

On 3 September 2015 at 16:43, Kevin Reid <address@hidden> wrote:

On Sep 3, 2015, at 8:24, Murray Thomson <address@hidden> wrote:

> Even selecting source and sink from the audio card, if I have a wav file playing in another input of the selector without a throttle, the CPU goes to 100%. To avoid it I put the wav file, then the throttle and the the selector. I've read that is bad practice but I couldn't reduce the CPU usage in any other way.

(Please make sure to CC the mailing list in your replies.)

Sorry, it was a mistake. For the list, just clarify that
I have an audio sink using the same audio card @ 96 KHz with the settings set to OK to block YES.

 

Ah. I just looked at the implementation of the selector block, and found that its documentation lies. It does not leave its unused inputs “disconnected” (which is actually good, because that would cause errors in some cases), but connects them to null sinks (which consume all the input they're given).

So, using a throttle is a workaround for this. (The cost is that since the throttle's timing is based on the CPU clock, not the audio card clock, you'll occasionally get either underrun or overrun.)

Here are some better solutions, from simplest to best:

1. Using some method to force the wav source and audio source to match sample rates. Specifically, you could use a “Multiply by Matrix” block to replace the function of the Selector entirely: give it a matrix value of either ((1, 0),) or ((0, 1),) to select just one input.

 

Can I make a multiply to matrix block have several inputs and one only output? If not, I was thinking on multiplying one of them by a constant block zero and then adding both outputs. Would this be a valid workaround?
 

2. Modifying, or creating a replacement for, the selector block which does not connect to a null sink but rather to a block of some sort which never accepts any data and so stops that branch of the flowgraph. (I don't think such a block actually exists, but it could, and there might be something else that acts like it.)

3. Actually remove from the flowgraph whichever of the wav source and audio source are not currently in use. This is the most general, efficient, and straightforward solution, but unfortunately it cannot be built within GNU Radio Companion -- you must write some C++ or Python code. If you don't want to stop using GRC entirely, you could isolate that part by putting the connection changing logic inside a hierarchical block; this would be similar to the selector block itself, but it would be a source, which has the wav and audio sources "built into" it. Alternatively, you could write your main()/top block as a Python program and put the _rest_ of your logic (the demodulator and sink) into a GRC block which is used by the Python program. Either way works.

Thanks, I'll try these solutions tomorrow. I assume that they also apply to add a constant block into a selector block.
 

--
Kevin Reid                                  <http://switchb.org/kpreid/>