On 01/09/2021 03:50 PM, Barry Duggan via USRP-users wrote:
Hi Ron,
Thank you for your test flowgraph. It works fine when using the wav
file, BUT when I change to an Audio Source block (mic) I get the
underruns. So I still have the problem. I've experimented with various
sizes of 'send_buff_size' and I even put in a Fractional Resampler to
raise the interpolation factor above the theoretical value.
I am now running on Ubuntu 20.04 and GRC 3.8.2.0
Any further suggestions?
Thanks,
Barry Duggan KV4FV
---
On Tue Jan 5 20:33:24 EST 2021, Ron Economos wrote:
Here's an ssb flow graph that's known to work. You can select the
sideband with the default option of the QT GUI Chooser block before you
start the flow graph (you can't change filter taps on the fly).
The test file is here.
http://www.w6rz.net/ssbaudio.wav
Ron
On 1/5/21 15:29, Barry Duggan via USRP-users wrote:
> Ubuntu 20.10
> GRC 3.9.0.RC0
> UHD 4.0
> B200mini
> USRP_ssb_xmt.grc - https://pastebin.com/ypyERUGE
>
> I have experimented with various combinations of send_buff_size and
> send_frame_size but continue to get underruns while transmitting. I've
> also tried setting the Audio Source 'OK to Block' to 'Yes' and to
> 'No'. What is the right combination of parameters to minimize or
> eliminate the underruns?
>
> Thanks for your help!
>
> 73,
> ---
> Barry Duggan KV4FV
> https://github.com/duggabe
>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
You're probably running into the "two clock" problem. Without any kind
of "smart" elastic buffer between two pieces of hardware with
different clocks, this problem is *guaranteed* to occur at some point.
Further, things like pulseaudio will sometimes (in my experience) only
do a half-hearted job of sample-rate conversion for audiohardware that
doesn't support the requested sample rate, which means that samples
aren't actually being delivered at close-enough to the requested rate
to "survive" the rigors of the two-clock problem.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
