On 3 September 2015 at 16:43, Kevin Reid <kpr...@switchb.org> wrote: > On Sep 3, 2015, at 8:24, Murray Thomson <murraythomson...@gmail.com> > 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. > > 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/> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
