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

[matt h. <hen...@ca...>]

4.8 is also required for both the AF8 and the AF8b (the latter also
has adat i/o).  I would presume the same applies for the pre8 and the
12.  Someone should fix that one of these years.

Glad to see I'm not the only one running them.  Had great luck as far
back as a pentium iv with 2gb ram.  Solid performers.  The AF12 is
especially sweet with the meter bridge and sample rate indicator right
on the front panel, and nothing else.  Nice and simple.

I have also had it working on numerous random firewire chipsets w/FFADO.

matt

On 2/8/21, Jonathan Woithe <jw...@ju...> wrote:
> 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.
>
>
> _______________________________________________
> FFADO-user mailing list
> FFA...@li...
> https://lists.sourceforge.net/lists/listinfo/ffado-user
>