Das KMidi-Handbuch
Zurück | Kapitel 4. Design | Vor

# 4.6. Speicheraspekte

TiMidity kann eine Riesenmenge Speicher für Patches verbrauchen. Anzeichen dafür ist eine geringe Antwortgeschwindigkeit ihrer Arbeitsoberfläche oder gar ein Absturz. Dieses Problem tritt wahrscheinlich nur bei großen sf2-Soundfonts mit mehr als 30 MB auf. Die Klavier-Patches des Personal Choice's PC400 Soundfonts können beispielsweise je 25 MB Speicher belegen. Nach der Wiedergabe einiger Midi-Dateien, die drei dieser Patches verwenden, sind 75 MB Speicher belegt. Im Konfigurationsdialog von KMidi können Sie die Obergrenze des von KMidi verwendeten Speichers festlegen. Das bedeutet, dass TiMidity früher geladene Patches verwirft, wenn die Obergrenze erreicht ist. Die Standardeinstellung von 60 MByte funktioniert auf einem System mit 48 MB RAM und 196 MB Cache-Speicher. Je niedriger Sie diesen Wert ansetzen, um so mehr Patches müssen während der Wiedergabe einer Stückliste zwischendurch nachgeladen werden. Wenn Sie über sehr viel RAM verfügen, können sie den Wert auf "no limit" setzen. Wenn Sie den Wert hoch genug ansetzen, können ganze Soundfont-Dateien anstatt einzelner Patches geladen werden. Setzen Sie den Wert zu gering an, so ist das nachteilig, da Soundfont-Dateien in einem Stück weniger Speicher benötigen als die Patches, wenn Sie einzeln geladen werden (der Grund ist unklar).

Auf Little-Endian-Systemen wie x86 werden sf2-Dateien nicht eingelesen, sondern in den Speicher abgebildet. Damit erfolgt der Start wesentlich schneller. Für Big-Endian-Systeme konnte das bis jetzt noch nicht implementiert werden.

Nach der Wiedergabe jeder Midi-Datei gibt KMidi die durch Patches belegte Speichermenge im Informationsfenster aus.

Wenn Sie nur über wenig Speicher oder Auslagerungsspeicher verfügen, kann ihr System trotz einer niedrigen Obergrenze des von KMidi verwendeten Speichers abstürzen. Seien Sie daher vorsichtig mit großen Soundfonts.

Zurück | Anfang | Vor
Geschwindigkeitsaspekte | Hoch | Mitwirkende