Ich weiß nicht ob ihr das mit den Knacksern gelöst habt, bei mir half folgendes:

Am Mixer stand ADAT Sync auf Intern Clock. Beim Madiface(Treiber des Digiface/Babyface) ebenfalls. Hab den Sync des RMEs auf extern 1/2 gesetzt und nun sind keine Knackser mehr zu hören.

Das ist ein anderer Fall.
Da gab es ein clock Synchronisierungsproblem, beide waren auf Master gestellt, klar, dass das in die Hose geht.
Siehe hierzu auch meinen Blog-Artikel, der Clock-Synchronisierung zum Thema hat:
https://www.tonstudio-forum.de/blog/ent … ios-en-de/

Aber es ist vielleicht noch einmal ein guter Hinweis darauf, in diesem konkreten Fall
   "Babyface Pro über USB angebunden"
zu überprüfen, ob in den RME driver settings clock Source auf "internal" steht,
also das BBF Pro Clock Master ist.

LatencyMon reports latency in the internal processing on your PC.

This is not an audible latency, but a latency in processing, so that time-critical jobs like audioprocessing  cannot be processed in time.

The technical background of this is that Windows (also macOS) is no real-time operating system.
Different jobs run in parallel: drivers and other running programs (Programs, Services, GUI, ..).

Drivers are not under the control of the operating systems process scheduler.
They run with the highest priority on the system for ensuring "data integrity".
Figure out what would happen when data transfers would be canceled during transmission.
Data would be incomplete / corrupted.

Therefore drivers have to detach themselves from a CPU core.
The time, how long the driver can occupy a CPU core is hardcoded in the driver and can not be changed.
Its simply based on "programming conventions".
But as we all know, there are good drivers and there are bad drivers.
If such a bad driver stays for too long on a CPU core and detaches itself too late,
then this CPU core can not serve other processes that have been scheduled by the job scheduler of the operating system to run on that core.

Then this job has to wait until this particular core becomes free (until the driver detaches itself from the core).

If this time is too long, then audio loss can occurr.

LatencyMon issues a DAW load on your system and measures the resposiveness of your system, how fast CPU cores react on the DAW load.
This is the Latency that LatencyMon reports.
If this Latency is higher than 1ms then the system is reported to be not suitable for processing audio / real-time tasks.

But even if this value is a bit below 1ms higher values show, that your system can not react agile on a real-time workload and process audio as fast as possible.

Depending on the system load this means to you that audio loss will much more likely occur the closer you are to the 1ms "processing" latency.

You can compensate it up to a certain point with higher ASIO buffersizes, but not full, because a latency of 1ms or higher is simply too high for a system that has to process audio in near-realtime.

The higher the DPC Latency, the more the likelyness for audio drops and especially when using smaller (ASIO-) buffer sizes.Therefore

Am Mixer stand ADAT Sync auf Intern Clock. Beim Madiface(Treiber des Digiface/Babyface) ebenfalls. Hab den Sync des RMEs auf extern 1/2 gesetzt und nun sind keine Knackser mehr zu hören.

Real-time means here:

a) while the application is open
b) while the application is not only open, but also outputting an audio stream ?

rpnfan wrote:

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.

Resetting is not impossible, but for the driver to know or detect when a signal is "distorted" is not possible. Otherwise it might suddenly reset with audio signals that are intentionally distorted or sound as if they might be.

rpnfan wrote:

In the mean time I tested two other lower priced interfaces. None of both experience the same problem. So for me it is clear that the RME driver is not working as it should. Or why would it be "o.k." that the RME driver causes artifacts which other audio interface drivers don't!?

I see no reason to assume that the driver *causes* these issues. If so, it would have been noticed earlier...

I can somehow follow the first argument. The second is a very strange assumption. That would mean that after a while no bugs will be found!? Sure that's less likely, but surely not impossible. I do not think that most users change buffer sizes sooooo often. So that can well be an explanation that this might not pop up earlier. Also not everybody is reporting a problem and / or taking so much time to find out the reasons, like I (had) to do till now...
May I remind you that you were absolutely sure that the problem lies somewhere in my computers or their configuration, while I found several hints which suggested otherwise and it turned out that I was right that it is _not_ the computers or their configuration!?

Thanks for the explanation. I have the impression "we" might be getting closer to an answer. I was of course not asking to change drivers to support less functions! I experience a problem with an RME interface which I do not experience with other interfaces (3 tested so far). Of course one is expecting less / no problems with an RME interface when they are advertised with  "rock-solid" drivers. When the experienced problems are the result of a feature (one wants) and not a bug that needs to be explained and possibly also described in the manual and / or an FAQ. 1. Where it comes from 2. Solutions to solve it and / or if that is not possible for the end-user 3. name work-arounds or making aware when to expect those (potential) problems.

So do I understand it correct that you think that the problem occurs due a message the RME driver sends to an WDM application? Please note that you were talking about sample rate changes. This was never the case. All applications are set to use the same sample rate and never changed otherwise. What I change when experience the problem is changing the buffer size!

The Behringer driver supports multiclient Asio applications. I have not checked that for the Tascam interface and I do not have the two interfaces at hand now to confirm that although.
One difference between the RME and Tascam / Behringer drivers seems to be that the RME driver settings are applied both to ASIO and WDM applications, while it seems that the settings from the Tascam / Behringer drivers are only applied to ASIO applications!? If that is true why is it to be somehow "expected" that the buffer size changes done in the RME driver can or might mess up the audio playback in a WDM application? Where would that need to be fixed? Why does the problem occur most of the time (for me at least), but not always?

Second please note that I found the problem to be (mostly) reproducible with Firefox (thus a WDM application), but I had similar problems with S-Gear (Asio application) as well (see report above). Last not least I have found several posts from others which also seem to be related to changing the buffer size. So it seems very much possible to me that there is somewhere something not o.k. with the driver related to the buffer size switching which can cause regular or (more likely) random errors under specific circumstances.

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.

Resetting is not impossible, but for the driver to know or detect when a signal is "distorted" is not possible. Otherwise it might suddenly reset with audio signals that are intentionally distorted or sound as if they might be.

I see no reason to assume that the driver *causes* these issues. If so, it would have been noticed earlier...

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

In the mean time I tested two other lower priced interfaces. None of both experience the same problem. So for me it is clear that the RME driver is not working as it should. Or why would it be "o.k." that the RME driver causes artifacts which other audio interface drivers don't!?

For reference I tested those two interfaces, which work flawless and none of them created any artifacts described above which I experience with the Babyface.

• Tascam 2x2 HR

• Behring UMC204HD

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).

And even when a non-RME program is not well-behaved a well written driver can somehow deal with such a situation. For example could a driver reset itself after experiencing that something went wrong -- even if that was caused somewhere else outside the driver or in interaction of a programm with the driver. I think that should be possible here too, because disconnecting the Babyface (thus resetting the driver in that way) can cure the problem.

If that kind of thing were possible, we'd have implemented it long ago. But that's not something an audio driver can do. The driver as such doesn't know whats "wrong".

First thanks for taking the time to comment. Although I am very much suprised about your statements. It seems you have not really read what I posted.

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 never talked about low buffer size itself and drop-outs or whatever. My problem is a real one and does not need to be set in ""! You missed that I have not glitches or drop-outs, but that the audio channel is completly messed up and audio plays either too slow or too fast, depending on the direction of the change in the buffer size.  You also missed that the problem does not appear only with WDM applications and also not only for streaming applications.

You confirm that changing the buffer size can and should be possible. 

Regarding the applications I use. I do not use Pro-Tools. Not everybody is using an audio device for similar applications.

And of course RME cannot fix problems which appear in a non-RME application. But I have seen in other threads that more people experience problems when changing buffer sizes. That is an indication that there can be a problem with the RME driver in that regard.

And even when a non-RME program is not well-behaved a well written driver can somehow deal with such a situation. For example could a driver reset itself after experiencing that something went wrong -- even if that was caused somewhere else outside the driver or in interaction of a programm with the driver. I think that should be possible here too, because disconnecting the Babyface (thus resetting the driver in that way) can cure the problem.

@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!