Ticket #304 (closed bug: fixed)

Opened 10 years ago

Last modified 8 years ago

FFADO can't restore stream status after multiple XRUNs

Reported by: gauss-gs Assigned to:
Priority: major Milestone:
Component: devices/fireworks Version: FFADO SVN (trunk)
Keywords: Cc:
The device the bug applies to: Echo AudioFire 2 and 4 maybe others

Description

My setup is:

  • Ubuntu 10.04 x86_64
  • Echo AudioFire?4 (firmware v4.08)
  • pulseaudio latest (from git, --disable-lirc);
  • jackmp latest (from svn, --debug --classic --firewire --alsa);
  • ffado latest(from svn, DEBUG=True);

Jackd started as: jackd -dfirewire -r48000 -p256 -n2 -v 9

This bug triggers on my setup while any player is playing music to the pulseaudio's jack sink and i've open my chrome browser. Jack shows xrun and often can't continue to work.

Logs of ffado-fireworks-downloader display, ffado-diag and jackd is in attach.

Attachments

jackmp.log.gz (0.6 MB) - added by gauss-gs on 09/11/10 13:11:50.
ffado-diag.log.gz (2.0 kB) - added by gauss-gs on 09/11/10 13:12:10.
audiofire_display.log (4.3 kB) - added by gauss-gs on 09/11/10 13:12:20.

Change History

09/11/10 13:11:50 changed by gauss-gs

  • attachment jackmp.log.gz added.

09/11/10 13:12:10 changed by gauss-gs

  • attachment ffado-diag.log.gz added.

09/11/10 13:12:20 changed by gauss-gs

  • attachment audiofire_display.log added.

09/11/10 13:32:25 changed by arnonym

  • status changed from new to closed.
  • resolution set to invalid.

Nothing strange here.

When debug is enabled and any -v > 2 is used, lots of debug output is produced. Even more in case of an xrun. This is definitely not meant for production use. Once your device is working, recompile with debug disabled. Or at least add -v1 or -v2 to your jackd command.

And maybe try -n3, that is better for bus systems like usb and firewire.

09/11/10 14:37:26 changed by gauss-gs

Maybe i've explained it wrong, sorry for my bad english.

I'm understand why i've got xruns and for what i've compiled everything in debug mode. This xruns leads to big problems: 100% cpu usage by jackd and often to sound interface freeze (bus reset, restarting jackmp and all other stuff doesn't bring sound back, only interface power-cycle does). Problem appears even with jackmp and ffado compiled with debug disabled.

09/12/10 07:38:33 changed by gauss-gs

  • status changed from closed to reopened.
  • summary changed from Strange problems with xrun handle? to FFADO can't restore stream status after multiple XRUNs.
  • resolution deleted.
  • device_name changed from Echo AudioFire 4 to Echo AudioFire 2 and 4 maybe others.

Thank you for -n3 suggestion, it now works much better.

I've figured out after many experiments with different settings that if many XRUNs successively appears in short period of time, the sound interface freezes with no chance to restore its streaming state. FFADO continuously tries to restore state and causes 100% cpu usage.

05/04/12 04:07:11 changed by jwoithe

I'm not sure there's anything to do here. From comment 3 it sounds like things are better for the reporter when debug is not enabled (as was suggested by Arnold in comment 1). The remaining problems may well be caused by other system configuration issues (shared interrupts, non-preemptable kernel, etc etc).

Due to the time elapsed since the original report, we would need the system to be re-tested with a recent FFADO subversion snapshot (and a new jackmp, either version 1.9.9 when it's released or from git) before further suggestions can be made. Can this be done easily?

Also, if the rest of the system configuration differs significantly from that at the time of the initial report, could you please also attach the current output of ffado-diag?

05/04/12 04:19:10 changed by jwoithe

A comment in ticket 264 suggests that the problem described here may be similar to that in #264. They are similar but I don't think they are identical. However, this may be due to me misunderstanding the above descriptions.

06/01/12 04:10:44 changed by jwoithe

  • status changed from reopened to closed.
  • resolution set to fixed.

There's been nothing further added over the past month, so I'll optimistically close this ticket for the moment as "fixed". There have been changes related to xrun recovery over the last two years which makes such recovery somewhat more reliable with particular devices. With the original report being two years old we really need a test with recent versions of the relevant software to determine whether the problem still exists. If re-testing demonstrates that the problem is still present this ticket can be re-opened.