Thanks Kevin, The note about not seeing 'O's is particularly useful. The odd thing is that the aU's come in bursts, I would expect a pure timing problem to be a consistent pattern. But the sample rates comment is well taken, there are parts of the flow graph in the audio domain and parts in the frequency domain so there clearly a lot of clocks flying around.
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
