Yes, thanks. I thought that was clear with "latest driver" used. That included both the win driver and the firmware (ver. 130) as well :-)

EDIT: I just disabled USB-power saving -- which should not have kicked in, as the laptop was still running. But even when I never had a problem with that with my old audio interface with the power savings enabled. So I guess the problem lies somewhere else.

Danke für die Antwort. Wirklich happy bin ich damit jedoch nicht.

1) Knistern / Knattern

Ich möchte ehrlich gesagt nicht im Handbuch oder Foren nach Problemlösungen für USB-Probleme suchen müssen, um einfach ein neues Audio-Interface ohne Störgeräusche in Betrieb zu nehmen. Ich habe bisher schon an dem Laptop ein anderes Interface ohne jegliche Aussetzer betreiben können. Kann ich nicht davon ausgehen, dass ich das Babyface mit dem mitgelieferten USB-Kabel an den gleichen Rechner anschließen kann und es "einfach funktioniert"?

Ich habe inzwischen testweise das Babyface mit dem Originalkabel an einen hochwertigen powered USB3-Hub angeschlossen. Dort lief auch mein altes Audiointerface ohne Schwierigkeiten. Das habe ich getan, da ich aus Erfahrung weiß, dass es teilweise manchmal bei Geräten Probleme gibt, wenn diese direkt an einem USB-Port angeschlossen sind, aber über einen Hub diese problemlos laufen (nicht, dass ich an dem jetzt verwendeten Laptop je Probleme mit dem USB-Port hatte!). Zudem würde ich im Grunde das Babyface lieber am Hub betreiben, da ich über meinen Bildschirm (mit USB-Anschluss) so 2 verschiedene Laptops wechselweise benutze.

Eben gab es aber wieder Aussetzer / Störgeräusche. Diese waren sogar noch heftiger als gestern und traten im laufenden Betrieb auf, also nicht nach einer "Idle-Pause" des Rechners. Mir ist dabei nun etwas aufgefallen. Sowohl gestern wie auch eben als die Probleme auftraten zeigt mir das Babyface "DIM" aktiviert an, ohne dass ich das selbst am Interface oder in TM gemacht habe! Das war mir gestern schon aufgefallen, aber hatte ich nicht weiter beachtet. Aber das scheint kein Zufall zu sein. Das Babyface verzerrt irgendwann den Ton und gleichzeitig ist DIM aktiviert!???

Ein weiterer Hinweis auf Probleme mit dem Audio-Treiber ist noch, dass ich gestern beim Abziehen des originalen USB-Kabels vom Laptop einen Bluescreen bekommen habe. Der Laptop läuft sonst ohne Probleme und ich bekomme sonst keine Bluescreens! Da scheint mir in der Tat ein Problem mit dem Babyface und / oder dem Treiber vorzulegen! :-(

Aktuell habe ich das Babyface nun mit dem "alten" USB-Kabel (welches mit dem alten Audiointerface einwandfrei funktionerte) wieder direkt an den Laptop angeschlossen und beobachte weiter, ob das Problem nun gelöst ist. Dann wäre ggf. das mitgelieferte USB-Kabel nicht in Ordnung.

Gibt es einen Debug / Log-Mode oder ein Verzeichnis in dem man ein Logfile finden und an den Support schicken kann?

2) CC-Mode unter Windows

Sicher ist das kein "Must-Have", dass der CC-Mode unter Windows funktioniert, solange es dafür funktionierende Treiber gibt. Allerdings muss ein Kunde doch davon ausgehen, dass Unterstützung von CC-Mode genau das bedeutet, dass auf egal welchen Geräten die mit Standardtreibern Audio unterstützen das Babyface auch genutzt werden kann. Da Windows prinzipiell auch Audio-Geräte ohne extra Treiber unterstützen kann, verstehe ich nicht, warum dies für das Babyface nicht der Fall ist. Was ist der Grund?
Würde das Babyface den CC-Mode korrekt unter Windows unterstützen hätte ich jetzt z. B. die Möglichkeit mit dem CC-Betrieb einen Gegencheck zu machen, ob das Babyface so fehlerfrei läuft. Zudem könnte ich das Babyface auch an Fremdrechnern mal eben schnell anschließen, ohne einen Treiber installieren zu müssen. Das wäre auch ein Mehrwert mit dem ich gerechnet hatte.

Im entsprechenden Kapitel des Handbuchs über CC-Mode, findet sich kein Hinweis darauf, dass (und auch wieso) der CC-Mode nicht unter Windows funktioniert. Im Gegenteil, indirekt wird schon der Anschein erweckt, dass der CC-Mode auch unter Windows unterstützt wird (S. 89, Abschnitt 32.2).

EDIT: habe im Handbuch an anderer Stelle (S. 14) nun gesehen, dass dort der CC-Modus für Windows als nicht funktionierend beschrieben wird. Das sollte zumindest auch noch dazu im entsprechenden Kapitel vermerkt werden... :-) Wobei ich ehrlich gesagt lieber einen unabhängig vom Betriebssystem funktionierenden CC-Mode hätte!

CC-mode is not for Windows, this was my first thought, but after having a look into the user manual page 89 I decided to ask you about the firmware.
The user manual has a chapter about CC-mode on windows, I was very surprised, it makes no sense.
The problems here with crackeling noise looks to me like typical windows Pc problem.
If you have the chance to connect the Babyface to a Mac and do some tests you probably can sort out the Babyface as issue.
Sorry for making a mess in your thread, latest driver is also known as problem, by the date of publishing it's not always the latest driver.

Thanks Waedi. It's not a big problem that CC-mode does not work for Windows -- just surprising, because then I do not understand what "class compliant" means when a device which should work with the "class compliant" drivers (which Windows offers AFAIK) does not.

Regarding the crackling noise I'll monitor the situation further. I use two laptops. The crackling appeared on the newer one (much more powerful then the old one). On my almost 10 year old laptop the Babyface so far works without any glitches. Still strange that I got sometimes crackling on the newer laptop, but never had issues like that with my old audio interface (EMU 0404 USB). I even dit not adjust the USB energy settings on the older laptop and have set a much lower buffer size there. So I see no reason / explanation where the crackling comes from and even I got a bluescreen (on the new laptop) which is very likely related to the Babyface (driver)...!?

Regarding Mac. I'm personally glad I do not use Macs any longer (Apple changes the OS too fast -- without sensible reason and destroys compatibilty software and hardware wise and they are too arrogant IMO) and have currently no access to one.

Thanks mkok for your input.

I am a bit surprised about the answer. I explained that it is not a deal-breaker not to have CC mode working on Windows. But I simply do not understand what CC-mode means when it shows that the device is not fully class-compliant (compatible). Please read the post of Matthias (quoted by me above) when introducing CC-mode for the original Babyface which clearly shows that my expectation that "class-compliant" would mean just that is nothing strange! I also mentioned two use cases where CC-mode would be beneficial to have under windows.

Last I do never reinstall Windows, but take care not to clutter up my installation. I run my windows installations for years without any problems. And why should I not expect the Babyface to work flawless on a laptop which never made any similar problems with  another audio interface (old EMU 0404 USB, in that case even with drivers never meant for Windows 10)!? In my case now I even can not make a new windows installation, because that laptop is a company laptop, but where I still need to use the Babyface for various tasks! I am not doing Pro audio work, but still want / need to benefit from Babyface/TM features and of course expect to be able to use a "rock-solid" audio device on a computer which otherwise does also work totally fine with audio tasks with the simple built in soundcard or an external USB audio sound card.

In addition I read the manual, searched the forum here and on the internet in general and followed all tips - still had occasional crackling appear. :-(

I find it strange that the RME followship is in such a way that it appears that it must not be questioned if there could be a problem with an RME driver!? ;-)

Some questions upfront
Do you run on battery with the Laptop or does it also happen when the Laptops PSU is active ?
Is the BBF Pro powered by USB bus or do you use a PSU ?

Regarding the Windows installation
What release of Win10 ? 20H2 ?
Is this a system preinstalled from factory ? Some preinstallations are pretty bad.
Some tools are programmed bad and can have impact on the performance.
Typically such add-on tools to check for BIOS or driver updates, fan control, battery control.
I know this from a friends Lenovo Laptop, the factory installation sucked performance much, so that even the mouse moved reluctantly. And the built-in SSD chip which should act as Hibernation and Harddisk accelerator was badly installed. Missing driver and wrong sizing to be able to perform both tasks and to speed up disk accesses.
Did you use tools like O&O Win10 Shutup to disable not required background services and transfer of telemetry data / user behaviour ?

Before making any changes to the system:

a) Try to find out with which simple reproduceable steps you can trigger the issue to be able to measure, whether a certain change solved the issue or how much better or worse things became by this. It needs to be reproduceable and measurable to come to good findings and solutions.

b) Make a backup (disk image) of the windows installation first, recommended here is Macrium Reflect 7.3, do not get 8.0 it's too fresh was just released and has the typical ".0 release" issues.

As mkok noticed: measurings with LatencyMon can be very useful should this have to do with certain drivers that block a CPU core for too long.

You could try the following usual things
1. Check in the RME driver settings whether you have USB transport errors.
2. Try a different USB cable for comparison to be on the save side, that this is no cable problem (unlikely here but try)
    Check cables and connectors has always been a good advice in the long history of IT..
3. try all USB ports on your PC to catch all possibilities (ports from chipset, ports from 3rd party USB chip)
4. does it make a difference if you use a higher ASIO buffersize?
5. check whether the energy profile "High Performance" gives more stability
6. make adjustments to the energy profile:
    - disable Diashow
    - disable selective USB power saving
7. if running USB bus powered, then try whether a power supply gives more stability
8. If Destop PC (here "Intel BIOS notation", for AMD the naming is different=
    try disabling C-States (either disable or set to C0/C1)
    try disabling EIST to achieve a stable non changing clock, but set TURBO then you get usuall 100-200 MHz higher clock
9. Disable CPU core parking for the power profile (can be performed differently, easiest with ParkControl from Bitsum)
10. Give the Processes a fix & longer time quantum to work more efficiently on all processes, to reduce context switches
    In the enhanced system settings change Processor scheduling to "Customize optimal performance for background services"

Some of these tips address hopefully the specific problem, some are generally useful. I would in a 1st round only try whether ONE of these options make a difference to get an idea whether changes in a certain area change, mitigate or even solve the issue.

But its not always guaranteed, that a single change does the trick, in the next round I would perform all changes, sometimes the sum of all changes solve an issue.

In a bad case of luck your Laptop does not work well.

The difference with such a RME interface is
- has usually a higher amount of channels, so more audio data needs to be transported per time interval
- RME uses potentially other more performant USB transfer modes and something in the laptop does not perform this well
because also chipsets can have issues ..

Create a vanilla reference installation with minimum amount of drivers and software and compare ...
Either on a separate external SSD with only the Microsoft drivers and the most important drivers for the laptop
- chipset driver
- keyboard / mousepad driver
- USB3 driver (if any needed)
- network drivers LAN/WLAN
- display driver
- RME driver

If you have a quick backup disk then you can also quickly change between two different Windows installation by quickly restoring the one or the other disk image. Macrium Reflect can do this very well.
Macrium Reflect has here a very unique feature called Rapid Delta Restore.
On my system it takes only 4 minutes to restore changes between today and yesterday on a 1TB SSD filled with 700GB data. A full restore takes otherwise 1h15, so this saves me 1h10 !! It's a great feature.
Also very useful to reliably get rid of installed software that turns out to be problematic or that you do not want.

Good luck, something like this is always a nasty problem and Windows as well as Apple are not designed as real-time operating system. BIOS and driver quality is always challenging for audio related processes with near-realtime requirements. He it seems to be even a special case, as this seems to happen over time. So I am curious whether it has something to do with Energy settings and USB power saving settings or to get a dedicated PSU for the BBF Pro or not ...

So, ich bin langsam sauer. Mit meiner alten Soundkarte hatte ich keine Knackser oder dass der Ton komplett wegbleibt (nur noch knacken zu hören ist). Mit dem ach so stabilen Babyface Pro kann ich nun nie wissen, ob ich etliche Stunden oder ein paar Minuten ohne Aussetzer Audio abspielen kann!

Es kann auch nicht sein, dass man Stunden mit Testen und allem möglicher Fehlersuche verbringen muss. Mir reicht es jetzt echt. Wo bitte schön ist die vielgelobte Stabilität der RME-Treiber, wenn meine Uralt-Soundkarte mit einem uralten Treiber diese Probleme nicht macht, aber das Babyface schon!?

Ich hab' nun alle möglichen Einstellungen (Engergiesparoption, CPU throttling usw.) getestet -- alles ohne Erfolg. Ja, der Laptop meldet mit Latency Monitor, dass der Laptop nicht für Audio-Ausgabe geeignet ist. Aber ehrlich gesagt habe ich das früher nie bemerkt und testen müssen! Sooooo spannend und anspruchsvoll ist eine Audioausgabe auf 2 oder mal 4 Kanälen jetzt auch nicht! Wieso bleibt der RME-Treiber dann stellenweise so total hängen, dass gar nichts mehr geht? Ich rede nicht von mal einem Aussetzer -- die auch auftreten, sondern andauerndem Knacken / Knittern, dass man nur über einen Neustart des Interface beheben kann. Manchmal hilft auch, wenn man einen anderen Ausgabekanal wählt (also z. B. Ausgang 3/4 anstatt "Speaker") und dann wieder zurück schaltet. Wenn das nicht hilft kann ich das Babyface komplett von USB trennen und neu verbinden. Dann klappt es wieder -- bis zum nächsten Fehler (nach Minuten oder Stunden).

Teilweise zeigt das USB Fireface Settings Fenster dann Fehler an (0/5 oder 0/10), aber teilweise treten die Dauerknackser auch auf, wenn kein Fehler angezeigt wird. Eben habe ich zum Beispiel "gewagt" Audioausgabe bei Spotify zu stoppen und dann über Youtube ein Video abspielen zu wollen. Das war dann offensichtlich für den Treiber schon zu viel!

Wie weiter? Ein "tolles" aber teures Interface gekauft und Probleme, die ich sonst nie hatte dafür bekommen.

@ RME: wenn ihr mal einen echten Betatester braucht, man muss mir nur die Sachen zukommen lassen. Wenn es Fehler gibt, so stolperere ich da leider recht zuverlässig hinein!

Wie schön, dass der Rechner Schuld ist und die RME-Treiber fehlerlos sind. Wenn ich gerade mal 2  oder 3 Kanäle von 12 gebrauche (sowohl beim EMU 0404 wie beim Babyface) erwarte ich, dass ein Gerät mit aktuellen Treibern nicht mehr Probleme verursacht als ein wirklich veraltetes Gerät.

Der fragliche Laptop ist ein Arbeitsrechner, den ich leider nicht in allem beinflussen und konfigurieren kann. Der Rechner ist sicher nicht der optimale Audio-PC, aber trotzdem erwarte ich, dass ich dort genauso wie mit meinem Uralt-Interface einen Stereokanal abspielen kann und ggf. noch einen Mikro-Eingangskanal gleichzeitig nutzen. Wieso ist dann (allein) mein Rechner "Schuld", wenn es mit einem anderen alten Interface funktioniert aber mit dem Babyface nicht!? Sorry, der Logik kann ich nicht folgen.

Ich bitte um sachdienliche Hinweise oder einen funktionierenden Treiber der mir diese Basisfunktionen des Babyface ermöglicht.

Zu den eindeutigen Hinweisen: Sie hatten gelesen, dass nur teilweise Fehler im Settingsdialog angezeigt werden? Das ist also nicht konsistent der Fall. Eben hatte ich nur noch Dauerknacksen / Knistern (hab' es über das Handy aufgenommen, aber ich vermute sie wissen wie sowas klingt krkrkrkrkrkrkrkrkrkrkrkrkr....) und _keinen_ Fehler im Settingsdialog. Nur ein Reset des Babyface hilft. Das zeigt doch deutlich, dass der Treiber und / oder Hardware nicht so stabil laufen wie erwartet.

Ich hatte auch verschiedene USB-Ports, Kabel usw. getestet (siehe oben in den Beiträgen).

Finde es sehr schade, wenn man als Käufer / Nutzer hier nicht ernst genommen wird und die Antwort -- "dann musst Du halt schauen wo _dein_ Rechner schuld ist." bekommt. Es ist komplett unlogisch alles hier auf den Rechner zu schieben, wenn ein anderes -- noch dazu altes Interface mit alten Treibern -- mit dem gleichen Rechner keine vergleichbaren Probleme zeigt!

Ich "mockiere" mich nach einer Woche Testen und Probieren von allen möglichen Lösungsvorschlägen. Wenn Sie ein Gerät kaufen was so hoch gelobt wird und dann nennenswert Zeit damit verbraten müssen es zum Laufen zu bringen -- wo andere Geräte die Probleme nicht zeigen -- wären Sie dann nicht auch irgendwann mal genervt?

Ich hoffe / denke, dass mein Tonfall nicht unhöflich war oder ist. Aber ohne Frage, begeistert bin ich in der Zwischenzeit nicht mehr und sicher kann man das auch merken. "Mockieren" heißt sich über etwas lustig machen. Mache ich mich lustig, wenn ich genervt bin, wenn ich anmerke -- wie auch in Ihrer Reaktion zu entnehmen -- dass die sooo stabilen Treiber hier leider nicht so zuverlässig laufen? Entschuldigen Sie den Ausdruck. Das war nicht böse gemeint.

Aber meine Entscheidung für ein mehrfach teureres Interface als die Alternativen war maßgeblich beeinflusst von dem Gedanken "es läuft einfach" und "wird lange unterstützt". Den ersten Punkt habe ich nun leider nicht.  Wenn mein Arbeitsrechner nicht optimal für Audio konfiguriert ist (mit Antivirensoftware oder was auch immer man da halt so drauf haben muss), so hätte ich noch absolut Verständnis dafür, wenn es mal einen Knackser gibt, wenn sich die Audio-Ausgabe verhaspelt -- wegen der ungünstigen Konfiguration. Aber ich habe kein Verständnis dafür, dass sich der Audio-Treiber offensichtlich komplett aufhängt. Und genau das passiert hier ja wohl. Wieso würde ich sonst Dauerknacken hören bis ich das Interface zurück setze!? Auch der Treiber für das integrierte Soundinterface macht keine vergleichbaren Probleme auf dem Rechner! Wäre der Rechner als solches Schuld, dann müsste auch ein "oller" Realtek-Treiber mindestens die gleichen Probleme haben / verursachen, oder nicht!?

Meine Feststellung, dass ein Umschalten auf einen anderen Babyface-Kanal das Knacken verschwinden ließ, aber auf "Babyface Speaker" beim zurückschalten weiter hörbar war, kann den entsprechenden Kollegen bei RME ggf. einen Hinweis geben wo beim Treiber (oder Hardware) da etwas schief laufen kann!?  Ich hatte auch schon gefragt, ob es einen Debug-Mode gibt oder ein Log-Verzeichnis, aber darauf auch keine Antwort bekommen. Vermutlich dann nicht. Da hätte ich ggf. genaueren Input liefern können, _wenn_ man interessiert ist einen Fehler zu finden und zu beheben.

An meinem alten Laptop betrieben bin ich mit dem Babyface und den Möglichkeiten von Totalmix sehr zufrieden und wünsche mir das auch auf dem Arbeitsrechner sein zu können!

Danke für die Erklärung. Bisher wurde noch nicht deutlich gemacht, dass ein USB-Interface immer alle Kanäle überträgt und das ein Grund sein kann, wenn ein Interface mit mehr Kanälen Probleme verursacht, die eines mit weniger Kanälen nicht verursacht. Dann kann ein Nutzer auch nachvollziehen, dass der Fehler ggf. in der Tat mehr oder allein beim Rechner zu suchen sein kann.

Ich habe nicht gesagt, dass RME Hardware oder Treiber als solches "mies" sind. Jedoch finde ich es seltsam, dass die Möglichkeit auf Fehler / Unsauberkeiten beim Treiber oder Hardware kategorisch ausgeschlossen zu werden scheinen. Natürlich weiß ich nicht, ob Sie 100, 100.000 oder 100 Millionen Babyface verkaufen und wie hoch die Prozentzahl der Leute ist die Probleme haben. Meine Stichprobe ist klein und da tritt der Fehler bei 50% auf...

Ich habe allerdings durchaus noch von mehreren anderen Leuten Berichte gefunden die unter Windows ähnliche Probleme wie ich haben. Zum Beispiel hier jemand der auch Probleme hat, die nicht gelöst wurden (und im verlinkten Video melden sich noch mehrere Leute die ähnliche Probleme haben):

https://forum.rme-audio.de/search.php?a … r_id=32977

Wenn ich das richtig sehe, so traten die Probleme dort "nur" mit Windows Audio auf und nicht über ASIO. Ich hatte das "Bit-Crushing" (so heißt das wohl) bzw. das "hängen" des Treibers auch mit Windows Audio. Ich nutze auf dem Firmenlaptop keine ASIO-Anwendungen und habe also nicht den Vergleich, ob es da Unterschiede in der Stablität der Audio-Ausgabe zwischen Asio und Windows-Audio gibt. Aber falls tatsächlich die Fehler "nur" mit Windows Audio auftreten, kann das auch eine Erklärung sein, dass nicht soooo viele Leute von Problemen berichten, da die Interfaces überwiegend für Musikproduktion usw. mit ASIO eingesetzt werden. Dann kann ein Problem mit dem Treiber für Windows Audio ggf. erst später oder weniger häufig auffallen.

Ich denke daher nicht, dass aktuell ein Problem mit dem Treiber sicher ausgeschlossen werden kann!?

Wenn es Möglichkeiten gibt das zu verifzieren, teste ich das natürlich "gern". CC-Mode wäre hier u.a. hilfreich.

Was ich auch nicht verstehe, warum eine mögliche schlechte Audio-Eignung des PC für andauernde Aussetzer verantwortlich sein soll (nicht einzelne Aussetzer!), die erst nach Reset des Babyface verschwinden. Das deutet aus meiner Sicht doch auch eher auf ein Treiberproblem hin.

EDIT:
@ramses: Thanks for the many suggestions! :-) I see I missed to test one option ("background process optimization"). I just have enabled that and will see if that fixes the problem. Hard to tell, because I need to wait till / if I get problems, because they turn up so randomly -- after hours and sometimes after minutes.

Hallo Angel,

auf dem Rechner auf dem ich die sporadischen Probleme habe sind keine Tools für Fan-Control aktiv. Die Probleme sind so weit zeitlich auseinander, dass sie sicher nicht mit CPU/GPU Temperatur zusammen hängen, da ich da zwischendrin auch teils höhere CPU/GPU-Last habe ohne Probleme. Da denke ich nicht, dass ein Zusammenhang besteht.

Unsere Probleme könnten ähnlich gelagert sein, aber bin mir nicht sicher. Bei mir äußern sich die Dropouts nicht "zunehmend" und auch nicht mit vielen Fehlern in den Fireface Settings. Teils ein paar, teils keine...

Bei mir läuft es soweit meist o.k., ab und an mal ein Dropout / Knackser. Den nehme ich auch nicht übel, da das System mit Firmenvirenscanner und was weiß ich wie konfiguriert ist und ggf. dann wirklich nicht optimal für Audio-Ausgabe ist. Was ich nicht akzeptabel finde und selten, aber bisher immer mal wieder auftritt, ist dass der Ton dann andauernd von Knacksern durchsetzt ist. Das kann recht leicht sein, so dass es über dem Audio-Signal drüber liegt. Teils ist es auch ziemlich heftig und man kann das Audio-Signal kaum noch "verstehen" und ich hatte auch schon den Fall, dass nur noch Dauer-Knackern zu hören ist und das Audio-Signal gar nicht mehr hörbar durchkommt. In allen Fällen tritt ein bestimmter Zustand dann für mich zufällig ein -- und bleibt auch unverändert ohne Besserung oder Verschlechterung. Es hilft teils noch Umschalten auf eine andere Audioausgabe und zurückschalten auf "Lautsprecher Babyface". Kam aber auch schon vor, dass das auch nicht geholfen hat und ich musste den USB-Stecker vom Babyface ziehen und neu verbinden.

Ich hab' jetzt "zig" Optimierungen (siehe den ganzen Thread) gemacht und muss abwarten, ob / wann es wieder auf tritt. Mir scheint aber der Treiber unter Windows doch etwas empfindlich zu sein. Das entnehme ich auch aus anderen Meldungen hier im Forum und auf anderen Webseiten wo Leute ähnliche Probleme habe.

Tritt der Fehler bei dir auch im Asio-Betrieb auf? Bei manchen ist das nur bei WDM (Windows-Audio) der Fall. Ob bei mir ASIO fehlerfrei auf dem fraglichen Rechner laufen würde weiß ich nicht, da ich beim Firmenlaptop keine entsprechenden Anwendungen nutze. Auf meinem privaten Laptop nutze ich WDM und ASIO und habe dort -- mit viel ältererer Hardware und ohne irgendwelchen "Optimierungen" wie oben genannt gemacht zu haben, keine Probleme.

Doch, darauf habe ich in meiner Antwort am 27. hingewiesen.

"Kategorisch" hat niemand gesagt, aber Sie können schon auch auf unsere Erfahrungswerte zählen - diese erleichtern Ihnen sogar die Fehlersuche...

Doch, ziemlich. Sie haben auch mehrere eindeutige Hinweise auf Probleme mit Ihrem Laptop (Latencymon, USB-Errors). Wieso ignorieren Sie diese konsequent?

Nein, CC würde hier nichts ändern. Es gibt einen funktionierenden WDM-Treiber.

Das Ihnen das allein nicht ausreicht, um klar zu erkennen, wo das Problem liegt, wundert mich ehrlich gesagt ein wenig...

Despite following those tips posted above (thanks for taking the time Ramses and the others) the errors still occur.

The audio driver "hangs" sort of. I checked and _no_ errors are reported in the Fireface USB settings. The problem is the sound is distorted ('bit crushing' the correct expression for that!?).

And again when I change the audio output from "Speakers (Babyface Pro)" to another output of the Babyface, it does not matter which, for example ADAT/SPDF, the audio output is not distorted any longer. As soon as I switch back to "Speakers (Babyface Pro)" the audio output is distorted again.

This is to me a clear sign that the driver must be involved somehow, because if the PC configuration / USB bus load or whatever would be the cause alone the distortion would appear on all output channels. But I can switch back and forth between distortion on "Speakers" and no distortion on the other outputs.

I have made a video with the distorted sound and showing that this is fixed on the other output channels and could upload that if that is helpful.

The only fix working is disconnecting the Babyface from USB and reconnecting. Again with _nothing_ changed otherwise on the PC side. So this is another indication that the driver (and / or Babyface firmware) _must_ be the problem or at least part of the problem!

https://youtu.be/d0unb4zTB1E

Here the upload of the video. It's a bit silent, as I recorded that at night (so low volume) just with the mobile phone.

UPDATE:

Unfortunately I have to report that the exact same problem has appeared now on my other computer (the older laptop). There are no error messages shown. The problem is the same that the sound is distorted on the "Speakers (Babyface Pro)" output. I have not found a work-around so far to reset that, besides restarting the Babyface! :-(

UPDATE 2 - Addition (2021-06-07): I already had the impression that the "stuck" audio seems to be slowed down more or less. See also the video linked above. But I was not sure. I just again experienced the distorted audio and found that indeed the complete timing is wrong then. I'll upload a second video where one sees that (in that case) the time is stretched by a factor of about 4.

The passage from the german manual is a bit outdated technically. Still, you wouldn't want sytem pings and beeps to disturb while editing,but that's just a general recommendation and has nothing to do with the problems described here. "Speakers" is just Windows nomenclature and does not affect device behaviour.

Your problem sounds different than mine. I tried different USB cables btw and am using the original one now.
The problems I have do not appear always, but random. Your dropouts and clicks were always there?

Your explanation here is a third variation which is not clear from the manual. So, does setting the default audio device to "Loudspeaker - Babyface Pro"
a) not work reliably (that's the statement of the german manual)
b) not work reliable when using ASIO audio (english manual)
c) is well working, but one just should deactivate system sounds to be sure not to get those sounds when not wanted (while recording and the like)  ???

What is then the difference between choosing the different RME outputs? All outputs give a signal on the headphone / line outs (3/4), where I have my loudspeakers connected too.

This does not make sense IMO. Why can you be sure that the interface hardware / firmware and / or driver is faultless?

1. Latencymon reports problems on one PC, that's right. But then I would expact latency problems (which I dont have). But instead the audio is distorted and the audio driver seems to hang sort of, because resetting the Babyfacer or switching to another Babyface output gets the audio correct again.
2. On the second PC I now had the same problem (so far once). No errors reported from Fireface USB and also no problems with Latencymon reported.
3. Even when a problem does not appear often it is not stated that this must be a PC problem. One reason: the user base of RME interfaces is likely relatively small for the usage of WDM audio. Most will use it only or mainly with ASIO applications. So problems with Windows WDM audio can be hidden possibly longer.

Here a video which shows very clear the problematic behavior. Note that the audio timestretch does not seem to be consistent. In that example it was about a forth of actual speed:

https://youtu.be/Zg95TNaGooI

So, what can I do now after following all the suggestions here and in the manual?

Unfortunately it is not a problem which is isolated to Firefox. I just had similar problems again when Firefox was not running, but I changed the buffer size, while S-Gear was open. That messed up the audio again. Closing all programs which have audio and restarting them fixed the problem. So with Firefox there seems to be a higher chance of problems and I think there is a bug in Firefox. But the RME driver seems to have a problem with the buffer settings. Either a bug / problem in the driver itself or a missing (or not fully working) error handling of the driver in case the audio application screws something up somehow and / or a communication problem between the driver and the application?

There is no "error handling". No audio driver can fix what comes from the application, or whatever goes wrong there.
Are the issues you demonstrate with Youtube playback reproducible in Chrome or Edge?

I assume that if your ideas of "error handling" worked the way you imagine for audio transfer, our developers would have found time to implement that at some point in the past twenty years.

I'm afraid I still see no reason to assume there is any general issue here beyond your individual system setup. To assume it could be that there's just insufficient number of users doing WDM playback for such issues to have been notices isn't very realistic, sorry.

That said, I can happily change buffers while playing YT on Firefox with my rather slowish Acer laptop here without even so much as a hiccup.

Vague ideas of what "error correction" is/means or might/should/could do in the context of audio drivers really won't help here. No audio driver can "correct" or fix performance related audio playback issues or the like. That's simply not something that can be expected.

As for the issue with buffer size changes, I can (not totally reliably) reproduce it in some cases (like when changing to a lower value), but that's Windows audio getting confused, not something about an individual computer's performance. But also not something that a driver can "fix" or correct just like that.

Also see https://forum.rme-audio.de/viewtopic.ph … 25#p141125

Hello!

@rpnfan
I can play my (off-line) games, fine, with a WDM Device, even at 32samples@48KHz, with my DF Usb!

Your "problems" seem to lie when you are using apps that require streaming. Youtube, facebook etc. It's, only, logical to assume that you cannot change buffer size, without experiencing some kind of drop-out or glitch, when someone uses these kind of apps.

These apps, also, use their own buffers in the background. Even if you close the app, it takes a bit for the buffer to get emptied. That process requires an x amount of CPU. That amount of CPU results in extra "burden" for the CPU to process. And when you have a small buffer setting in the audio driver settings, this might result in an audio "hick-up".

What I 'm trying to say is, that it is application specific! It depends on how each app is coded! There doesn't need to be any specific mention, in the manual, for that. It's simple logic, I think!

In Reaper, for example, I change buffer sizes, all the time! 128 when recording my guitar tracks with IRs, 1024 when mixing and mastering!
In the middle of the project! And not a single glitch!

Try changing buffer sizes when the "industry standard" Pro-Tools are running....

So, it's not something that RME could/should fix!

You 're welcome!
You 're right, I didn't re-read the whole thread, because some portion is in German and I don't speak German, unfortunately!

Just to be clear, using the "" wasn 't ironic! I, just, wanted to point that I didn 't think that it 's a BF Pro 's driver problem. Not that it 's not a problem for you!

I mentioned Pro-Tools, because many big studios and composers use them. I, just, wanted to say that even with that kind of a scale of an application, error handling is not tackled well. The issues you are experiencing are application-specific!

I, actually, think that these issues are windows or Firefox related!

For example, in your video, if you had used TotalMixFX for changing Outputs(routing Software Playback AN1+2 to SPDIF Outputs), the video would have been played back, normally!

I don't know if that is possible, because how could a driver be aware that a video's playback rate is slowed down or whatever other issue? If it 's the fault of an application and/or system configuration dependent?
The driver is not self-aware of how it 's used!

I don't know if that is possible, because how could a driver be aware that a video's playback rate is slowed down or whatever other issue? If it 's the fault of an application and/or system configuration dependent?
The driver is not self-aware of how it 's used! 

It's not only that the video playback is too slow. Also any audio output is then distorted. And resetting a driver (restarting the service) is nothing which can not be done.

https://en.wikipedia.org/wiki/Exception_handling
Some exceptions, especially hardware ones, may be handled so gracefully that execution can resume where it was interrupted. 

I do not know if that is easy to achieve here or not, but it's surely not something which is impossible. When I reset the Babyface everything works fine. So resetting _is_ an option. The question is if in the case of problems when changing the buffer size there is an exception thrown or not. If yes the fix is very close. If not then an alternative approach would be needed. For example possibly the communication to the Babyface is also not normal after the error occurs and can be tested by the driver!?

What about the other people who also experienced problems which seem to be related to changing buffer sizes!?

I hope you add the question / answer (buffer size changes -- effects) as one possible problem to the handbook like suggested. That would have saved me much time instead of trying to "fix" a PC problem which was not there (I am talking about this problem described here and not random dropouts which I understand can happen with a not well-configured PC).

Both these do not support multiclient WDM, multiclient ASIO and mixed multiclient ASIO/WDM with multiple I/O channels. For that reason they also don't (or don't have to) initialize their WDM devices on sample rate change.

We will definitely not change the way our driver works, sorry.