12 Apr
2016
12 Apr
'16
5:29 a.m.
Hi,
thanks for the quick and sound response.
On Tue, 12 Apr 2016, Jörn Nettingsmeier wrote:
Just because I'm, familiar
with it. I'm not sure what to replace it
with, jack.play, jack.record?
Yes I think it's just clocks drift.
I did jack_unload/jack_load and got the channels back (almost) in synch.
On 04/12/2016 10:42 AM, mdrslmr wrote:
We use a script starting:
aplay -q -D $channel Test-Ton.wav &
arecord -q -D $channel -f S16_LE -r 48000 -c 1 -d 8 $result/recorded.wav
Why are you using alsa tools when you are otherwise working with JACK? This
will make the problem analysis more complicated... The resulting wav file shows that the time
between the start of the
recording
and the start of the actual sound continuously increases.
In the beginning (after starting the system up) the time difference is
just about 3ms. It increases
constantly to almost one second now
after 8 weeks of uptime.
If audioadapter works by just providing a big buffer (without any
resampling), the reason would be clock drift. Such a minuscule clock drift
between two consumer cards however would be sensationally good.
First of all, consider if you can actually sync the cards. If both have an
SPDIF i/o, you can use that. Just connect the secondary card's SPDIF in to
the master's SPDIF out (no matter whether you use toslink or RCA), and you
can be sure your cards will be locked.
Our cards M-Audio Delta44 don't have SPDIF ports.
Secondly, try zita-ajbridge. If you can sync the cards in hardware, there is
an option for zita-ajbridge to skip the resampling, which will conserve cpu
power.
I'll check it out.
Cheers,
Michael