Hi Andreas, > Yes i remember a lot of such characters on the console. Is the sample > rate of the audio device to small ? in some way or another, yes. Explanation: A sound card consumes a fixed about of samples per second (e.g. 48,000), that we shall call f_sample,soundcard You need to supply these in time, and if you don't, your sound will be choppy and you'll see aU.
The fact that you're not doing that in time can have two reasons (actually three reasons[1]): 1) systematically: You take your RF samples from your SDR peripheral, and you process it, decimating it to a fixed rate of f_sample,RF < f_sample,soundcard. 2) computationally: although your theoretical flow graph does the right thing, ie. f_sample,RF / decimation == f_sample,soundcard, your computer can't process these samples in time, and your sound card has to wait for these samples. Since the real world time keeps running on, it can't produce sound. 3) real physics don't like anybody: both the sound card and your RF hardware have oscillators from which they generate their sampling rates; these oscillators will neither be perfect nor will they be coherent, so inevitably there will be some mismatch between the expected and actual sampling rates. However, these offsets tend to be small and would usually not lead to massive accumulations of audio underruns. So, since the same application works on a faster machine, I'd say it's 2). What you could check, though, is that the sampling rate you set in your audio sink is actually supported by the hardware, and try with different values (e.g. 44,100 Hz instead of 48,000, but that's about it when it comes to usual sampling rates), but you'd of course have to adjust your decimation between RF hardware and sound card accordingly. Greetings, Marcus [1] http://youtu.be/7WJXHY2OXGE?t=40 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
