Xlating FIRs just generate the sin internally and apply it themselves; they are mathematically equivalent to shifting your signal and filtering it afterwards.
You can, of course, use bandpasses, if you're after a specific sprectral shape. Try the gr_filter_design toolbox, it's even neater than doing your calculations in Matlab (or scipy).
However, as Mike already pointed out, depending on your signal and potential interferers of course, selection by trunkated fft is faster and as intuitive.
Awesome - I will stick with Xlating FIRs then. I will have to get smarter on how to use the FFT to do the frequency shifting. I checked out Mike's app, but I don't have 3.7 installed yet so I couldn't play around with it.
I will give the block core affinity a try. I think what maybe happening is that 2 process heavy blocks are being scheduled for the same core. I have a 4 core machine and it is only hitting ~60% CPU utilization, but it stops/slows decoding the trunking stream while it is doing vocoder work. It doesn't seem to have a problem doing NBFM Demod and recording, so I think the additional processing requirements of decoding digital audio is the problem. The Performance Counters seem like a great approach. It should give me a better idea where all the cycles are going. The network source/sink approach also sounds like a good one. And I have a spare laptop... :)
Awesome project!
Thanks! I am having way too much fun with a $20 dongle. GNURadio is awesome.