Hi!
Ich kenne das Programm nicht, aber die Problematik.
Ein Buffer soll ja Daten auffangen und aufbewahren, bis sie abgearbeitet werden. Ein Produzent (banal gesagt, Deine Soundkarte) füllt fleißig den Buffer und ein Konsument (Deine Audiosoftware) liest ihn aus und schreibt ihn weg.
Das bedeutet, daß ein Datum (Einzahl von Daten) eine gewisse Zeit im Buffer verbringt bevor der Konsument ihn einsammelt. Diese Zeit nennt man auch gerne Latenz. Die will bekanntlich jeder gegen 0 absenken. Das geht aber nur wenn der Konsument ganz schnell die Daten vom Produzenten lesen kann.
Hat man einen großen Buffer, dann kann der Konsument weit hinter dem Produzenten hinterher hängen. Dann hat man zwar keinen Datenverlust aber hohe Latenz.
Macht man den Buffer ganz klein, dann läuft man Gefahr, daß der Konsument zu schnell konsumiert und den Produzenten einholt. Das äußert sich meist in Knackser bzw. Datenverlust.
An dieser Stelle könnte man natürlich sagen, warum nicht Konsument und Produzent mit gleicher Geschwindigkeit laufen lassen? Das liegt in der Natur von Eventgesteuerten multithreadfähigen Betriebssystemen wie Windows eines ist. Der Konsument ist auch nur ein Programm, daß hoffen muß, daß Windows mal so lieb ist und ihm hin und wieder ein wenig Rechenzeit zuweist.
Der Witz ist einfach, daß man nicht wissen kann, wie klein man den Buffer machen kann. Das ist von vielen Faktoren abhängig (vor allem von der eingesetzten Hardware CPU, Speicher, Festplatte, Motherboard, OS etc.). Daher ist ausprobieren schon ein ziemlich guter Ratschlag.
Sollte es knacken, dann ist der Buffer zu klein. Knackt ist nicht, dann reduziert man die Buffergröße, bis es anfängt zu knacken und vergrößert den Buffer nur wenig. Wenn man die Latenz nicht mehr störend wahrnimmt, dann ist auch gut.
Das ist übrigens auch der Grund, warum solche Dinge konfigurierbar sind.