<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.23588"></HEAD>
<BODY>
<DIV dir=ltr align=left>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial>Hi Alan,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial>Very interesting all! I agree with your comment about getting
in trouble if your requested PortAudio buffer size happens to be different from
the sound-device driver's buffer size. That forces PA to adapt between the
two buffer sizes causing the aperiodic behavior you mentioned below.
It's easy for a VAC1 user to get himself into that mess by choosing the wrong
value in the "Buffer Size" comboBox and making things sound bad. Passing
paFramesPerBufferUnspecified to PA (as in Thetis) solves that problem but
potentially creates another one by allowing PA to vary the buffer size from
callback-to-callback.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial>I recently found an interesting post in the PortAudio list
archives where Ross Bencina himself admitted to not using
paFramesPerBufferUnspecified when running pro-audio live sound gigs. He
just makes damn sure his buffer sizes match :-)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial>Thanks for your post - lots of food for thought
there.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=502321815-10062017><FONT color=#0000ff
face=Arial>73, Bryan W4WMT</FONT></SPAN></DIV></DIV><BR>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Hpsdr
[mailto:hpsdr-bounces@lists.openhpsdr.org] <B>On Behalf Of </B>Alan
Hopper<BR><B>Sent:</B> Saturday, June 10, 2017 9:35 AM<BR><B>To:</B>
hpsdr@openhpsdr.org<BR><B>Subject:</B> [hpsdr] Audio
resampler<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=ltr>
<P class=MsoNormal>Hi List<SPAN></SPAN></P>
<P class=MsoNormal><SPAN class=424004916-10062017><FONT color=#0000ff
face=Arial> <SNIP> </FONT></SPAN><BR></P>
<P class=MsoNormal>One pit I fell into was requesting a buffer size from
portaudio audio different to its preferred size, if the buffer requested is
smaller than the actual audio buffer size the portaudio callback is called in
bursts, this can cause a subtle error in reading the audio clock rate as the
thread producing the audio will statistically capture a clock reading more often
between bursts which will cause the filtered frequency to read high.�� Letting
Portaudio choose the buffer size fixed this.<SPAN></SPAN></P>
<P class=MsoNormal><FONT color=#0000ff face=Arial></FONT><BR></P>
<P class=MsoNormal>Before I solved this issue I had tried a number of ways of
filtering the very jittery clock data you get packet by packet including iir
filters, delay locked loop, Kalman, moving linear regression and moving average,
I suspect they all would have worked but as I happened to be using the moving
average at the point I fixed the above problem and it all started working, I
stuck with it.�� I���m currently moving this code from c# to c++ and shall go
back and re try the other options.<SPAN></SPAN></P>
<P class=MsoNormal><SPAN class=424004916-10062017></SPAN><FONT face=Arial><FONT
color=#0000ff><<SPAN
class=424004916-10062017> SNIP> </SPAN></FONT></FONT><BR></P>
<P class=MsoNormal><FONT color=#0000ff face=Arial></FONT><BR></P>
<P class=MsoNormal>73 Alan M0NNB<SPAN></SPAN></P></DIV></BODY></HTML>