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

[Brian H. <wo...@4a...>]

Bleh, USB. Good luck getting the same latency out of that.

I got the AF4 to specifically get away from USB audio (Native 
Instruments Komplete Audio 6 MK II) which will just be for the laptop 
from now on.

-brian

On 2/9/21 8:08 AM, matt henschel 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