On 22 December 2016 at 20:41, Chuck McManis <[email protected]> wrote: > > The odd thing is that the aU's come in bursts, I would expect a pure timing problem to be a consistent pattern.
While I agree that it's intuitive for a mismatch in clocks to cause consistent underruns, the buffering of samples between blocks is probably what turns it in to a bursty problem. > On Thu, Dec 22, 2016 at 7:29 AM, Kevin Reid <[email protected]> wrote: >> >> On Thu, Dec 22, 2016 at 1:24 AM, Chuck McManis <[email protected]> wrote: >>> >>> Hi all, >>> >>> I'm building a more sophisticated FM receiver in grc and I find I'm getting regular audio underruns (aUaUaU ... ) they come in bursts. My CPU utilization is like 33 - 40% for 3 of the 4 cores, maybe 70% for the fourth one. What techniques can I use to avoid audio underruns? >> >> >> Underrun or overrun is inevitable, because there are two different hardware clocks involved with therefore different definitions of the passage of time: the HackRF's sampling clock and the audio device's sampling clock. (There was recently some discussion on the GNU Radio mailing list about developing a feature to handle this clock skew by adaptively resampling the audio, but that project has not even been started.) >> >> If CPU utilization were the problem, then you would also be seeing "O"s from the HackRF driver not being able to offload its samples into the flowgraph fast enough. I think. >> >> If you changed your demodulator design and are now getting more underrun/overrun than you used to, then you should look at your demodulator's sample rate conversions and check if you are doing something imprecise (e.g. rounding a non-integer ratio to an integer one). >> > > > _______________________________________________ > HackRF-dev mailing list > [email protected] > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev >
_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
