Re: [Discuss-gnuradio] Changes to Audio Sink / Source ?

[Michael Dickens]

On Nov 30, 2005, at 6:20 PM, Eric Blossom wrote:
> On Wed, Nov 30, 2005 at 05:41:42PM -0500, Michael Dickens wrote:
> > BTW> In examples/audio, it seems like the "dst" in "multi_...",
> > "dial_...", and "mono..." generate way too much data.  I don't think
> > this is a clock mismatch ... I haven't had time to look further;
> > maybe some who knows these things better than I could take a gander.
>
> The sources generate an unbounded amount of data.
> Got a problem with that?   ;)

Protected memory is a good thing; my first implementation used an  
unbounded list, which quickly took up all available memory and  
crashed the application.  My second implementation bounds the list  
(FIFO ring) to a default of 20 items, but is a user option when  
instantiated; it works much better for memory, but drops old inputs  
quickly and thus the output sound can be undesirable.  My third  
implementation will try to force a slower data rate by (optionally)  
blocking if the queue gets too large or dropping as before (it not  
blocking).

> These are cases where the audio sink needs to set the pacing.

I am still learning about GR's code, so I don't see why the sink  
needs to set the pace here when the source shouldn't be generating so  
much data.  Is there no way to have the source cut back on data  
generation?  Aren't there interrupts or timers available to go off  
every 10 ms & the source would generate 1/100 (or 100 ms and 1/10,  
etc.) of the sample rate's worth of data?  Yes, it's easier for the  
source to generate unbounded data, but doesn't that take a big part  
of the point out of a sampling rate?  The source does seem to take  
the sampling rate as its first argument ...

Either way, the sink needs to handle the "too much data" in some  
fashion (either drop or block).  Thus:

> do_block

This will be trivial to add to my code (it's in there but commented  
out, as it won't compile due to inheritance issues) ... once an  
"work" API is agreed upon for the parent class "gr_sync_block".

So, again, yes, a "bool do_block" or "bool dont_block" seems  
necessary to have in "work" for both source and sink.  I -think- I  
can make the necessary changes to the code to allow for this ...  
should I just go ahead and do it and submit the patches?  Or are we  
not in enough agreement yet?