I already posted in here and I'll say it again.

I already had that problem and it was a internal firewire problem, not with the Fireface but with the OS. Never got that beep on Mac OSX but at that time I didn't had my Macbook so I only tested on a PC's.
At that time, I tested using two diferent PC's, with diferent motherboard chipsets, and all kinds of try-fail systems. Because of that, I have 4 diferent firewire pci cards on the shelf, two VIA, one NEC and one Texas Instruments. All of them work fine, all of them gave me the same problem.

Using a logic thinking, if 4 pci cards do the same, it's the Fireface that's wrong!

Wrong.
It was a OS software problem.
For what I tested and used the Fireface, that beep is a audio driver hang (experts, correct me if I'm wrong), caused by two or more pieces of software, trying to use the Fireface at the same time in a corrupt way. When everything is working fine, if we are using Live 7 for exemple and we open Cubase, the second program won't be able to lock the Fireface for itself and a dialog will pop up alerting that Fireface it's already beeing used by other program. This is the legal way.
Now imagine a corrupt way of Ableton Live using the Fireface and another program or even the OS, steals the same information pipeline for itself? If the system doesn't consider this has an ilegal procedure, the Fireface itself goes into "panic" caused by two hosts pulling it to each side.
That is like Matthias said, a firewire transmition problem, even if it's at (OS) software level.

Feel free to PM or even add me on MSN to try to solve it.

Cheers and have a nice weekend.

Hi,

I have the endless beep with foobar2000. When it happens the red led is on but the Fireface 400 still appears as connected in Windows. The beep stops when I close foobar. When I disconnect the Fireface and connects it again, Windows does not detect it. I have to reboot for the Fireface being OK again. This happens when I'm doing something else on my PC (internet navigation for instance) while foobar is reading music. The fireface is selected as the audio output in foobar,but not as the default audio output of Windows.

ok so i've given in and bought another (non rme interface) it will be delivered tomorrow thank god

I have had the beeeeeeeeeeeeeep problem extensively in mac OSX using a macbook pro 2.33 ghz 2gb ram

switching to built in sound for system sounds DOES NOT  solve the problem im afraid, neither do any of the other tricks or workarounds, i have tried them all and still a 0db BEEEEEEEEEEEEEEEEEEEEEPPPPPPPPPPPPP

this makes the fireface totally useless and has on occasion made me look very silly in front of clients

Come on rme write some new drivers or something please..................

Its not like i can afford to spend 600 quid on a doorstep, im a musician

but thats what i did when i bought the fireface 400.

add to that the 400 i spent on my new interface........... brilliant service ffrom rme there

I will report back soon

BBBBBBBBBBBBBBBBEEEEEEEEEEEEEEEEEEEEPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP

It's funny (?) how, when it gets uncomfortable, NOBODY from RME answer your questions. To make it simple, I've spent 1200 ? on a Fireface 800 to spend my days trying to solve this random bug (the beeeeeep thing) instead of making music (this is my job BTW) and getting no freaking help. Thanks a lot.

I forgot to say that I did, of course. Tried with a clean system (with nothing except MOTU and RME necessary files) on a newly formatted HD. I guess I tried everything. And now (it's related) I notice that working with DP 6 (flawlessly for the moment), if I switch to Safari for instance or iTunes, then I have to restart the hardware Driver inside DP (when Fireface is set as the default output for the Mac). I'll make some more exp. and keep you posted.

Even if I repeat myself: My only experience with the looped sample-buffer problem (aka beeep) happened when some audio application froze, crashed or otherwise did something ugly that the RME driver was not responsible for.

The RME driver tries to catch these situations, but some things can slip through. I found a reproducable situation with Ableton Live on Windows that made the FF beep. But the source of the problem was Live, not the FF. The driver did not catch the situation though, but by showing this *reproducable* situation to RME they could fix the driver to better catch these in the future.

I did not follow the whole discussion, but did anyone come up with a *reproducable* way to make the FF beep on OS X?

Mocker suspects "Airport" to be part of the problem, but which WLAN chipset are we talking about? My Unibody MBP uses a Broadcom WLAN chipset and I never ever had the beeep even when surfing the web while having Ableton Live and Mainstage running.

Just to mention it again, we need something *reproducable* here! fryingpan

My experience is that there is no such thing as a "random" problem in software.

Most really random problems happening with computers are down to broken hardware (especially power-supplies and mainboards).

Everything software can usually be traced down to at least something reproducible (ha, I finally looked up the correct spelling HeadScratch) circumstances.

We already know that this is not a beep, but a looping of the very last audio-buffer that was played before the driver hang. Now what can make the driver hang?

1. The Audio application itself froze/hang or crashed and doesn't properly unload the driver DLL from memory. And just because you can still use GUI elements of an application doesn't mean that it's Audio related threads didn't freeze or crash.

The driver tries to catch these situations to switch off audio, but nothing is perfect. Restarting the application can help in these situations, but it can also be that you need to switch off the unit in order to force the OS to unload the driver and reload it again after switching back on.

2. A plugin inside the Audio application (VST, AU, DirectX, whatever plugin format your favorite Mediaplayer is using) might misbehave and cause situation 1.

3. The communication link between the unit and the driver/OS/application can be broken.

This can be a faulty cable, a faulty Firewire port, a faulty Firewire chipset or a faulty Firewire driver. If the communication link breaks up by sending garbage over the wire to the unit then I can well imagine the unit to get confused and keep playing the last buffer. The units Firmware might try to catch such situations, but that's something that RME knows best about.

Just because other units seem to work over the very same communication link doesn't mean that the link works flawless (think of LSI/Agere FW chipset for example). The RME Firefaces utilize the FW bus upto its standarized limits, which in turn can reveal flaws in the design of your FW setup, especially if some parts to fulfill the standards when getting near those "limits".

4. Last but not least the driver itself can be faulty. Maybe there is some kind of circumstances that make the driver misbehave or hang or crash or whatever. But these circumstances, as random or specific as they may seem, should usually be reproducible. It may be more effort than a paying customer is willing to invest though. Still this is only one possible cause of the problem among several others.

That's ok, you need to use what works for you and it's not as if there ain't any alternatives out there. If the RME inteface gives you troubles and another piece of gear works then you really should not be wasting your time to find the cause of the problems, but switch gear.

OK seriously, we are all audio ENGINEERS here.  Troubleshooting, proper setup, and maintenance are all part of the gig.  Since it seems like nobody knows anything, let's start with what we do know. 

1) the issue IS cross platform.  (stated on page one or two that the problem exists on XP)
2) the problem occurs with both bus power and external power.
3) the problem occurs with a variety of applications.

All of this points to hardware or drivers/firmware.  However the lack of reproducibility makes the issue nearly impossible to fix.  (impossible to the point of RME ignoring the problem)

What we need to know:

1) EXTREMELY SPECIFIC system information, including OS, computer, processor speed and number of cores, mobo, ram, video card, fw chipset, wifi chipset, interfaces, controllers, and anything else that you think might affect anything.
2) Buffer size you are generally using on projects.  (For me, anything over 256 in logic causes serious problems)
3) wether this EVER happens when used in stand alone mode.  (THIS IS A BIG ONE) 
4) the state of totalmix when the issue occurs
5) state of the status LED on the FF when the issue occurs
6) sync setup when the issue occurs (is the FF master or slave, are you using DDS, what is the master?)
7) the length of the firewire cable you are using between your FF and your computer
8) if you are daisy chaining any devices in line with your FF
9) environmental conditions when using the FF
10) wether phantom power is in use on the FF when the issue occurs
11) sample rate and bit depth of source material at the time the problem is encountered
12) ANYTHING ELSE, NO MATTER HOW TRIVIAL IT MAY SEEM.

My guess is that if we already knew all of the info I listed above, there would surely be a common thread, which is the first step in finding a solution.  I'm sick of people bitching about things on a forum asking for non-specific help before they have explored every possibility.  The point of a forum is to bring people with similar experiences together and come up with a solution to said problem.  Instead, people come here and randomly complain without providing useful information as to what might be causing the problem.  NOBODY KNOWS HOW TO FIX YOUR PROBLEM unless you are PERFECTLY clear about what exactly your problem is and under what conditions it has occurred. 

We are ENGINEERS, it's our job to troubleshoot until the problem is solved.

We know that most people around here are AUDIO engineers, not computer engineers and that is where the problems begin. What qualifies an audio engineer to setup a complex computer system?

Most audio engineers have at max computer knowledge comparable to first level support, some comparable to second level support. They are simply not qualified to solve complex computer related problems. People seem to be thinking: "Hey, I can master a desk with dozends on buttons and faders, complex routing throughout a studio and connecting myriads of 19" effects. This computer stuff is just Playdo for a bad-*ss engineer like me."

Frankly, many engineers would be better off with outboard gear that comes with big knobs and push-buttons instead of aiming around with a mouse. Even an academic grade at electronics or physics doesn't help you much with computers if you lack the in-depth experience and especially understanding that with computers some issues can be quite "illogical" (think of a car's engine choking because of a broken light bulb).

But in the end it all comes down to money...:cool:

fryingpan undercode mate :-) no worries about it...

Just a question: Why do you use the Fireface with iTunes? Why don't you try to use the built-in audio interface, routed into the Fireface?

Cheers.

Nope. Means that only the normal apps (iTunes, Safari, VLC, etc...) will use the built in output. Logic, Live and more will use the Fireface.
This is what I have in my studio.

Cheers.

I do understand what you mean and generally agree with you. But I question your qualification as an "audio engineer" when it comes to complex computer issues. You know the saying: Jack-of-all-trades, Master-of-nothing!?

The same time you spent on learning how to recap those consoles and calibrate those tape machines others spent on learning how to identify a mousedriver to be the source of harddisc problems. It's a matter of experience and specialized knowledged once the real difficult to identify issues come up, just like with every other profession.

Your list is a very good starting point to discuss the buffer-loop with everyone willing to spend time on this (including me). But for someone who wants to get rid of this the best way is to take some money into their hands and call an expert. Just like you would do with a broken water-pipe. fryingpan

These people then look at things like:

- Which GPU, WLAN, LAN, HD, mouse, USB and FW devices are being used and what drivers are installed for these. Does turning off these devices have an effect, if so does the specific driver offer any particular settings that can help circumvent the problem.

- Which processes are running in the background and does any of these access hardware components on a regular basis?

- What do processes and threads actually do under the hood when the problem arises.

- On Windows specifically: How is DPC Latency behavior, does Write-Combing and mouse-pointer accelleration affect the issue, does ACPI Battery, AHCI HD or HPET affect the issue? Does it help to put particular prozesses' affinity to a specific CPU core (like with the Bootcamp KBDMGR.EXE driver). Does changing CPU priorities have any impact and how so.

etc. pp.

Something you sound guys can have a look at is whether any Midi devices are attached to your RME interface when the problem occurs.

I agree and gotta add: I identified my personal buffer-loop (beep) problem several weeks ago and RME already work on it (HDSP is fixed, FF still waiting for a fix). Source of the problem was not the RME driver, but by providing RME with a reproducible way of causing the loop they were able to identify an error within own drivers their crash-detection mechanism that is responsible for turning off the sound when a crash happens.

First of all the loop only happened on Windows when Live crashed/froze, not on OS X (sound turned off as soon as the crash happened).

One way to make Live crash is to change the plugin buffer size (by default set to the same value as the audio buffer size) with several NI plugins loaded (especially with Reaktor 5), but that is harder to reproduce than what I used for demonstration for RME. Version 7.0.10 had a bug that made Live crash whenever you copied a scene that included an "External Instrument" being linked to an external plugin.

I created a small Live set for Uwe and Martin that made Live .10 crash upon request and so they were able to identify the problematic crash detection within the RME driver. Unfortunately the changes are not part of the current FF driver yet.

No sorry, you are missing the point.  We must each be the master of our studio.  I have spent days upon days setting up every aspect of my studio as best I can for my workflow.  This involves modifying many aspects of my computer, both hardware and software.  I'm sure you are also familiar with the saying: The only way to do it right is to do it yourself.  Otherwise, how could you quickly correct bad behavior on the spot. 

If you don't understand the system, you cannot master it.  I have one trade, and that's running a studio.  Don't you think I had better be a master at it?  Every studio as a whole is a system, regardless of wether it's analog or digital, it is a logical system all the same.

When I was in school some time ago for a bachelors in audio engineering, the curriculum involved much more than learning how to record and make music.  Several classes were electronics classes, others were acoustical physics, and room acoustics.  Other classes involved creating web pages or DVD menus, even coding plugins!  Spare time was spent wiring up studios, installing drivers for new components, troubleshooting, fixing the broken communication between the digi-pres and the computer or fixing the routing in the 02r96.  Once I had to fix the Otari console with a client in the room and also had to figure out how to fix a pair of original Neumann bottle mics from the 20's after they had been exposed to too much humidity while sitting near a door that a client left open.

All of these are just examples of very expensive high quality gear failing and having to be fixed on the spot.  Knowing how to fix these type of things are acquired skills that quickly become part of the job.  BY NO MEANS did I walk into the studio knowing how to do any of this.  I learned out of necessity.  Do not look for an excuse to fail, look for a reason to succeed.

In every situation, examining ALL of the variables and considering ALL of the options is the only way (besides luck) to find solutions.  Hence, the listing of even the most minute detail.

Now, lets see those lists!  I am really eager to find a pattern in all of your scenarios.  I am sure we can sort this out.

Peace,
Brian

Don't assume that it's not a firewire comunication problem. When I had the beep on the Windows, on the Fireface Settings panel there were no errors counted and it still beeped.

Did you test the Fireface before the DP6 install and nothing else more connected (MyBook WD) ?

Cheers.

Safari 3 or 4?

What audio interface is set on Live and what's the iTunes audio interface (system preferences default)?

Cheers.

I always ask this because it was the source of my problems on Windows.

I had a friend who posted on this forum too with the same problem and had the problem solved with a clean format (Mac OSX).

Cheers.

OK, now I'm getting not even tired but totally depressed.
My conclusions :
- the loop thing occurs when something happens on the USB port. Knowing USB & Firewire share the same controller? it's easy to draw some conclusions.
-- the" no more sound" syndrom happens in 2 situations (I remind you guys that restarting the driver is enough, no use to switch off the FF) :
      - in Live 8 after a "certain time" and also if I ever decide to use the FF as the Mac's output
      - in DP 6 after a "certain time"

I've tried another Firewire setup, no luck. Again a clean install, nothing. Unpluging everything USB same thing. Well I'm out of ideas. PLEASE help before I decide to call my reseller and ask for a refund, if it's not too late?

Thanks for reporting back...

Regards
Daniel Fuchs
RME

Now this is an interesting read. Thanks for reporting back about the heat problem, especially about the kernel message. Wait a few days or weeks and see if things work smooth.

In my case, I can reproduce the problem. It often occurs, when I switch the view in EyeTV from full screen to window view. But in Logic, MainStage iTunes,... it occurs randomly without warning.

Right - I upgraded my macbook with the seagate momentus 7200rpm... cue ridiculous amount of heat + constant fans + beeeeeeeeep.
Problem also got worse when I use external monitor(?).
Will try the fan cleaning and report back.
Thanks