:) (Are you sure you meant to thank me? Hahaha... I only mentioned the underlined parameters! :P )
Sometimes I still find myself looking for the cause of a stopped flowgraph, to finally find I connected two streams with different sample rates to the same GUI sink. 2015-08-02 14:25 GMT-03:00 Tom Rondeau <t...@trondeau.com>: > the qtgui sinks can only accept streams coming in at the same sample rate >From the user's point of view, these GUI blocks actually *do *accept streams with different sample rates, according to Gnuradio's idiosyncratic "sample rate gnosticism" of blocks (correct me if I'm wrong). It is left to the user to know how each block consumes and generate samples. I found helpful to think GUI blocks to consume from "one stream of tuples of n samples" instead from "samples from n streams" (is this true for all multiple-input blocks?). I never looked into the code to really understand how the scheduler deals with this situations, but I imagine two buffers' lengths diverging proportional to the sample rate mismatch leading to the filling of the fastest. I'm looking forward to GRCON15 to learn more in-depth some of these things. 2015-08-02 17:53 GMT-03:00 Kevin McQuiggin <mcqui...@sfu.ca>: > > > Kevin, > > > > Yes, the qtgui sinks can only accept streams coming in at the same > sample rate, and the repeat block would change that. Glad you figured it > out. I really thought that I had added that warning to the manual page, but > I don't see it in the published manual. I need to check on this and make > sure a warning about this is made in the docs. > > > > Tom > > > Hi Tom: > > Thanks for the information, that explains what I was seeing last night! > > Kevin > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
