Tom,Thanks for the input. I follow your philosophical point: multiple rate limiting blocks are at best redundant, and at worst may cause problems.
But in my case, I'm trying get something "nearly synchronized" with a user-interface action: a button press. Thus, all the buffering is working against my purposes.... and I figured throttle blocks may be the answer. (It sort of worked a little bit.)
Perhaps I'll have more luck just starting and stopping the flowgraph (if I can figure out why it seemed to crash when I first tried that).
Or I've heard of another method to limit the amount of buffered data: messing with buffer sizes. I'm not sure how to do that, or if it would work. Was hoping someone could give me the recipe, if it is a viable approach.
-- Dan On 11/4/2010 10:05 AM, Tom Rondeau wrote:
On Tue, Nov 2, 2010 at 8:24 PM, Dan Harasty<dhara...@telcordia.com> wrote:Hello, all. I'm still getting up to speed on gnuradio.... (does that make me a gnoob? or maybe a gnuub?)... ;-) Anyway, to learn how to instrument a simple flowgraph with a wxPython GUI elements, I conceived of something simple to just play audible tones. Like a simple monotone piano keyboard. The good news is I found getting wxPython working was not as difficult as I thought it would be. However, I've found that there is a pretty big lag between GUI button clicks and hearing the tone go on, off, or change pitch. Say: about a second. So I know enough GR to surmise that lots of samples are getting buffered, and that is the cause of the perceived lag. I don't need micro-second level synchronizing between GUI button keypress events and tone output.... but getting it to under a tenth of a second would be good. Some of you probably already know exactly what I need to do (and I look forward to your reply). For the rest of you, I'll give you the blow-by-blow of what I tried, anyways. The basic graph is the same as the "dialtone.py" example: Tone 1 ---> + Adder ---> Audio Sync Tone 2 ---> + Yes I said it was a "monotone" keyboard. But what I mean by that is you can only play one NOTE at a time. We'll assume the note has two components, and I need to add them. 1) So first I tried starting and stopping the graph upon keydown / keyup from the GUI. I would set the tones' frequency value before starting the graphs. Alas, this seemed to crash the graph. 2) So I figured in addition to setting the frequency, I would set the tone's amplitude. Now I notice a big lag between keydown and tone starting, and keyup and tone stopping. 3) Ah... just add a throttle block, and control the amplitude after the throttle. Tone 1 ---> + Adder ---> Throttle ---> Mult by Constant ---> Audio Sync Tone 2 ---> + I have keydown set the mult. const. to 1, and keyup set it to 0. Keydown also sets the tones' frequencies. OK, now my tone starts and stop in close sync with the GUI button.... but the upon keydown, I still hear a burst of the former frequency... again, because the samples have been buffered. 4) So next.... I got really confused, and wrote this. I worked hard to think of where I could put the throttle block to ensure that there are no buffered samples at the "previous" frequency. And, well, it doesn't seem there IS anyplace. For example, I considered this: Tone 1 ---> Throttle ---> + Adder ---> Mult by Constant ---> Audio Sync Tone 2 ---> Throttle ---> + but a) doesn't solve the problem that the tone blocks can still buffer lots of on the throttle inputs, and b) it gives me pause to have two throttle blocks (even at the same rate). What's the "right" answer here? -- Dan HarastyYou never need to use two throttle blocks in a flow graph. Also, if you have anything else that clocks the samples, you don't need a throttle block. In your case, if you have an audio output block, that's going to determine the sample rate of the entire system, so there is no need for a throttle. Throttle is _only_ necessary if you have nothing else that limits the sample rate (eg, a USRP or audio source/sink) and when you want to limit the CPU. Mostly, this tends to be useful for running with graphical sinks. Tom
<<attachment: dharasty.vcf>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio