> > By default Gnu Radio now schedules each block in its own CPU thread. So > >> there could be >> differences in instantaneous latencies down each path. >> >> > Also- whether a data is processed at the same time in terms of physical > timeslices in the real world isn't so important, but by definition, > gnuradio should assure that samples in various block arrive in order to > the various things- so say in the simplest case you have a vector source > with [1, 0] in it, and you have two sink blocks connected to it, each > sink should receive 1,0,1,0 always. Make it more complicated, add a > const multiplier (*2) in one of the two paths- one sink should receive > 2,0,2,0... and the other should receive 1,0,1,0. My point is - in-order > processing and sample order preservation and arrival should be preserved > or half the DSP in done in gnuradio wouldn't be possible. The Scope sink > should be grabbing the same number of samples off each of the inputs on > each work pass, and if one path doesn't have enough available it should > stop short and not report consuming anything past the smallest available > number of samples on the inputs, and not render any data seen past the > shortest available. > > I'm not sure how the scope sink deals with the "minimum amount of data available" issue.
But the broader question becomes something like: given two (or more) subgraphs where the signals in the subgraphs had relative phase "foo" at the head of those sub-graphs, and the two (or more) subgraphs do different numbers and types of "things" to those signals, is relative phase preserved as seen by a sink object? It seems, on reflection, that unless those things *explicitly* modify phase, then phase should naturally be preserved. This is in stark contrast to the analog world, where there will be minor (or major!) phase-distortions as a result of following different paths. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
