On 3 September 2015 at 17:04, Murray Thomson <murraythomson...@gmail.com> wrote:
> > 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. >> > 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/> >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
