[Hackrf-dev] sources of audio underrun?

[Chuck McManis]

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> wrote:

> On Thu, Dec 22, 2016 at 1:24 AM, Chuck McManis <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/20161222/abf36eaa/attachment.html>