The TotalMixFX failing hit me, too. Curiously after the first failure I noticed that I had not updated yet and overwrote the Totalmix in Applications, but Totalmix still failed. What i did then was to disconnect the UFX, reboot and then overwrite Totalmix again, now it works.

My guess is that OS X did not overwrite Totalmix the first time because maybe the process was still running hidden. Should have gotten a message about not being writable, but since it works now I could care less.

Yes - I knew before that the BSOD was caused when both FW and USB were connected to the same windows PC thats all I knew and posted previously - not that it would happen when it was connected to a different PC (fine when OSX is the USB machine and I kind of assumed both drivers might share very similar/same protocol logic within the limits of OS specific stuff - I guess not).

Re the OSX wierdness - you actually mean it has not been reported or perhaps not tested in the same way on other systems. You cant know that it doesnt happen at all.

Anyway - I think timur actually nailed part of what happened on OSX related to TotalMixFx, but thats seprate from why it hung when restarting the first time and TBH relative to previous OSX driver updattes - odd that it took ages the second time - all stuff that to me as a developer raises alarm bells and I would actually want to know about.

Cheers Timur - I have Paragon NTFS v9 (upgraded from v8 yesterday evening).

Oddly - for the first time ever since buying the UFX Im starting to get terrible stalls occasionally in Ableton Live on OSX (Not tried with windows driver for obvious reason) - switching to my NI audio 10 then back to the UFX seems to solve it for a while.

By stall I mean Live suddenly goes into very high CPU use, too high to play audio, then resumes again. Eventually it degraded into continuous distortion when it returned to normal CPU use level. After switching to the audio 10 (in live preferences) then it was fine immediately through the Audio 10 and OK when I switched back to the UFX for a while. Note, I did not exit Live during these switches, it seems that simply closing and reopening the core audio driver did the trick.

As you might ask, I did verify normal audio operation after the last round of round of apple updates, so the only system change between good reliable operation and the current state is installing the RC3 driver, UFX firmware update and updated TotalMixFx. I also left it running on the Audio 10 for 10-15 minutes - no stalls.

Also did try existing and restarting Live - stalls returned after a few minutes and was fine again which switched back to the NI Audio 10 and left it on that. The issue is also present when running Logic Pro 9, though the impact on audio is not as dramatic and recovery is quicker - just a gap rather than distortion as well.

Normal CPU use (activity monitor) in both cases was quite low and evenly spread over the 4 pairs of cores. 

As ever, if there is any further info that would be useful, let me know.

I need to restore reliable function for next week, so am hoping its possible to go back to release driver version?

It installed cleanly, but no - they were back again, so yes - 155 is useless for me as well.

Obviously I didnt test it for long enough and that makes me wonder if I checked for long enough after the very recent Apple update for these MBPs. The NI audio interfaces OTOH have had several hours of clean use since, so they appear to still be working well.

Going to have to try and manually clean up the current driver and go back to the release version and release firmware. The aim of updating ironically was to try some USB recording, so for my pains, this happens and even get balled at for posting my experiences in what I though was the right thread... nice!

Since the problem with using two cables at once seems to be known there are two possible workarounds/solutions I can think off:

1) Disable the Firewire port of your PC via Device-Manager before using the Mac via USB.

2) Put a powered Firewire hub/HD in between the UFX and the PC that enables you to switch it on/off easily, either by putting it within reach or by using some power-outlet remote control.

That surely applies only when both are connected to the same computer and that computer is booting. I must admit I was suprised when I fnd this months ago that noone else had hit it when they re-flashed as you need to use USB to reflash. Kind of thing I would have expected to especially be notice in a test lab where RME must be testing FW and reflashing alot, or the test script says unplug everything at the start

However I have NEVER assumed the priority to USB came from the OS, I had allways assumed it was code path in the UFX - is USB conected - yes - configure for USB, else if FW connected, configure for FW, else whatever (I never tried it and later plugged something in later - Im guess it does nothing and waits for whatever is connected first).

That to me is the implication of what is written in the manual and that appears to be how the UFX behaves, so in tha respect, manual would seem to be correct?

Still this does not change that the OSX RC3 drivers seems to have issues (with some passing similarity to a past fixed OSX driver issue) regardless of whether FW is connected which was why I posted in the first place. Nor does it change that the windows driver will BSOD in boot on any (same or other) computer when a (at least windows, never tried OSX) computer is connected to the FW port and apparently BSOD on other circumstances as well from another post in the RC3 thread.

Now, if you would put as much energy into acknowleging and reporting these issues internally as you are putting into trying to deflect and ignore them and worse, imply that is somehow my stupidity and/or fault then perhaps life would be easier for us all. Oddly I thought you actually might want to know that the driver install and operation doesnt seem release ready yet.

And yes - stupid me for thinking tha a 100% easily reproducable driver BSOD during boot might actually have some priority as TBH - it looks really really bad never mind the risks to a customer's computer (due to windows reaction to this). I guess we come from different software engineering backgrounds and certainly very diffrent customer relations backgrounds. As for not fialign on other systems, well Timur immediately posted that he had a non-functional TotalMixFx as well.

> trying to deflect and ignore them and worse, imply that is somehow my stupidity and/or fault

HeadScratch  :roll

Just to mention it:

My earlier supposed workaround of disabling the FW port (or just UFX driver) via device-manager seems to work. I tested this myself with a bootcamped Macbook (FW) and an Acer Windows 7 laptop (USB).

But I found an oddity with how the UFX reports itself via USB when FW is already connected and reported that with screenshots and some detail. I don't see this a a major issue myself, but maybe it can be solved at some point for convenience.

Thanks for posting to this thread.
Some question:

1. Will this work with fixed the OSX 150 driver?
I am not sure what is gained here - it stops BSOD - great that means Windows will boots correctly, but you cant connect both at the same time at all which would seem a huge step back condemming anyone with racked machines to forever having to dig around behind the racks to unplug one or the other if they have need to plug into anoher machine to driver the UFX (As per manual regardless of your claimed interpretations to suit your bugs). I can see how this might appear to be a great idea from a programming work around perpective, but pretty much useless when the ability to leave on connected and connect the other as need was (among others) an attractive feature upon which a purchase decision was made.

So it doesnt solve that problem at all. I guess this is where you invoke the fine print about specifications subject to change that stop shafted customers from invoking trade descriptions act etc.

Not impressed - at all!

Should send me a free babyface as compensation I think.

OK, so your telling me I need to shut computer down instead of leaving them connected?

I appreciate that your are giving time to this, but here a simple question:

Can I leave this connected via FW to a *switched on* PC or MAc Pro, while a Macbook pro is connected to the USB to take over the connection occasionally (even if I have to power cycle the UFX to get it to see the USB connection and use it, though ideally not, but understandable).

The original description of this feature was that USB took precedence which MC tried to change the meaning of when clearly with the exception of the Windows driver BSOD functioned in the way the manual suggested it would and in a way that was useful. It seemed (obviously from a user perspective as I cant see the code) to me the only thing that needed fixing here was the windows driver - not a major change to the behaviour of the firmware.

Please think of this from a user perspective - would you really want to be power on/off computers or have to pull racks out to disconnect? I mean - does that make any sense to you at all as a potential user? Is it really so hard to consider real use in an actual physical studio? Seriously, Im stunned that people who surely have been in and around studios for years should not get this.

I may be the only person so far on this board who has tried to use it this way *and* said so - that doesn't mean there arn't others who like the idea as well. People who have been in here rather like it, though of course I've had to warn them about the windows driver. The reason is simple - we typically have two production/performance machines - a permanently connected main studio workstation and a portable that is useful for taking to other studios and/or live work. As we all *currently* use RME audio interfaces in studio then it works well if the BSOD is fixed and nothing else from a user perspective is changed.

No you can't. And you should understand that if we build in something like that the next user comes up with this example exactly the other way round. USB connected PC, and FW Mac should take over occasionally (quite logical example with Macs, IMHO).

I am also really disappointed from your comments here. We do not make a living from screwing people, but whatever we do you try to turn it that way.

Here are some simple solutions (@Khazul: I think you are overreacting a bit):

1) Get an inexpensive USB switch that allows to connect one USB device to two computers. They come in a variety of ways, some manual, some automatic, some with control software. I think you can find up to 8 port ones. Here is a manual 2 port one:

http://www.amazon.com/Cables-Go-30505-2 … amp;sr=8-1

I own a manual switch myself (other than the one linked above) and it makes an audible "click" when switching, pointing to a relay being used.

2) When you turn on the UFX while both USB and FW are connected (either to different or the same computer) then it will prioritize the USB connection (while both LEDs on the front are lit).

When you send any of your two computers to *sleep* (stand-by) the connection will get lost and the other computer will take over automatically!

On OS X you only have to press ALT-CMD-EJECT to initiate a sleep or use the mouse. On Windows you can either use the mouse (it's even possible to create an icon shortcut) or use WIN -> Cursor-Right -> E.

2b) Since Windows usually takes longer to go to sleep and some PCs don't cut power on the FW port when sent to sleep (or even turned off) the other option is to disable the FW port via Device-Manager.

If you PM me I can send you a simple batchfile that will disable and reenable the FW port with a simple mouse-click on a shortcut. That will break the FW connection for a second and allow the Mac's USB connection to take over without having to use Sleep. Unfortunately I cannot provide that for OS X, since the OS doesn't allow me to disable FW even when nothing is connected.

In any way there is no need to disconnect any cables or shutdown the computers.