Re: [FFADO-devel] Strange XRUN Issue...

[Euan de K. <eu...@de...>]

Thanks for the reply Johathan.

I have looked a bit further, and the messages I was seeing where coming
from the qjackctl application that is used to manage the jackd session. 

I had just assumed that qjackctl redirected the text from the jack
client directly to it's message output, but it actually attaches itself
to the jack callback functions and generates it's own messages.

As I am seeing "ProcessAsync: Read Error, skip cycle" messages when I
run jackd directly, and I get xruns in Ardour, so I suspect it is coming
from somewhere in:

int JackAudioDriver::ProcessAsync()
(common/JackAudioDriver.cpp)

which calls:

int JackFFADODriver::Read()
(linux/firewire/JackFFADODriver.cpp)

but I'll need to dig deeper.  

I am intrigued by the isochronous cycle also occurring every 128 seconds
and will need to research this more too.

Strangely though, this evening when starting jackd directly from the
command line, using an identical set of parameters that qjackctl is
configured to use I managed a two hour long recording session with
numerous stops, starts and recording and playback and I didn't get any
XRUNs or ProcessAsync messages - all at 96K.

I'll try some of the alternate versions of Jackd as suggested over the
next few days and post anything of interest that comes up.

Thanks,

Euan de Kock, Perth, WA, Australia.







On Wed, 2010-11-10 at 09:20 +1030, Jonathan Woithe wrote:

> Hi Euan
> 
> > Listed below is a full Jackd Session of just over an hour. Jackd is
> > running at 96K with my (slightly patched for the Echo bug #301) version
> > of FFADO fresh out the SVN (1922). Jackd is also jack2 out of the SVN
> > repos.
> > 
> > The earlier stuff was working with LMMS, and at around 22:41 I stopped
> > this, and started Ardour2. I recorded approximately 12 minutes of 8
> > track audio at 96K. During this time I keep getting an XRUN message
> > popping up (Ardout tags it in the record session (see attached picture)
> > 
> > The strange thing is I get this almost exactly every 2 minutes and 8
> > seconds - 128 seconds, regular as clockwork. It only appears to start
> > when I fire up Ardour, but continues after I have shutdown Ardour. From
> > "23:02:04.512 XRUN callback (9)." onwards I had nothing running against
> > jackd.
> 
> I can't immediately point to the cause, but I note that 128 seconds is the
> period of the firewire isochronous cycle timer.  However, if your xruns were
> related to this it's hard to see how starting ardour2 would suddenly cause
> this to be a problem.  If there was something funny going on with the cycle
> timer one would reasonably expect it to affect jackd/ffado from the time it
> is started, irrespective of the clients attached.
> 
> Perhaps the problem is always occuring but only ardour2 activates something
> in the jackd server which causes the message to be printed (and which
> persists after ardour2 has exitted).
> 
> Having a cursory glance at the jackd source I notice the existance of
> jack_set_xrun_callback() in libjack/client.c.  So I would say that ardour2
> calls this to set up an xrun callback which then gets fired off from that
> point on (although precisely how it persists after ardour2 exits is a
> mystery because this is a callback associated with a specific client).
> 
> > I don't even know where it is being generated - I cannot find
> > any reference to code that would print this message in the Jack or FFADO
> > code. I have killed just about everything I can and it still appears. I
> > suspect it's not actually an error as I don't appear to lose any data -
> > but I need to stop ardour recording at as one.
> 
> If this is something associated only with the wrapping of the iso cycle
> timer then the "xrun" detection is clearly a false detection.  In this case,
> if the above hypothesis is correct it would explain why no audio data is
> being lost.
> 
> This would then come down to identifying a reason why the wrapping of the
> cycle timer is causing a false xrun detection - the xrun code *should* be
> save against timestamp wrapping.  Maybe it's something specific with the way
> timestamps are handled in the echo driver.  If it were in the ffado core
> code I would have expected many other people to have noticed this by now.
> 
> Having said all that, I actually find it curious that the note of the XRUN
> callback is all you're seeing.  If ffado was flagging an xrun it would
> immediately attempt its xrun recovery process - something which causes an
> interruption to the audio data stream at the very least (and usually
> something would be logged about this too, but maybe that happens only at
> higher ffado verbose settings).  The fact that this does not seem to be
> happening would, at first glance, suggest that the xrun detection is not
> originating in ffado but is in fact occuring inside jackd.
> 
> I note you're using jack2.  It would probably be instructive if you could
> test this using plain jackd (that is, not jackd2) and see if that makes any
> difference.  If jackd1 svn still suffers from the problem maybe try the
> jackd 0.118 release since this has up to now behaved itself on my test
> systems.  These tests would at least give us some clue as to where the
> origin of this was.
> 
> Regards
>   jonathan