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

[Luke T. <luk...@gm...>]

True, I'll be sticking with these until I can't. I wish that behringer
had a clock sync and supported multiple cards. Also ports on the front
of the unit is a pet peeve, but I'll survive.

On Tue, Feb 9, 2021 at 8:09 AM matt henschel <hen...@ca...> wrote:
>
> 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
> >>
> >
>
>
> _______________________________________________
> 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