El 17/04/17 a las 13:04, Marcus Müller escribió: > Hi Daniel, > > I'm not overly happy with the splitting using Throttle: Sooner or later, > it's going to turn out either your PC or your SDR device are a few ppm > faster clocked, and then your throttle rate doesn't match your actual > sample consumption rate, and then some buffers are going to over- or > underflow.
Hi Marcus, Of course, that was just a quick test. The throttle was deemed to fail eventuall due to sample rate mismatch. > The buffers are the reason you're seeing this: GNU Radio works on a > buffer interface, which means every block is producing samples as fast > as possible – that is, until the output buffer is full. Buffering is a > wanted effect – it allows for higher computational efficiency, and is > absolutely necessary when marrying a device with a fixed, deterministic > timing (i.e. the DAC/ADC of an SDR device) with a variable-scheduling, > non-deterministic computer (i.e. software running in a general-purpose > operating system on a general-purpose CPU). > > Now, 5s sounds like way too much. Maybe you're operating your SDR device > at a very low sampling rate? Try to use a higher one (and drop the > throttle and UDP sink/source split). That would make the buffers (which > keep their size in samples) "shorter" in terms of time. I was running at 1Msps. I've tested the same flowgraph at 10Msps and the delay is now around 1 second, which seems fine. Is it possible to tweak the buffer sizes in an easy manner so I could get the same effect at 1Msps? Regards, Daniel.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio