Re: Babyface Pro FS - Probleme (knistern / knattern)
Changing the buffer size is the same as sample rate - it is not supported in real-time with WDM, and some ASIO apps also fail with that.
Matthias Carstens
RME
You are not logged in. Please login or register.
RME User Forum → FireWire & USB series → Babyface Pro FS - Probleme (knistern / knattern)
Changing the buffer size is the same as sample rate - it is not supported in real-time with WDM, and some ASIO apps also fail with that.
Thanks for the clarification. Would be really great to add that to the manual / problem or Windows section. That would have saved me maaaany hours of researching, testing, reporting and so on...
Real-time means here:
a) while the application is open
b) while the application is not only open, but also outputting an audio stream ?
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.
I stumbled over one comment that I didn't read earlier.
Because its important for understanding the situation and LatencyMon I comment it now.
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.
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
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.
Ich konnte es jetzt mit Firefox und YouTube einmal nachstellen. Das Phänomen trat auf, wenn ich die Anzahl der WDM Devices änderte (erhöhte) und danach auch den Buffer Size. Den Sinn des Prozederes des OP verstehe ich allerdings überhaupt nicht. Warum braucht er sechs WDM Devices?
Warum muss man beim Abspielen von Web Videos den Buffer ändern?
Warum werden Videos in 48000 Hz produziert ;-)
RME User Forum → FireWire & USB series → Babyface Pro FS - Probleme (knistern / knattern)
Powered by PunBB, supported by Informer Technologies, Inc.