Re: [Jack-Devel] ALSA PCM multi plugin and xruns

Hi John,

On Tue, Dec 11, 2012 at 8:28 AM, John Rigg <[hidden]> wrote:

> When jackd detected no xruns it produced this message repeatedly:
> snd_pcm_multi_avail_update: sync issue: 1025 1024
>
> When jackd detected xruns it produced this message:
> snd_pcm_multi_avail_update: sync issue: 1024 0
> There appeared to be two of these messages for every xrun
> indication.
>
> Does this make sense?

Yes, that makes sense.

I'm guessing that the first device in your .asoundrc uses internal
sync, and the second device listed in your .asoundrc is synced to the
first device via word clock.  If that's the case, then I'd like you to
try setting the 'master' device in your multi device to the second
card.  You can do this using the 'master' parameter in the pcm 'multi'
section of your .asoundrc:

    pcm.some_name {
        [... the parameters you already have]
        master 1;
    }

The multi device naively assumes that all of the cards that it's
aggregating are synced perfectly, and thus, the application that's
polling the cards needs to only check *one* card, which the multi
device calls the "master".  By default, that card is the first card
you list in your .asoundrc.

My (possibly incorrect) rationale for setting the master in this way
is that if only one card is going to be polled for events, then the
card that should be polled is that one that's going to be ready for
I/O last.  Above, you said that when xruns aren't happening, this
message is produced:

    snd_pcm_multi_avail_update: sync issue: 1025 1024

... which means that 1025 frames were available on the first card, and
1024 frames were available on the second card, and when xruns *are*
happening, this message is produced:

    snd_pcm_multi_avail_update: sync issue: 1024 0

... which means that 1024 frames were available on the first card, and
0 frames were available on the second card.

If the second card is always ready last, then polling the second card
*may* solve the issue.

In the long term, I don't think this is the best way to solve this
issue.  The multi device is inherently broken because of the
assumption that only one card needs to be polled.  I think a better
way to solve this problem would be to write a new JACK driver that
aggregates the cards itself (no multi device), and waits until I/O is
available on both cards.  I'm feeling pretty motivated and excited
about solving this problem, but I don't yet know when I'll have time
to do it.

-- 
Devin Anderson
surfacepatterns (at) gmail (dot) com

blog - http://surfacepatterns.blogspot.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/

1355249148.24939_0.ltw:2, <CAG7zqTqM7QrLNsUAGn340B0wXqQb31RUiFwW9=vE9d2zH-Ku-g at mail dot gmail dot com>