i think the one below is a better approach - it will only trace eventsthat the ALSA driver has reported to be an xrun. I.e. the full latencypath from the point where poll() is called, up to the point where jackd[after the latency has occured] considers it an xrun worthcounting/reporting. The tracing restarts at every poll(), so only the latency is captured. If you up your tracebuffer to 40K+ entries then i'd suggest to use the following trace settings:

i.e. dont use trace_freerunning - this will give much easier to parsetraces.

a suggestion wrt. the format of the .trc files: it would be nice if youcould dump the PIDs of all relevant tasks into it too, to make it easierto identify who causes what latency. Ideally it would be useful to have a more symbolic trace - i.e. instead of:

3570 00000000 254981.991ms (+0.000ms): up (ext3_orphan_del)

it would be:

jackd-3570 00000000 254981.991ms (+0.000ms): up (ext3_orphan_del)

but this is easier done in the kernel - some of the tasks involved in alatency might be long gone by the time you detect the xrun.