[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] throttle blocks and GUI responsiveness

From: Dan Harasty
Subject: Re: [Discuss-gnuradio] throttle blocks and GUI responsiveness
Date: Thu, 04 Nov 2010 10:49:01 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6


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<address@hidden>  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

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

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 Harasty

You 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.


Attachment: dharasty.vcf
Description: Vcard

reply via email to

[Prev in Thread] Current Thread [Next in Thread]