Re: [FFADO-user] Echo AudioFire 4 stability issues

[Jonathan W. <jw...@ju...>]

Hi Brian

As others have said, the AudioFire 12 (AF12) requires firmware 4.8 for use
with FFADO.  I am not sure if the same requirement exists for the AF4
(AudioFire 4) [1] but I would assume so until tests prove otherwise.  If
firmware is an issue then FFADO will not get as far as starting the
streaming.  Thus if you see xruns in a particular firmware version then you
can conclude that FFADO is happy with that version of the firmware.

Firmware version 4.8 is prevalent when AudioFire (AF) devices are used with
FFADO.

On Feb 8, 2021, 20:23 -0500, Luke Tidd <luk...@gm...>, wrote:
> I'm using 2x AudioFire 12s and I think 256 or 512 was the lowest I
> could run them, but they were stable.

Without any system tuning these numbers would be about right.  To push the
latency lower one normally has to tune the system accordingly.  A "low
latency kernel" (aka PREEMPT) is a good first step but even this will only
get you so far.  In the past, aiming for buffer sizes of 16 or 32 required
the use of an RT-patched kernel.  These days the standard kernel includes
threaded IRQs in the PREEMPT kernel (although they aren't enabled by
default) which avoids the need for RT kernels in all but the most
challenging of situations.  When pushing things this low things become
highly dependent on your precise system configuration, and what works for
one person won't necessarily apply for the next.  It's very much a case of
experimentation.  Try things with a PREEMPT kernel, and maybe consider an RT
kernel if it appears necessary.

On Mon, Feb 8, 2021 at 5:19 PM Brian Hechinger <wo...@4a...> wrote:
> The error is always the same, unhandled xruns:
>
> ERROR: JackFFADODriver::ffado_driver_wait - unhandled xrun

This means one of two things:

 1. FFADO was not able to keep up with the incoming data stream from the
    device (capture overrun), or

 2. FFADO could not feed audio data to the device fast enough (playback
    underrun).

Usually (but not always) these can be addressed by careful tuning of the
system.

It should be noted that sometimes the problem is related to the firewire
card in use.  Your ffado-diag output reports you have a firewire host
controller based on the "XIO2213A/B/XIO2221" chip.  Thus it could be the
XIO2213A, the XIO2213B or the XIO2221.  I don't know much about the last one
as it's not overly common.  Of the other two, my understanding is that the
XIO2213B is a reasonable choice in this day and age.  It is also about the
only viable option since the best possible PCIe cards (using the Agere/LSI
FW643E cards) are very difficult to find[2].

The XIO2213A did have some hardware issues, although I don't know if they
might affect the ability to use the AF4 at the settings you are targetting. 
FFADO users have been able to use XIO2213A cards in the past, although
usually at more conservative settings (512 samples for example).

I am not aware of any specific issues with the XIO2213B chips and FFADO
users have reported success with them, but I don't think anyone's taken them
down to 16 or 32 sample buffers.

If possible it would be good if you could take a look at your Firewire host
controller card and identify the number on the main chip.  That way we at
least know for certain what hardware we are dealing with.

The posted ffado-diag output indicated that you are using a PREEMPT kernel,
which as noted above is a good first step.  You will however have to enable
threaded interrupts and utilise something like rtirq to prioritise
interrupts.  Perhaps the best description of this (along with a bunch of
information about additional details such as CPU frequency scaling) can be
found at

  https://wiki.linuxaudio.org/wiki/system_configuration

There is also some dated information at

  http://subversion.ffado.org/wiki/LatencyTuning
  http://subversion.ffado.org/wiki/IrqPriorities

which may never-the-less be useful.

I would recommend that you work first to obtain stable operation at more
modest latency settings (for example, 3 buffers, 512 samples per buffer). 
Once you have that working you can then start tuning the system for lower
latency knowing that all the basic details are working correctly.

Finally, if you decide to pursue support for the ALSA AudioFire driver at
some point please use the ALSA project mailing lists.  The ALSA drivers for
firewire devices are developed independently of the FFADO project.

Regards
  jonathan

[1] I have a vague recollection that the AF firmware issue affected mostly
    the AF12.  However, I don't have time right now to chase up the
    historical information to back this up.  The issue from memory related
    to a change in the way the AF device reported its capabilities.  Logic
    suggests that if the AF12 was affected then it's reasonable to expect
    the AF4 to be too.

[2] A great many sellers on the internet offer the StarTech PEX1394B3 card
    and claim in the specifications that it uses the FW643E chip.  However, 
    in every case I've pursued it turns out that the card in stock uses the
    XIO2213B chip.  It appears that there might have been an earlier version
    of the PEX1394B3 from StarTech which did use the FW643, but all current
    stock seems to be a later version with the XIO2213B instead.  Sellers
    seem generally unaware of the change which is why they continue to use
    the old specifications dating from when the cards they sold did have 
    the FW643 chip fitted.