Hi,
> If you have a hardware sink or source involved though, this is *never* the
> correct approach, since you will end up with two competing clocks, and that
> will, over a longer time, lead to over- or underflows. You can solve this
> issue by either using a hardware sink that accepts bursts of data, so you
> don't have to zero pad, or by having a block that passes through input
> samples (e.g. from a constant 0 source) and adds message-generated samples
> when they occur.
Unfortunately that's sometimes the only approach.
If you have a PFB synthesizer that create many parallel channels, then
relying on the sink block burst capability won't work ...
Or for cases where if you don't have a packet to TX, then you should
TX a 'filler' frame rather than 0.
That limitation is pretty much a show stopper when you try to
implement TDMA system TX on gnuradio ... :(
For RX the streamtags now allow a good way to split them in packets,
but for TX that's not sufficient.
Blocks should be able to get a notion of time provided by an external
device. And also monitor the buffer levels.
Cheers,
Sylvain
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
