Dear Mark,
On 09.10.2016 14:54, MarkO wrote: > > For this issue I've tried [Packet Encoder] and [Packet Decoder]. I'd say: don't. These blocks are pretty deprecated by now, being rather inflexible, slow python blocks. For now, try http://gnuradio.org/doc/doxygen/page_packet_data.html . > > With these blocks I get a noise-free connection if i downsample the audio > signal to 3 kHz, otherwise the data rate is to high for a stutter free > transmission - audio underruns (aU) occur. 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? > Now the problem is that I only receive parts of the audio signal. What i > hear is like: second 1, 5, 9, 15, 17, .. and it's not to fast, what i hear > are parts of the audio file in one consistent stream . The only solution i > found so far is to place a [Throttle] with 3kHz right before [Packet > Encoder]. 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. Of course, you'll here your output as one consistent stream: your GNU Radio flow graph is probably faster at producing samples from simulation than your audio sink is at consuming them (which happens at your audio sampling rate, e.g. 44.1 kHz or 48 kHz), so whenever the audio sink is done consuming the last sample of the first burst, GNU Radio has already calculated the output of the next burst. That's how it's supposed to work – 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". > This way I receive a nearly flawless stream. A few aU still come > up from time to time, i think this is because of the [Throttle] > implementation - usage of OS clock. Exactly! :) > > For details please check out the attached grc file: > QAM_audio_clean.grc > <http://gnuradio.4.n7.nabble.com/file/n61679/QAM_audio_clean.grc> > > I'm pretty sure that [throttle] isn't the correct solution. Is there a neat > way to solve this? > > Regards, > Markus Best regards, Marcus > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/mod-demod-issues-tp61674p61679.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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
