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

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

This looks like a potential replacement that is class compliant but I
see no reason to add perfectly great hardware to the landfill
https://www.sweetwater.com/store/detail/UMC1820--behringer-u-phoria-umc1820-usb-audio-interface

I picked up an "acer swift 7" that is FANLESS and has thunderbolt 3
ports.  Will try one of my AFs on it in the next few months under
windows 10.  Probably will not run ardour/gnu right off the top as I
managed to get a roland v700c working with 'cakewalk by bandlab'.
It'd be sweet with ardour though.

One of these years.....

On 2/9/21, matt henschel <hen...@ca...> wrote:
> I can't remember the specific combination as I have been migrating my
> foundation to TASCAM DTRS but I do recall pulling 2ms latency out of a
> trashpicked laptop and an echo AF.
>
> such beautiful stuff.
>
> preachin to the choir
>
> On 2/9/21, Luke Tidd <luk...@gm...> wrote:
>> The audiofire's have been the center of my studio for years. I even
>> have a dedicated WinXP box tucked into a corner should I need the
>> official drivers or software to change settings. Not sure where I'd
>> move after these.
>> https://photos.app.goo.gl/bUE37L7nAeY2ANYK9
>>
>> On Tue, Feb 9, 2021 at 4:34 AM matt henschel <hen...@ca...>
>> wrote:
>>>
>>> 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
>>> >
>>>
>>>
>>> _______________________________________________
>>> FFADO-user mailing list
>>> FFA...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ffado-user
>>
>>
>>
>> --
>> Luke Tidd
>> Google
>> 7055 Pleasant Dr
>> Austell, GA 30168
>> 404-939-0306
>>
>