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

2010-11-04 Thread Dan Harasty

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


<>___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

2010-11-04 Thread Tom Rondeau
On Tue, Nov 2, 2010 at 8:24 PM, Dan Harasty  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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] throttle blocks and GUI responsiveness

2010-11-02 Thread Dan Harasty
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





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio