Topic: UFX II - FiFo Errors after exhaustive system work. Please help

GENERAL DESCRIPTION

Per the subject of this topic, I have experienced persistent and difficult-to-diagnose FiFo errors, which result in the UFX II entering a state of glitching.  The specific character of the glitch is a gapping of playback accompanied by a loss of timing sync that manifests system wide (for instance, playback timing of video files slows).  In Pro Tools 12.8.2 this manifests initially as what I interpret from the USB Diagnosis as incrementing "drops," numbering up usually to a few hundred, before eventually entering the gapping-state and displaying the FiFo Error.  At this point, the system wide timing becomes corrupt as I described earlier.

Because Pro Tools is coded in a way that restarting the UFX II results in system failure, the session must be restarted.  However, once the problem has occurred, in most cases the destabilization seems to linger on some level of the system.  On occasion, a power down/up of the UFX II allows work to continue.

The problem happens regardless of system load, but happens more severely and quickly in a PT Session with higher loads touching more subsystems.  My work currently requires that the Avid Video Engine is instantiated.

I will give system specs next, and detail the diagnostic steps I have taken to date.  Both Jeff and I have exhausted our ability to conjure up more tests, so I am posting this to provide documentation to him and those of you at RME who might be able to guide me--or find the information useful.

One other note:  The UFX II was purchased to replace a Fireface 800 which experienced motherboard failure.  It functioned well on this very same computer system!!!  Rather than invest in that, I decided to move to the latest RME flagship.  I generally have amazing luck with your products, and still have an HDSP 9652 in an XP Gigastudio machine that is soild as a rock.  But something about the UFX II does not agree with this system.

HELP IS WELCOME!!!  Or...maybe I have discovered the world's most elusive bug, and I can help you kill it.

SYSTEM AND HARDWARE CONFIGURATION

ASUS X99 Deluxe Rev 1.xx
Bios 3902 04/19/2018 (current, but the problem has manifested through other Bios versions)
Intel Core i7 5930K
128 GB RAM, Corsair DDR4 (has never failed repeated memory testing)
AMD Radeon R9 380 Series 4GB GDDR5 (MSI branded)
Boot Drive is Seagate FireCuda hybrid SSD/Spinner (passes error checks)
Data Drives are 7200 RPM Spinners (all pass error checking)
UFX II (drivers/firmware current as of today...problem has persisted through several driver iterations with UFX II changes)
Sonnet Allegro Pro USB 3.0 PCIe - 4 discrete ports, one chip per port (Jeff recommendation).  UFX II has its own discrete port.

All system drivers are latest.  ASUS-specific peripherals, such as on-board Audio, WiFi, Bluetooth, USB, Disk Controllers, etc. are disabled on BIOS level.  Disk Controllers and on board Intel LAN ports are operated with latest generic Microsoft-provided drivers.  They have been tested with the ASUS drivers as well.

All power-saving or clock-related throttling has been disabled.  Hyperthreading is disabled.  Turbo Mode disabled/enabled has no effect.  Intel Onboard Ethernet power saving, jumbo packet, offloading to CPU, etc. is disabled.

I have disabled the swap file as a diagnostic, since I have a large enough amount of RAM to do so.  That had no effect, either.

Overall, the system is being run as cleanly as I have the ability to make it.

DIAGNOSTIC ACTIVITIES

As you can infer from the above, I have undertaken an exhaustive clean-up and optimization effort.

Working in Pro Tools is the quickest way to make this problem occur.  However, it is not the only way, as it has occurred even when playing back streaming video files on YouTube.  Obviously Pro Tools reaches out far and wide, and touches many subsystems on the machine.  I've replaced hard drives as an elimination possibility, divided project files onto different drives, etc.  None of the projects are taking this system to its limits.

Seemingly, the only two subsystems I suspect are potentially implicated are Video and Network.  I will explain why I think so...

Here are other specific diagnostic activities I have undertaken:

1)  I have toggled the GPU-usage modes in Pro Tools.  The problem happens whether Pro Tools is offloading video tasks to the GPU or not.
2)  I have toggled the "Use D2D" setting in Total Mix Prefs.  No effect on the problem.
3)  I've moved the USB 3.0 card to different slots, used different cables, tried a repeater cable, etc.  I feel I've exhausted those kinds of basic failure points
4)  I have undertaken Latency Testing with Latency Mon and the accompanying In Depth Latency Tests app.
5)  This does not seem related to Buffer Size in the driver.  In fact, this system plays back flawlessly with latencies down to 32 Samples!!  The problem comes at any buffer size, all the way to 2048 Samples.

LATENCY TESTING

Here is whereC it gets interesting, to me.

Any time I bring up the system from a reboot, warm or cold, the Latency performance is outstanding on this machine.  Especially after the exhaustive optimization efforts, and leaning down of subsystems and TSR/startup items, the system is otherwise rock solid.  It could run for a year with no crashes...I have literally never seen a blue screen on it.

But there are interesting phenomena with the Latency Testing.

First, I have narrowed down a way to QUICKLY cause a problem.  On a very lean Pro Tools file (one video, small footprint Avid codec that Pro Tools recommends) and simple audio, all I have to do is instantiate TOTAL MIX, and the problems will come.  This is why I experimented with the video modes.  The FiFo errors will tend to come on once I've had to, say, mute an output, or do something in Total Mix.

If, after I have had the FiFo error, I run Latency Mon, the system latencies are significantly higher, sometimes fatally high DPC latencies where Latency will throw up the "problems" message.  They'll be in the Kernel Mode driver generally, but will seem to implicate video/network subsystems as well.

But if I run the short-loop tests in the "In Depth Latency Tests,"  there will be a significant change there..."red" values of generally in the 385 microsecond range in one or more processors.

Once the processor is in this state, restarting Pro Tools again results in immediate FiFo Errors.  Pro Tools will throw Video Engine errors at that point--which I suspect are not very accurate or precise, just indicating that playback can't start everything in sync.  On rare occasion, after I have run those latency tests, I can restart the UFX II and those latency tests will return to the normal system baseline.  In those cases, I can restart Pro Tools, and it will run normally until the next FiFo Error.  But in most cases, at that point the system cannot recover normal timing, and a boot is required.  Once I reboot, the system returns to its very low latencies, with tight loop latencies maxing out at less than 30 microseconds on CPU0 and less than 8 microseconds on CPUs1-5 at the Dispatch Level.

THAT seems interesting.

But then it couples with this ERROR MESSAGE that is occasionally thrown:

TMFXCallback:  TotalMixFX.exe - Application Error
The instruction at 0x0000000000000000 referenced memory at
0x0000000000000000.  The memory could not be read.
Click on OK to terminate the program

Could this all be related to an obscure total mix bug?  Do you test against large memory footprints like mine, 128GB in my case?  I feel a bit incompoetent and out of my depth technically when it comes to computer coding, so please bear with a question such as this.  I simply cannot find many other things that seem to be related.

Opening Total Mix while in a Pro Tools session DEFINITELY hastens the FiFo Error.  That much is certain.

SO THAT LEADS ME TO THESE QUESTIONS:

Might I have stumbled upon an obscure Total Mix bug relating to something unusual in my system?

Can anyone explain EXACTLY what the USB Diagnostic is polling to throw up the "FiFo Error?"

Is there ANY possibility that a bad UFX II hardware component could be throwing bad data into the system?

Why would instantiating Total Mix hasten the problem?

How is Total Mix communicating with the hardware?  Does Total Mix talk directly to the GPU?  Does that relate to the "D2D" setting?  Are there any other settings which could affect this issue?

I am at the end of my rope

Why would that happen?  What is Total Mix adding to the equation that would bring on the error so much more quickly?

Why does Pro Tools cause the error to manifest so quickly?  I would assume that you test exhaustively against it, and that 12.8.2 would still have a significant user install base among RME customers.

Why would a system that ran the Fireface 800 without these kinds of errors (and which is very robust) be so susceptible to FiFo errors with the USB Driver?

I am trying to finish a feature film.  I have just a few weeks, so I am unable to just rip my system to shreds.  Is there a debug driver of some kind for Windows, which might catch more useful information?  Is there anything I have not described above that you feel would be worthwhile to try?  Am I missing the most stupid, obvious thing in the world?

I feel like I am pretty competent at wringing out systems...I've been doing it for years, and this is literally the most frustrating problem I have ever experienced with a Pro Tools system.  I have never had an experience where an RME interface was anything but rock solid and tenaciously robust about working even when the system was badly taxed.

I am really hoping (pleading, actually) for help with this.  Please let me know if there is anything else I can provide.

Best regards,
Bruce Richardson

2

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Bruce, thanks for all the details. PM sent.

Regards
Matthias Carstens
RME

3 (edited by ramses 2018-09-09 08:03:44)

Re: UFX II - FiFo Errors after exhaustive system work. Please help

EDIT1+2

Hi Bruce.

thanks for your detailed description, please also tell which Windows version you are using.

Warning: Before doing any change on Windows perform a system Backup by taking a disk image with Macrium Reflect, there is a free version available but I recommend to get this as backup solution and to install it later also to an USB stick so that you can boot from that stick for recovery. It copies all required drivers and add on drivers to the stick (USB3, Sonnet, Network, ...).

Along with your BIOS upgrades, did you perhaps  enable by this CPU microcode upgrades  against Spectre and Meltdown ? This can slow down the system for certain operations down to 50% of previous performance, for me ie when performing downmix in Cubase. In this case you should IMHO compensate this performance loss by reenabling Hyperthreading, see also next chapter. In Win7 you activate ucode upgrades by BIOS in Win10 the latest status was IIRR that Microsoft performs it, but changed for a while with 1804. There is a check tool available for this to be sure.

Does enabling of Hyperthreading make a difference? I would leave it enabled. For my system disabling of Hyperthreading kills Performance / reliability against audio drops pm high audio load (400 tracks test project in Cubase) although it's a E5-1650v3 which is very similar to your CPU.

What are your BIOS settings in regards to EIST, Turbo,  C-, P-, T-States, C1E ?
I recommend to keep EIST and Turbo enabled, C-states set to C0/C1 (or disable, depends on BIOS), disable P- and T-states, disable C1E.
With this settings my system runs with all cores constantly with 200 or 300 MHZ higher clock than Base clock.
See here how I am doing it on my Supermicro based socket  2011-3 system and what tools I use to control it.
http://www.tonstudio-forum.de/blog/inde … -X10SRi-F/

Use bitsum's parkcontrol tool to disable CPU core parking in the high performance energy profile and use this when you want to work with highest performance. Parking and waking up CPU cores cause also latency which also gamers notice as micro stutter on the screen/GPU.

In regards to DRAM. If your system runs otherwise stable I would not think that you have a memory related problem. Importal is to use modules of the same type. As a test you could take out 4 of them. Consult handbook which memory slot positions need to be used with only 4 modules built-in to ensure proper operation in quad-speed for socket 2011-3.

In regards to GPU, did eventually the driver change ? I had one time a bad driver which slowed down the whole system.

What PCIE slot do you use for the sonnet card which requires a x4 socket ? Is the socket that you use currently  eventually in conflict with other sockets or subsystems ? Does this slow down your GPU to work only at x8 instead of x16 speed? You can use cpu-z or gpu-z to find this out.

What happens if you connect the UFX II to different USB2 or USB3  port which comes definitively from Intel Chipset (not from the 3rd party ASMEDIA chip) ?

I also use and recommend this sonnet card, as it is very good and using message signalled interrupts (msi). It can't hurt though to fallback to Intel Chipset USB ports just for a test.

If you have Win 10 then use O&O1Oshutup to disable as many data grabber and background tasks as possible as there is too much data collection going on in the background, indeer,  cortana, weather apps and such crap.
You need to perform this also for the Administrator user if you reenabling it. Only some Oo10shutup settings are global, most seem to be on a per user setting.

On every system make sure that the indexer for Windows search / Cortana is disabled or at least fine tuned for only indexing meta data.

I would start with

0. Backup system disk by taking an image using Macrium Reflect (very reliable)

1. try ufx II on other usb2/3 usb  ports coming from Intel Chipset to exclude issues with sonnet card

2. Then BIOS related part to ensure energy saving i's disabled completely and Hyperthreading, EIST, Turbo are enabled.

3.  disable CPU core parking.

4. Check whether ucode upgrades slow down your system. On Win 7 you can deactivate them by flashing an older BIOS.

General remark.

1) Performance tuning you do in single steps, not more than one change then reamers ure.

2) The sum of all fine tuning steps together bring the best benefit. Keep suggested things even if they change not much at the moment as single step as long as it makes things not worse.

3) Upgrade system Disk to a SSD
which also can hold sample libraries to increase overall system Performance.
Get a second SSD for recording projects only.
By this you have split SATA load for system and applications to 2 different SSD's.
Samsung EVO's are very good.
SSD's became cheap these days.
You can use Macrium to restore your system Image to SSD for a quick migration.

In regards to the Sonnet. Fully supported by Win10, only Win 7 needs driver installation.
Which driver do you eventually use (if Win7).

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Hello Ramses,

Thank you for such a generous response.  Matthias has been corresponding with me in email as well.  Sorry, haha...the one thing I didn't mention was Windows 10 Pro 64-bit v.1803 build 17134.228

Re: Bios upgrades, I do not **think** that the Spectre/Meltdown microcode fixes were implemented.

I like Macrium Reflect, and I have an image.

Hyperthreading: Not MUCH difference, but seemed maybe a little more solid with it disabled.  What I noticed was that once the system has entered the FiFo Error/compromised state, and begins to fail the tight-loop latency tests (IDLT), that Hyperthreading seemed to exacerbate that--that it "failed worse" for lack of a better way to describe it.  Reboot required, versus maybe just resetting the UFX II and regaining normal processor latency numbers.  Could have been the luck of the draw, though.  I will try re-enabling it again. 

I forgot to mention that I had actually re-enabled Turbo Mode.  This system runs 100% solid at 4 ghz w/RAM clocked at 2677.  I had slowed it down to spec for testing purposes, but it has been running well in Turbo since I built it three years ago.  This problem manifested when I switched from the Fireface 800 to the UFX II.

Core Parking already disabled.

DRAM has been rock solid.  I cannot make it fail..I've tortured it with memtest, as this seemed like a potential "first place to check."

GPU driver has been kept up to date, but I've tried various drivers.  I have suspected GPU (simply because of the lack of anything else I can find, and because I work with picture), but the issue also occurs when working on audio-only files, GPU processing disabled.  It occurs less quickly or often, but in any state or type of file, I have not gotten "rock solid" out of the UFX II.  It makes the system feel as if it's a cheap junker, which is quite devastating as it was not cheap to build this system three years ago.  I had intended for this to be a problem solver investment for me, and was hoping for the opposite when upgrading to the UFX II, that it would actually be the missing link to a MORE solid and efficient workflow.

I have not tried to reduce the GPU to x16.  The Sonnet is currently in the slot recommended for a second GPU at x16, however, I have tried it in several slots.  There are no perceivable differences.  All slots in this system are capable of x16, with the exception of a small x4 "half slot."  I will try reducing the GPU's footprint to x8.  No harm in trying.

I have tried the Intel USB 2/3 ports, as well as the ASMEDIA 3 and 3.1 ports.  All the same.  None worse, none better.  I was REALLY hoping that the Sonnet was going to make a difference...but really, none.  I opted not to return it, since it would be a "known good" set of ports.  I have disabled most of these other USB ports now, trying to keep only the subsystems running on the machine that I am using.

I've already disabled data-grab/background tasks.

I think this is the dilemma...I have experience tuning systems as well, and that is why this is driving me insane.  For some reason, this very well tuned system started behaving like an off-the-shelf consumer machine when I moved from the Firewire-based Fireface 800 to the UFX II.  I replied to Matthias earlier asking if he knew whether the UFX+ would be more robust as a USB 3.0 native interface.  Do you have any comparative experience...I see that you use the UFX II.

This is quite distressing, as the difficulty of trying to finish an indie feature is quite high.  I am "all things music and sound" on this project, so I am doing ten jobs already, and the ugly truth about film biz is that indie films are exactly as much work as major films, only with less people, haha.  I will test the theory of fewer GPU lanes, and report back.

B.

Re: UFX II - FiFo Errors after exhaustive system work. Please help

brucerichardsonmusic wrote:

Re: Bios upgrades, I do not **think** that the Spectre/Meltdown microcode fixes were implemented

Please check as with Windows 10 Microsoft delivers them as part of their upgrades. This was working so with 1709, 1804 broke it for a while, but it should be back now.

brucerichardsonmusic wrote:

I forgot to mention that I had actually re-enabled Turbo Mode.  This system runs 100% solid at 4 ghz w/RAM clocked at 2677.

Full Turbo you will not get when disabling cpu core parking. But a little more for all cores.

brucerichardsonmusic wrote:

I have not tried to reduce the GPU to x16.  The Sonnet is currently in the slot recommended for a second GPU at x16, however, I have tried it in several slots. There are no perceivable differences.

Maybe misunderstanding here. If you place the card to the 2nd GPU socket it can happen that the speed of your primary GPU socket will be reduced from x16 to x8. Ensure to use a socket that does not impact the performance of your GPU.

brucerichardsonmusic wrote:

I have tried the Intel USB 2/3 ports, as well as the ASMEDIA 3 and 3.1 ports.  All the same.  None worse, none better.  I was REALLY hoping that the Sonnet was going to make a difference...but really, none.

It's a very good card and it solved some issues that I got after adding things like Bluetooth USB adapter and one USB 3.0 bridge to my system (I have C612 Chipset on a socket 2011-3 server board).

Now I can connect two UFX+ and ADI-2 Pro to the Sonnet card without any issue's and load a Cubase test project with 400 tracks and playback without audio loss with ASIO buffer size set to 32.

Also stable with Spectre Meltdown ucode upgrade but not when disabling Hyperthreading.

brucerichardsonmusic wrote:

I replied to Matthias earlier asking if he knew whether the UFX+ would be more robust as a USB 3.0 native interface.  Do you have any comparative experience...I see that you use the UFX II.

No I use 2 UFX+ and one ADI-2 Pro.
You can try an UFX+ of course.

In most cases if things fail like this then it's most likely your combination of mainboard / Chipset / BIOS. I also had an bogus Mainboard in the past where the successor model of the same board of all sudden performed much better, but didn't cure everything.

For some people Firewire gives better results. For me it was USB.

The best is to ask other people what works good or to buy a turnkey system where you pay that somebody else solved all issues.

I heard that Xeon based supermicro systems run very reliable. Built such a system and I can confirm, yes true. But even with this system I needed to get the Sonnet card as the USB ports of Chipset are not fully isolated and the connected equipment can influence each other.

Now where I isolated all three RME devices behind the Sonnet no issue's.  Neither on Win 7 nor on my Win 10 test system 1804.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Try two things:

Switch the GPU driver to the Microsoft Standard VGA driver via Device-Manager. This is for making sure that the GPU driver really isn't getting in the way of things (regardless of version). The combination of (Asus) X99 board + NVidia cards causes USB issues, which I could not reproduce using an AMD card in the past, but you never know. Enabling mouse-trails (disabling hardware mouse-pointer acceleration) would then be a possible workaround.

Connect the RME interface to an Intel USB port and switch XHCI Handoff (likely disabled by default, then enable it, or vice versa) in BIOS.

Report back after that.

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Hi Timur,

Regarding the Intel USB port experiment, I have already undertaken testing the Intel ports with all flavors of XHCI handoff.  I tested the latest and a few earlier Intel-branded drivers, along with the Microsoft provided ones.  Additionally, I tried a few other PCIe USB 3.0 adapters that I had around the studio from previous machine builds.  These had varying chipsets.  I also tested against other USB "2.0 native" cards.  Finally, I purchased the Sonnet Allegro Pro 3.0.  All failed the same way, so I feel that I've exhaustively tested the USB subsystem(s).  My conclusion at this point (unless you see something else in all that which I missed) is that something else is interacting with ALL of these scenarios to destabilize my system.

I need to test with the standard VGA driver, I suppose.  That is difficult in my current predicament, because I am sleeping very little as is, and I can't effectively work to picture in Pro Tools in that configuration.  Unfortunately, the deadline for completion of this film is not adjustable to accommodate this issue, and over the few months I have been fighting this (ever since the Fireface 800 fried, at the beginning of production on the film's music), I have been struggling against the dual demands of keeping up with the work load and trying to solve this highly frustrating problem.

I am currently experimenting with limiting the AMD R 380 to the PCIe 2.0 standard.  I did some reading about the card's performance in systems which are actually limited to that standard, and the conclusions of experienced reviewers on that subject were that the performance of the card would not be greatly impacted in that scenario.

I would appreciate opinions on that.  My rationale for trying it is to determine if the PCIe 3.0 bandwidth in and of itself might be stressing a yet-unidentified weak link or undiscovered compromise in my system configuration, and whether limiting that throughput would lighten up and potentially walk the system back "from the edge."

Yesterday, at least until I became exhausted and needed sleep, the system seemed to stay up MUCH longer.  But, because I have been working through suggestions offered by Ramses and Matthias at a very quick pace, I am unsure whether I can confirm whether this did indeed help--or whether one of the other suggestions may have actually solved the problem.

Thoughts?

Today I am going to try to push the system hard until it either fails, or until I determine that something we've done has helped.  I will be very grateful if it is the latter.  And...if I get significant progress made on the film, it will start buying me some time.

I will report back to you all when/if new information manifests.

THANK YOU to Jeff, Matthias, Ramses and Timor.  I am grateful for your generosity, and for the time you have taken to offer suggestions.  I have been laughing about this experience, because I have configured and optimized many, many machines over the years and I don't think I've ever run into a problem quite as difficult as this one.  Usually, a few hours and some easy tweaks will do it, or I'll discover a piece of hardware failing or something stupid I did by accident.  This seems to be a genuine design issue with the Asus X99 board, which necessitates all sorts of implementation gymnastics to address.

Of course, when I built this machine over three years ago, the Haswell E and X99 chipset were bleeding edge, and the Fireface 800 did not present these issues.  My hope is that this may all fall under the category of deferred optimization.  Ironically, I didn't choose the AMD GPU specifically to avoid X99 conflicts.  I'd just become tired of a particular Nvidia board I had in a previous build (which didn't want to remember which monitor was primary), and was giving the AMD card a roll of the dice.  So, at least that choice seems to have been well-made, given the number of Nvidia-specific problems I've seen while researching my own issues.

Cheers, and please let me know any other thoughts that might come up.  One thing in particular that I did while working through the suggestions Ramses offered was to use the "O&O1Oshutup" utility to double-check my work on manually disabling various Windows 10 "junk processing."  I was glad to see that I had found a number of the offending processes already, but was surprised (and hopeful) to find some others that I had not specifically run across.  IT MAY BE...that one or more of these is actually responsible for the better performance I ***might, haha**** have seen late last night.

Wish me luck, and thanks again.  Any feedback on this report is appreciated.

Re: UFX II - FiFo Errors after exhaustive system work. Please help

UPDATE:  I feel I am nearly back to square one.  What seems to be the state of affairs here is that I am optimizing the living bejeezus out of this system, to the point that I am disabling most of of the features I paid good money to have, up to and including replacing the entire USB susbsystem, and still it seems that ANY "perturbance in the force" immediately results in the UFX II tanking into the gapping state with FiFo Error indicated in the driver.

Here's the only additional clue I have after all this optimization and isolation:  It is now very consistent that when the driver enters the FiFo Error state that I can instantiate and run IDLT and get Tight Loop Latency Test numbers exceeding 300 microseconds.  If I then power-cycle the UFX II and retest, the system goes back to normal.

Second Clue:  There was for a while a second latency-increasing issue present.  In searching every remaining hardware device for power-down preferences, I noticed that the built in Intel Ethernet ports had some power-saving preferences hidden in Device Manager.  I went through both drivers and disabled any type of power reduction or offloading, with the idea to limit their interaction with the CPU to the highest possible degree.  This, I think, did make a difference in their impact on the CPU.  It was after this that "Clue One" began to show consistency.  That the tight-loop latency text condition would actually "heal," one-hundred percent of the time so far, when I power-cycle the UFX II after it goes into buffer/stutter.  System now returns to normal latencies instead of remaining unstable.

THIRD CLUE:  Limiting the R9 380 to PCIe 2.0 BANDWIDTH seemed to help the GAPPING (USB DIAGNOSIS showing a "number" as a result) which was usually a sign that performance was deteriorating towards an eventual FiFo Error state.

Third Clue seems significant, because why would that be?  If the CPU has 40 lanes, and those lanes can be twice as "fat" under PCIe 3.0, then wouldn't the GPU operate MORE efficiently with the fat lanes, not less?

Thoughts?

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Did you try to disable the mouse-pointer hardware acceleration yet (by enabling mouse-trails via Windows mouse options)? It's the mild version of trying to disable the AMD driver all together. As mentioned before I was only able to (re)produce this problem with the combination of (Asus) X99 + NVidia cards, but you never know. Even with full on dropouts there were no increased DPC latencies measurable.

In the end it very likely is a BIOS/UEFI issue present on Asus X99 boards and likely others as well. There is hardly any reason why something like accelerated mouse-pointer drawing should disrupt USB operation, but it does. Based on that experience alone I do not trust (Asus) X99 systems and would not be surprised if other strange combinations cause similar issues. So you may just have hit some similar BIOS bug.

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Timur, yes, I tried the mouse-pointer acceleration workaround early on.  From what I saw in some of the reports on this forum, it appeared that for those users, enabling mouse-trails was an immediate and complete fix whereby function afterwards became normal.  I did not see that result.  Presently, I do now have the mouse trails enabled (at their least eye-insulting feedback level, haha) in case it was making some tiny incremental difference.

I certainly feel it is unfortunate that at the time I built this machine I was not aware of issues with X99 systems and USB.  At the time, this motherboard seemed to be nearly ideal for this machine's function in my studio, and indeed it was right until the moment I replaced the Fireface with the UFX II.

At this point, I honestly wonder if I should bite the bullet and install an NVIDIA card from my previous build, and see if the known solution to that card's issue is more effective than the (I suppose) yet unknown solution for my dilemma.  It is devastating to my creative flow to be on-edge and constantly fighting this, as I'm sure you can imagine.

Thank you again for hanging in with me and giving feedback as I work through this.  I keep hoping I will eventually stumble across a solution, as there is really no space in my production schedule to do much except forge ahead and deal with the constant FiFo Errors and resulting consternation.

I still find it weird that throttling the PCIe bandwidth to the GPU really does seem to have a partially mitigating effect.  I can't understand why artificially limiting the data flow on a pipe which is designed to handle it wouldn't result in less CPU efficiency, not more.  I'm far out of my area of expertise there, but it seems illogical that the same number of pipes at half the throughput would be mitigating in any way at all.

11 (edited by brucerichardsonmusic 2018-09-12 04:26:31)

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Also this: Total Mix is putting a substantial load onto the USB subsystem, at least according to my experience.  I can break the system just by instantiating it.

I find it bizarre that Firewire was so much more solid on this same machine.  USB seems fragile in comparison.

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Can't complain about USB. Look here.

http://www.tonstudio-forum.de/blog/inde … cks-de-en/

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

Re: UFX II - FiFo Errors after exhaustive system work. Please help

ramses wrote:

Can't complain about USB. Look here.

http://www.tonstudio-forum.de/blog/inde … cks-de-en/

Yes, I read that.  My results, when the Diagnostic is not throwing up errors, concur with these.  At 32 buffers, the system is able to handle simultaneous multitrack Audio, Video, and even some audio DSP.

Do you have any theories on the two data points that I found interesting?

First, that throttling the 16x AMD R-9 from PCIe 3.0 to 2.0 bandwidth seems to help make the system more stable.  That seems counterintuitive (that the CPU would take on more work if it can only pass half the data through a pipe that is otherwise solid).  I say that it is solid (at least in and of itself) because I've put that video card through exhaustive benchmarking and it has consistently overperformed its advertised spec when hit with multiple rounds of testing.  Why would artificially making it a less efficient subsystem help out here?

Second, that instantiating TotalMix is a pretty guaranteed way to bring it down and bring on the gapping and FiFo Errors quickly?

To be clear, these errors are in no way similar to typical buffer underrun errors.  Once this gapping occurs, other observable subsystems seem caught up in some kind of destabilized state of operation.  The GPU and video output frame rate becomes affected too.  In fact, once it has occurred, Pro Tools throws up a Video Engine "reported errors" message.  But it seems to be a symptom, not a root cause, since the FiFo Error can occur in an audio only session, without even having instantiated Avid Video Engine.

If I close Pro Tools after the error has occurred, and just go to YouTube and open a random video, the video "syncs" to the gapping heard in the audio.  If I leave the video playing and power cycle the UFX II at THAT point, the video will begin playing at correct frame rate.  Once I power cycle the UFX II back on at that point, the problem is "healed" and both audio and video play back normally.

Just to be clear that I am not complaining about USB itself.  Nevertheless, I am trying to make an expensive and well-built system function with the UFX II--an interface that was recommended to me as my best replacement path for my failed Fireface 800 by two different (and very competent and helpful) RME dealers.   Now I am in a hellish world of sleeplessness and embarrassment as my fellow filmmakers sit and wonder if I will hit my deadlines.

Any other suggestions as to what I might try?  I am curious if you have ever built systems with the UFX II versus the UFX+.  Theoretically, the UFX II does not need more bandwidth than USB II can offer.  BUT, what  I am experiencing is that simply adding whatever USB load that TotalMix adds to the equation TANKS my system dependably.

Hopefully everyone is clear that I am not trying to assess blame.  I am trying to not be in hell, and to come out of this film without losing any more money, so that I can recoup the losses I already incurred when the Fireface reached the end of its life (which was well lived).

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Did you try to disable D2D mode in Totalmix?

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Thank you for the reply Timur.

Yes, that was one of the first things I tried.  My methodology was working outward from any RME-specific settings into the system work.  However, I will try that again, because I have done quite a lot of further optimizing since my first post.

In my assessment, I would say that the grand total of all the optimizing has walked the system back maybe a step from the edge.  It seems to me that whatever constitutes the root cause is still present, and the only progress I'm really making is to keep inching the tipping point.

One of the clues, though, is that even though my track count and buffer performance is excellent at 32 samples (before the eventual FiFo Error manifests), what seems to hasten that tipping point is additional USB loading, either in the form of Total Mix or in the form of simultaneous record and playback.

One thing that really seems to trip it is ADR recording, where I'm looping 15-20 second segments of video/audio while Pro Tools is dropping each take into the same track (on different playlists).

If that offers anyone any clues, I'm all ears.  What I generally do is wake up and try anything that's suggested, and then get as much work done as possible until I fall asleep.  Rinse and repeat.  smile

Best regards,
B

Re: UFX II - FiFo Errors after exhaustive system work. Please help

As an aside, I think that subtitle under my name is funny "ADAT user."

Ironically, I still have a rack of ADATs and a BRC stored from back in the day.  Too bad the BRC isn't useful as an external controller and the converters on the ADATs are so ratty.  I was beginning to question why I didn't just unload them for whatever I could get, then someone called me out of the blue hoping I could rescue an old ADAT session they had.  So, they earned their place in the closet for a little while longer, I guess.

17 (edited by anotherzen 2018-09-28 22:55:45)

Re: UFX II - FiFo Errors after exhaustive system work. Please help

I am in the exact same situation. I get Fifo some times in the USB Diagnosis, other times it's just numbers.
First time i connected the UFX II the sound would start stop start stop with about 1 second with sound and 1 second without.
Sometimes i get crazy buzzing sounds when audio is playing, but usually there are random dropouts.

Tried all my USB ports all of them produce the same issue.
I had a Babyface (original) before and had no issues. Updated drivers, updated firmware, no CC on etc.
I have a very similar setup as OP. Windows 10. Asus x99-e motherboard.
Everything has worked perfectly until i added the UFX II.

This seems like it's a common issue,
https://www.youtube.com/watch?v=8FIg_y8POFY
this guy had to buy a usb addon card for it not to do drop out, is there a specific USB prerequisite?

18 (edited by anotherzen 2018-09-29 10:51:33)

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Just as a test i did a complete reinstall of Windows to see if there where any usb driver or other issues. Mint Windows install, same issue.

Edit: I have also done a reset of the Bios where i had speedstep and turboboost turned off, it is now on. Still the same.

Edit 2: These are also all intel USB ports, the ASmedia ports (which are not compatible) give the same results.

Edit 3: I see it's more or less recommended to get a standalone PCI card for the USB (sonnet etc). Will try this.

Re: UFX II - FiFo Errors after exhaustive system work. Please help

Ok, so i ordered an Allegro Pro USB 3.0 PCIe card... Still the same issue.

Re: UFX II - FiFo Errors after exhaustive system work. Please help

In the end I am quite happy that I did not jump on the X99 bandwagon.