[Hackrf-dev] sources of audio underrun?

[Patrick Sathyanathan]

Hi Chuck,


I've had this problem too. I fixed it by generating the audio samples from your demodulator at a slightly higher rate than that the audio sink is set to. So for instance I would generate audio at 49KHz and set the audio sink rate to 48KHz. This fixed the problem for me. You may have to experiment with slightly different values to find one that works for you.


--Patrick


________________________________
From: HackRF-dev <hackrf-dev-bounces at greatscottgadgets.com> on behalf of Chuck McManis <chuck.mcmanis at gmail.com>
Sent: Thursday, December 22, 2016 12:41 PM
To: Kevin Reid
Cc: Hackrf-dev
Subject: Re: [Hackrf-dev] sources of audio underrun?

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 <kpreid at switchb.org<mailto:kpreid at switchb.org>> wrote:
On Thu, Dec 22, 2016 at 1:24 AM, Chuck McManis <chuck.mcmanis at gmail.com<mailto:chuck.mcmanis at gmail.com>> 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).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20161224/83784a49/attachment.html>