Throttle blocks and GUI responsiveness

GNU Radio
1

Hello, all.

I’m still getting up to speed on gnuradio… (does that make me a
gnoob? or maybe a gnuub?)… :wink:

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.

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

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

  1. 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 H.

2

On Tue, Nov 2, 2010 at 8:24 PM, Dan H. [email protected]
wrote:

thought it would be.

only play one NOTE at a time. We’ll assume the note has two components, and
keyup and tone stopping.

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

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.

Tom

3

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