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?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
