Re: [Discuss-gnuradio] More on latency

[Nick Foster]

On Thu, 2010-10-21 at 15:48 -0400, Davek wrote:
> Jack, what a nightmare. I user it to send audio from my ubuntu server
> to macbook. Used ssh to access gui. According to the docs this is how
> they deal with sync. 2 soundcards...
> 
> 
> http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack2
> 
> 
<snip>
> 
> Netjack2 includes a system allowing to resample the network stream to
> send it on a piece of audio hardware. This is done using an in server
> client called audioadapter. After the slave has been started using the
> net backend, load the audioadapter client using jack_load:"

Yes, it may be possible to use the alsa_out plugin for JACK as a quick
fix to handle dynamic resampling. This plugin is now built into JACK by
default.

It would be most useful to replicate this functionality in our own JACK
sink and do the resampling using GR's own resampling blocks. We could
potentially replicate that solution for the native ALSA driver, which
most users seem to use. Since alsa_out uses native ALSA calls to
determine buffer fill state, this should be possible, although far from
straightforward.

--n

> 
> 
> 
> Sent from my iPad
> 
> On Oct 21, 2010, at 1:46 PM, Nick Foster <address@hidden> wrote:
> 
> 
> 
> > On Thu, 2010-10-21 at 13:11 -0400, Marcus D. Leech wrote:
> > > On 10/21/2010 11:41 AM, Eric Blossom wrote:
> > > > 
> > > > Yes, that would cause it.  I've seen it with the FM receiver
> > > > apps.
> > > > 
> > > Any hint about how to "cure" this problem?  I'm perfectly willing
> > > to
> > > have the audio sink drop samples
> > >  from time to time in order to prevent/dramatically-reduce buffer
> > > creep.
> > > 
> > > How do Linux audio apps deal with this in "digital recording
> > > studio"
> > > cases?  Where they may have audio inputs/outputs
> > >  from/to different cards, with unsynchronized clocks, etc?
> > 
> > The cure is to provide a resampling block inside the sink, and to
> > dynamically set its fractional rate based on the buffer consumption
> > of
> > the sink. This is on my todo list for the JACK sink. I'm starting
> > with
> > the JACK sink because the JACK API is the only one that provides
> > detailed info on buffer state. It's possible that ALSA also provides
> > useful information; it's hard to say because of the
> > incomprehensibility
> > of the ALSA API. I haven't looked that hard.
> > 
> > I'm not sure that most digital recording studio applications have
> > the
> > capability of reading from one audio card and writing directly to
> > another. If they do, they must have some way of resampling data to
> > match
> > sample rates.
> > 
> > > I have *another* GNURadio app, which uses an audio input and an
> > > audio
> > > output, on different cards.  It has been running for
> > >  several days,  and the latency is roughly 1sec.  The machine it
> > > is
> > > running on is a Pentium D dual-core, at 2.4/3.2GHz.  Probably
> > >  30% more "ooomph" than the D-510 that is running the other app.
> > > 
> > > Btw, I started the app on the D-510 and let it run overnight.  The
> > > latency this morning is roughly the same as it was last night
> > >  when I started it--about 1 to 1.5second.  So, I wonder what the
> > > condition is that causes buffer creep to become really large?
> > 
> > Hard to say. It could be that on that machine the audio card's clock
> > is
> > very close to what it's "supposed" to be; e.g., its 44100Hz is
> > really
> > 44100Hz.
> > 
> > > 
> > > 
> > > > BTW, it would have been useful to tell us that there was an
> > > > audio sink
> > > > in the graph when you first posted the observation.
> > > > 
> > > > 
> > > Actually, in the first instance, a few days ago, I did.  It was an
> > > oversight in this most recent post series. Sorry.
> > > 
> > > 
> > > > Thanks,
> > > > Eric
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >