discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Sample rate of file souce/sink


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Sample rate of file souce/sink
Date: Wed, 16 Mar 2016 14:24:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

Hi Jesse,

this is not embarassingly simple!
So, the point is that GNU Radio is really totally agnostic when it comes to sampling rates. For all the blocks, sample streams are really nothing but a sequence of numbers. Whether the signal was physically sampled at 1MS/s or 1S/s doesn't matter; the only thing that matters is e.g. how long one event is in unit of samples (e.g. the signal source doesn't really use the sampling rate for anything but to calculate how long on period of cosine is – a signal source with a cosine frequency of 1kHz and a sampling rate of 32kHz will produce exactly the same signal as one with a sampling rate of 1 and a cosine frequency of 1/32; there's really no difference in behaviour).

The architecture of GNU Radio implies that every block processes the input he has as fast as possible to produce output, with which the next block works as fast as possible and so on; the fact that there's a limit in processing speed of your file source comes because somewhere, a downstream block has a full input buffer, so the block before that can't produce samples, because there would be no space to put them.

Now, if all your blocks were infinitely fast at processing samples, the job of the block providing this (that is a very common mechanism in buffered architectures, it's usually called backpressure) would always fall to the throttle block (whose only job is to do exactly that - only copy as many samples over per iteration as allowed to keep the time-averaged sampling rate at the specified limit).

Now, if there's another block that effectively limits the rate of samples going through the flow graph, e.g. a complicated calculation that is CPU-bound, then that will put up its own backpressure. Together with the backpressure of the throttle block, that might decrease average rate even below the throttle's rate.

For a deeper understanding of why this happens it would be necessary to look at your actual playback flowgraph and the blocks involved.

Best regards,
Marcus
On 16.03.2016 02:29, Jesse Reich wrote:
This is probably embarrassingly simple but I can't seem to find the answer anywhere. I just recorded a signal to a file sink with a sample rate of 100k. I go to use that file as a source with a throttle set to 100k and it seems to playback at approximately 1/10 the speed. When I step up the throttle sample rate to 1M it seems to be closer to real-time. What am I missing??

Thanks,
Jesse


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

[Prev in Thread] Current Thread [Next in Thread]