[Hackrf-dev] sources of audio underrun?
Dominic Spill
dominicgs at gmail.com
Fri Dec 23 11:24:38 EST 2016
On 22 December 2016 at 20:41, Chuck McManis <chuck.mcmanis at gmail.com> 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 <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).
>>
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20161223/7198e139/attachment.html>
More information about the HackRF-dev
mailing list