John Rigg | 11 Dec 17:28 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Sun, Dec 09, 2012 at 05:03:57PM -0800, Devin Anderson wrote:
> On Sun, Dec 9, 2012 at 6:46 AM, John Rigg wrote:
> > What code did you add to display the extra messages?
> I added:
> 
> 	if ((ret != LONG_MAX) && (ret != avail)) {
> 		fprintf(stderr, "snd_pcm_multi_avail_update: sync issue: %d %d\n",
> ret, avail);
> 	}
> 
> ... to the function `snd_pcm_multi_avail_update` in
> src/pcm/pcm_multi.c of the alsa-lib package.  I added the code just
> below:
> 
> 	if (avail < 0) {
> 		return avail;
> 	}
> 
> It should print data to the console when there is a difference between
> the number of frames available from one card and the number of frames
> available from another card.

I added the above code to pcm_multi.c (in alsa-lib-1.0.26)
then ran jackd using the following command:

jackd -d alsa -C capture16 -P playback16 -r 44100

where capture16 and playback16 are the pcm_multi devices in my .asoundrc.
This was with two ice1712 cards, with default period size of 1024.

(Continue reading)

Devin Anderson | 11 Dec 19:05 2012
Picon

Re: ALSA PCM multi plugin and xruns

Hi John,

On Tue, Dec 11, 2012 at 8:28 AM, John Rigg <j <at> jrigg.co.uk> 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
(Continue reading)

Paul Davis | 11 Dec 19:15 2012

Re: ALSA PCM multi plugin and xruns




On Tue, Dec 11, 2012 at 1:05 PM, Devin Anderson <surfacepatterns <at> gmail.com> wrote:


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.

jackd  [ ... args ... ] -d alsa -d hw:FIRST &
alsa_in [ ... args ] -d hw:SECOND &
alsa_out [ ... args ] -d hw:SECOND &

[ .. repeat as needed]

much more general than your brief summary, since alsa_in/alsa_out will resample as necessary, thus not requiring that the devices share a sample clock.

there are also fons' version of alsa_in/out, which some people feel do an even better job with the resampling and more.

now of course, if the devices are synced then none of this would be necessary. if they are synced and ALSA gets things things wrong, the ALSA needs fixing.

--p

_______________________________________________
Jack-Devel mailing list
Jack-Devel <at> lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Devin Anderson | 11 Dec 19:22 2012
Picon

Re: ALSA PCM multi plugin and xruns

Hi Paul,

On Tue, Dec 11, 2012 at 10:15 AM, Paul Davis <paul <at> linuxaudiosystems.com> wrote:

>> 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.
>
>
> jackd  [ ... args ... ] -d alsa -d hw:FIRST &
> alsa_in [ ... args ] -d hw:SECOND &
> alsa_out [ ... args ] -d hw:SECOND &
>
> [ .. repeat as needed]
>
> much more general than your brief summary, since alsa_in/alsa_out will
> resample as necessary, thus not requiring that the devices share a sample
> clock.

It's my understanding that `alsa_in` and `alsa_out` add some latency,
which means that sound card that JACK is synced to and the sound card
that the alsa-in/out clients use aren't quite in sync.

> now of course, if the devices are synced then none of this would be
> necessary. if they are synced and ALSA gets things things wrong, the ALSA
> needs fixing.

What about cases where the word clock sync of a sound card isn't quite
as tight as it should be?  Does ALSA have control over that?

--

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

blog - http://surfacepatterns.blogspot.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
Paul Davis | 11 Dec 19:25 2012

Re: ALSA PCM multi plugin and xruns




On Tue, Dec 11, 2012 at 1:22 PM, Devin Anderson <surfacepatterns <at> gmail.com> wrote:

It's my understanding that `alsa_in` and `alsa_out` add some latency,
which means that sound card that JACK is synced to and the sound card
that the alsa-in/out clients use aren't quite in sync.

i'd want torben to comment on that. i;m not sure. maybe fons can comment too on his similar utiltiies?
 

> now of course, if the devices are synced then none of this would be
> necessary. if they are synced and ALSA gets things things wrong, the ALSA
> needs fixing.

What about cases where the word clock sync of a sound card isn't quite
as tight as it should be?  Does ALSA have control over that?

my understanding is that word clock sync is all-or-nothing. you're either precisely in sync or not at all.
_______________________________________________
Jack-Devel mailing list
Jack-Devel <at> lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Florian Faber | 11 Dec 19:29 2012
Picon

Re: ALSA PCM multi plugin and xruns

On 12/11/12 19:25, Paul Davis wrote:

>     What about cases where the word clock sync of a sound card isn't quite
>     as tight as it should be?  Does ALSA have control over that?
> my understanding is that word clock sync is all-or-nothing. you're
> either precisely in sync or not at all.

Yes. In addition you want the card's buffers to be synchronous, so there
is no 'card that is ready for I/O last' and you have no nasty alignment
problems.

Flo
--

-- 
Machines can do the work, so people have time to think.
public key B3B9226C
Devin Anderson | 11 Dec 19:56 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Tue, Dec 11, 2012 at 10:25 AM, Paul Davis <paul <at> linuxaudiosystems.com> wrote:
>
> On Tue, Dec 11, 2012 at 1:22 PM, Devin Anderson <surfacepatterns <at> gmail.com>
> wrote:
>> What about cases where the word clock sync of a sound card isn't quite
>> as tight as it should be?  Does ALSA have control over that?
>
> my understanding is that word clock sync is all-or-nothing. you're either
> precisely in sync or not at all.

Hmmm.

Do you know offhand if `snd_pcm_link()` is supposed to synchronize the
poll file descriptors such that the poll file descriptors of the
master aren't set with events until both the master card and the card
it's linked to are ready with I/O?  If so, then the bug is probably
there somewhere.  If not, then I wonder how this synchronization is
supposed to happen.

--

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

blog - http://surfacepatterns.blogspot.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
John Rigg | 11 Dec 21:52 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Tue, Dec 11, 2012 at 10:56:30AM -0800, Devin Anderson wrote:
> On Tue, Dec 11, 2012 at 10:25 AM, Paul Davis <paul <at> linuxaudiosystems.com> wrote:
> >
> > On Tue, Dec 11, 2012 at 1:22 PM, Devin Anderson <surfacepatterns <at> gmail.com>
> > wrote:
> >> What about cases where the word clock sync of a sound card isn't quite
> >> as tight as it should be?  Does ALSA have control over that?
> >
> > my understanding is that word clock sync is all-or-nothing. you're either
> > precisely in sync or not at all.

Yes. Sync is achieved by using a phase-locked loop (PLL). It's either locked
completely or not at all. The PLL typically runs at 128 or 256 x fs, so
even if it takes a few tens of cycles to lock after startup, it synchronises
pretty quickly compared with the word clock period.

> Do you know offhand if `snd_pcm_link()` is supposed to synchronize the
> poll file descriptors such that the poll file descriptors of the
> master aren't set with events until both the master card and the card
> it's linked to are ready with I/O?  If so, then the bug is probably
> there somewhere.  If not, then I wonder how this synchronization is
> supposed to happen.

IIRC the link code didn't appear in early versions of pcm_multi and
was only added in alsa-lib-1.0.9rc1 (Jan 2005). It broke duplex operation
with pcm_multi. I commented it out for months to work around it on my own
systems. Eventually a change was made in JACK to make it work again. Some
info can be found here if interested:
http://search.gmane.org/?query=pcm_multi&group=gmane.linux.alsa.devel

John
John Rigg | 11 Dec 22:05 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Tue, Dec 11, 2012 at 08:52:56PM +0000, John Rigg wrote:
> Yes. Sync is achieved by using a phase-locked loop (PLL). It's either locked
> completely or not at all. The PLL typically runs at 128 or 256 x fs, so
> even if it takes a few tens of cycles to lock after startup, it synchronises
> pretty quickly compared with the word clock period.

Correction: time taken to achieve lock can be significantly longer than the
word clock period (my PLL theory is a little rusty). On a system where
all cards are driven by a common clock this shouldn't be an issue,
but it still doesn't cure the problem being discussed.

John
Arnold Krille | 12 Dec 00:49 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Tue, 11 Dec 2012 21:05:39 +0000 John Rigg <j <at> jrigg.co.uk> wrote:
> On Tue, Dec 11, 2012 at 08:52:56PM +0000, John Rigg wrote:
> > Yes. Sync is achieved by using a phase-locked loop (PLL). It's
> > either locked completely or not at all. The PLL typically runs at
> > 128 or 256 x fs, so even if it takes a few tens of cycles to lock
> > after startup, it synchronises pretty quickly compared with the
> > word clock period.
> Correction: time taken to achieve lock can be significantly longer
> than the word clock period (my PLL theory is a little rusty). On a
> system where all cards are driven by a common clock this shouldn't be
> an issue, but it still doesn't cure the problem being discussed.

Its even the other way around: The PLL has to adopt to changes rather
slowly. Otherwise the smallest jitter in the word-clock would make your
PLL run wild. But a slow PLL calls for a long time to sync.

Have fun,

Arnold
_______________________________________________
Jack-Devel mailing list
Jack-Devel <at> lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
John Rigg | 12 Dec 09:15 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Wed, Dec 12, 2012 at 12:49:37AM +0100, Arnold Krille wrote:
> On Tue, 11 Dec 2012 21:05:39 +0000 John Rigg wrote:
> > On Tue, Dec 11, 2012 at 08:52:56PM +0000, John Rigg wrote:
> > > Yes. Sync is achieved by using a phase-locked loop (PLL). It's
> > > either locked completely or not at all. The PLL typically runs at
> > > 128 or 256 x fs, so even if it takes a few tens of cycles to lock
> > > after startup, it synchronises pretty quickly compared with the
> > > word clock period.
> > Correction: time taken to achieve lock can be significantly longer
> > than the word clock period (my PLL theory is a little rusty). On a
> > system where all cards are driven by a common clock this shouldn't be
> > an issue, but it still doesn't cure the problem being discussed.
> 
> Its even the other way around: The PLL has to adopt to changes rather
> slowly. Otherwise the smallest jitter in the word-clock would make your
> PLL run wild. But a slow PLL calls for a long time to sync.

Yes, I was obviously sleep-deprived when I made that comment about
PLLs locking quickly. In high quality audio interfaces it's common
to use two PLL stages, one to lock to the incoming clock and a
second one (often a VCXO) for jitter attenuation.

John
Devin Anderson | 12 Dec 06:21 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Tue, Dec 11, 2012 at 10:56 AM, Devin Anderson
<surfacepatterns <at> gmail.com> wrote:

> Do you know offhand if `snd_pcm_link()` is supposed to synchronize the
> poll file descriptors such that the poll file descriptors of the
> master aren't set with events until both the master card and the card
> it's linked to are ready with I/O?  If so, then the bug is probably
> there somewhere.  If not, then I wonder how this synchronization is
> supposed to happen.

AFAICT, start, stop, drain, pause, suspend, resume, reset, and prepare
operations are all synchronized in the kernel via `snd_pcm_link()`;
however, I can't find any evidence that `snd_pcm_link()` (or any other
ALSA API call, for that matter) will make the poll operation for a
master device wait for I/O availability on its linked slave devices.

So, I guess the next questions are:

1.) Should `snd_pcm_link` make the poll operation of a master device
wait for I/O availability on its linked slave devices?  Why or why
not?
2.) Should ALSA handle this operation at all?  Why or why not?

I guess the answer to (1) is dependent on whether or not there is a
reason to sync start, stop, drain, etc. without syncing poll
descriptors.

Given that ALSA has configuration options for a multi device, I would
guess that at least one ALSA developer thought the answer to (2) was
"yes".  I'd be inclined to answer "yes", as this seems like a useful
operation, and doesn't seem like an operation that should be
re-invented by any userspace application that wants to sync multiple
sound cards.

I guess this is getting a bit off-topic.  Perhaps this discussion
should be moved to the ALSA developers list.

--

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

blog - http://surfacepatterns.blogspot.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
Jörn Nettingsmeier | 12 Dec 09:23 2012
Picon

Re: ALSA PCM multi plugin and xruns

On 12/12/2012 06:21 AM, Devin Anderson wrote:

> I guess this is getting a bit off-topic.  Perhaps this discussion
> should be moved to the ALSA developers list.

if you do, please keep this list posted as well - i think it's a highly 
relevant issue for JACK development on linux.

--

-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net
Jörn Nettingsmeier | 11 Dec 19:25 2012
Picon

Re: ALSA PCM multi plugin and xruns

On 12/11/2012 07:15 PM, Paul Davis wrote:
>
> jackd  [ ... args ... ] -d alsa -d hw:FIRST &
> alsa_in [ ... args ] -d hw:SECOND &
> alsa_out [ ... args ] -d hw:SECOND &
>
> [ .. repeat as needed]
>
> much more general than your brief summary, since alsa_in/alsa_out will
> resample as necessary, thus not requiring that the devices share a
> sample clock.
>
> there are also fons' version of alsa_in/out, which some people feel do
> an even better job with the resampling and more.
>
> now of course, if the devices are synced then none of this would be
> necessary. if they are synced and ALSA gets things things wrong, the
> ALSA needs fixing.

ho-humm. for years, we all have been telling newbies in a more or less 
friendly way that cascading non-hardware-synced consumer gear to obtain 
cheap multichannel devices is evil. now that the word has spread and 
people try to do things the proper way, all of a sudden everybody 
advocates resampling. it's a great quick-and-dirty solution iff you can 
spare the cycles and don't care for bit-transparency, but in a 
professional context with synced hardware, it is an abomination. shame 
on you mr davis :)

don't get me wrong, i love alsa_in/out and zita-ajbridge for what they 
do, but they are a band aid for very specific use cases (notably, to get 
local i/o for _monitoring purposes_ on a netjack slave). putting them in 
the signal path for the final product isn't to be undertaken lightly.

so yes, alsa needs fixing.

--

-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net
Jörn Nettingsmeier | 11 Dec 19:19 2012
Picon

Re: ALSA PCM multi plugin and xruns

On 12/11/2012 07:05 PM, Devin Anderson wrote:

> 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.

interesting hypothesis! unfortunately, i seem to have hardware problems 
with my (quite ancient) RME DIGI 9652 in that i can't even get it to run 
on its own anymore, so i can't test it right now, but it sounds promising.

it would be very nice to have this feature supported and rock-solid, not 
the least because migrating mac users have come to expect such things to 
just work.

--

-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net
John Rigg | 11 Dec 19:56 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Tue, Dec 11, 2012 at 10:05:40AM -0800, Devin Anderson wrote:
> Hi John,
> 
> On Tue, Dec 11, 2012 at 8:28 AM, John Rigg <j <at> jrigg.co.uk> 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 second card is synced to the first via S/PDIF. My .asoundrc
doesn't contain a master parameter, but does have

ctl.capture16{
	type hw
	card 0
}

and a similar entry for the playback device. The ice1712 chip has 12
inputs and 10 outputs, so separate capture and playback devices have
to be configured. My full .asoundrc is shown here:
http://www.jrigg.co.uk/linuxaudio/ice1712multi.html

I just tried changing the ctl parameters to use card 1 and the messages
from pcm_multi are the same as before. BTW on my main system with
3 x ice1712 cards there's a common clock supplying all three cards
simultaneously. It also shows the same xrun messages from jackd when
using pcm_multi. It would be interesting to see what the extra fprintfs
in pcm_multi.c would show on that system.

John
Chris Caudle | 11 Dec 19:56 2012

Re: ALSA PCM multi plugin and xruns

On Tue, December 11, 2012 12:25 pm, Paul Davis wrote:
> my understanding is that word clock sync is all-or-nothing. you're
either
> precisely in sync or not at all.

I would think absolute worst case would be two different model cards, and
there is some ambiguity about when relative to the clock edge the sample
is available.  That should result in at most a +/- 1 sample difference
between the buffers of the two cards at any particular time, not multiple
periods difference.

Is the difference seen when the event occurs a 1 period difference, or
multiple periods?  Could it be as simple as the second card not flagging
the period of data as available until the last frame is latched, and there
being some fraction of a sample clock difference between when the first
card flags a period is ready and when the second card flags a period  is
ready?
I would have guessed that just the latency in servicing the interrupt
would have allowed the second card time to catch up, but maybe the current
processors are so fast that when the first card interrupts, the first card
and second card can be checked and the lack of data ready in the second
card flagged before the second card has had time to catch up.  That
difference between cards, if it exists, should be on the order of some
fraction of the 20 microsecond sample period.

Probably  not a useful line of investigation, unless it can be reconciled
with the later message from John Riggs:
> BTW on my main system with 3 x ice1712 cards there's a
> common clock supplying all three cards simultaneously.
> It also shows the same xrun messages from jackd when
> using pcm_multi.

My understanding of John's system is that he has three identical cards,
and has physically modified the hardware so that they all operate from a
single oscillator feeding the ice1712 chips on the cards.  I don't see how
it could apply to that system.  Possibly there is an ambiguity in that
case with startup because of differences in reset timing to the individual
cards, in which case the cards would be locked in frequency, but might
have a fixed offset in the number of frames in the buffers at any
particular time.

If that is the case, then the proper solution would be for ALSA to check
the status of each card that is part of the multi device, and not flag the
multi device as ready for the next read or write until all of the physical
devices are ready.  AND instead of OR.

--

-- 
Chris Caudle
John Rigg | 11 Dec 20:37 2012
Picon

Re: ALSA PCM multi plugin and xruns

On Tue, Dec 11, 2012 at 12:56:04PM -0600, Chris Caudle wrote:
> Probably  not a useful line of investigation, unless it can be reconciled
> with the later message from John Riggs:
> > BTW on my main system with 3 x ice1712 cards there's a
> > common clock supplying all three cards simultaneously.
> > It also shows the same xrun messages from jackd when
> > using pcm_multi.
> 
> My understanding of John's system is that he has three identical cards,
> and has physically modified the hardware so that they all operate from a
> single oscillator feeding the ice1712 chips on the cards.

Yes, description here:
http://www.jrigg.co.uk/elec/interface.html

> I don't see how
> it could apply to that system.  Possibly there is an ambiguity in that
> case with startup because of differences in reset timing to the individual
> cards, in which case the cards would be locked in frequency, but might
> have a fixed offset in the number of frames in the buffers at any
> particular time.

Interesting point.

John
Chris Caudle | 12 Dec 16:39 2012

Re: ALSA PCM multi plugin and xruns

On Tue, December 11, 2012 11:21 pm, Devin Anderson wrote:
> I guess this is getting a bit off-topic.  Perhaps this discussion
> should be moved to the ALSA developers list.

I guess that depends on how confident you are that the ALSA snd_pcm_link()
implementation is the root of the JACK messages seen.

Is there any way to highlight the issue using native ALSA access?  I
haven't worked with the ALSA devs  before, I was thinking it might be
easier to get them interested in incorporating a change into upstream if
there was some way other than installing JACK and JACK aware applications
to make the problem show up.  If you just submit a patch and say this
change is needed, are the ALSA developers pretty good about accepting
patches without letting them sit around unmerged for a long time?

--

-- 
Chris Caudle

Gmane