Dear Marcus, thanks for your response. Marcus Müller-3 wrote > That sounds like a unrelated thing; aU's typically happen when you have > two clocks in your system, for example, one SDR device's sampling clock > and a soundcard sampling clock, as those never align perfectly, and one > can drift away from each other, or if you actually made a mistake > somewhere and the rate conversions between signal source hardware and > signal sink hardware don't actually result in the sink's clock rate. > You're not using a throttle block together with an audio sink, are you? > > The console output will tell you that using throttle + audio sink = > evil. Throttle must never be used with hardware that has its own sample > clock.
Yes, I also tested the audio stream with a throttle block and I understand the problem with [throttle] + hardware, but as you said: Marcus Müller-3 wrote > GNU Radio's job is to process samples as fast as it can; it > doesn't care, or even know, about how fast these samples should occur > related to "real world time". That can be a problem in some cases, but probably only for me because I don't understand something essential.. The only blocking element is the [audio sink] in "blocking mode" (of course). If i start an audio flow graph without [throttle] and increase some additive noise or change the volume with a multiplier in the stream the audible signal gets effected way too slow (action-to-effect-time approximately 10 s or more). If I use a [throttle] after the [wav file source] i can effect the stream directly - maybe i can call it "in real time", but then sometimes aU occurs. The issue remains also if i use real hardware (redpitaya with osmocom blocks) an resampler blocks in the stream. So is the solution for such problems a tagged stream with control through tags or the usage of PDUs? Regards, Markus -- View this message in context: http://gnuradio.4.n7.nabble.com/mod-demod-issues-tp61674p61811.html Sent from the GnuRadio mailing list archive at Nabble.com. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
