discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] throttle blocks and GUI responsiveness
Date: Thu, 4 Nov 2010 10:05:01 -0400

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

Tom



reply via email to

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