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...
"You probably know that if you take two computers, and make them run an audio software, or a Jack server at a given sample rate, they are obviously not running exactly at the same sample rate. That is because they don't have exactly the same master clock. This is the greatest inconvenience that all the digital audio world has ever fought.
In the Netjack system, no problem of synchronization because the slave isn't running an audio hardware. It's simply led by a network stream. the incoming stream delivers 64 frames, for example, so the slave have to deal with those 64 frames, then send back 64 frames. There is no other time consideration than the master's cycle last. But if you want to make these 64 frames goes to an audio hardware, you will have to resample because the master's cycle duration will not fit to the new arbitrary slave's. Master and slave have no other way of syncing each other (except for hardware which includewordclock or some other kind of wired sync). 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:"
Sent from my iPad 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 todynamically set its fractional rate based on the buffer consumption ofthe sink. This is on my todo list for the JACK sink. I'm starting withthe JACK sink because the JACK API is the only one that providesdetailed info on buffer state. It's possible that ALSA also providesuseful information; it's hard to say because of the incomprehensibilityof the ALSA API. I haven't looked that hard.I'm not sure that most digital recording studio applications have thecapability of reading from one audio card and writing directly toanother. If they do, they must have some way of resampling data to matchsample 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 isvery close to what it's "supposed" to be; e.g., its 44100Hz is really44100Hz.
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 listaddress@hiddenhttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|