20 Dec
2010
20 Dec
'10
8:14 a.m.
On Sat, Dec 18, 2010 at 03:19:14PM +0100, Jörn Nettingsmeier wrote:
On 12/16/2010 08:49 PM, Lee Azzarello wrote:
it will oscilate, but the oscilation will get slower and slower,
and its about 0.00001% so this is going to be pretty good.
but its not perfect.
there are a bit of scheduler uncerteinties, which might perturbate the
timebase.
if your interfaces are synced just use the pcm multi approach.
if you dont care for bit-transparency, and dont want to edit a config
file, use alsa_io.
the main purpose of alsa_io is jackd running with a jittery timebase.
and i prefer optimizing it at that end.
On Thu, Dec 16, 2010 at 1:36 PM, Lee Azzarello
<lee(a)rockingtiger.com> wrote:
torben, i wonder: will alsa_[in|out] be perfectly bit-transparent when
the two interfaces it bridges are externally synced, or will its
tracking algorithm keep oscillating around the correct samplerate? On Thu, Dec 16, 2010 at 6:58 AM, torbenh
<torbenh(a)gmx.de> wrote:
Great success! alsa_out on the second device exposes those two
additional channels to JACK and I can connect any application to them
without jackd printing messages about xrun callbacks. On Thu, Dec 16, 2010 at 08:02:29AM +0100, Luis
Garrido wrote:
> On Thu, Dec 16, 2010 at 4:21 AM, Lee Azzarello <lee(a)rockingtiger.com> wrote:
>> Hello, I'm looking for some advice for an interesting symptom of
>> putting my M-Audio Fast Track Pro USB sound card into ALSA multi mode.
>
> I have no idea what might be happening, but an alternative to use
> several alsa devices in jack would be the alsa_in and alsa_out
> utilities shipped with jack, perhaps that will give you less trouble?
hmm... the interesting thing is that he actually claims to not have
trouble. he only gets xrun callbacks. this is weird.
I'll test the alsa_(in|out) utilities later today.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn