S1 und das CPU Verhalten

  • Ersteller FragmentMachinery
  • Erstellt am
F

FragmentMachinery

Registriert
30.11.10
Beiträge
30
Reaktionen
1
Punkte
36
Hallo,

da ich mitbekommen habe, das sich hier auch Eike als Entwickler herumtreibt, dachte ich mir das ich mein Problem mit S1 nocheinmal hier poste. Ich habe bereits den Presonus Support und das offizielle S1 Forum hinter mir, leider ohne Erfolg.

Als erstes mal mein System:
Win 7 32 Bit
i7 920
Gigabyte GA-EX58-UD5
S1 1.6.1

Nun zu meinem eigentlichen Problem:
Ich benutze S1 nun schon seit dem Erscheinen (extra aus Ami-Land bestellt..) und habe schon diverse Songs damit komponiert und gemixt. Bei einem Track habe ich allerdings ein merkwürdiges Verhalten. Die durschnittliche CPU Last ist 40 Prozent (laut S1 Anzeige). Wenn ich nun den Song schließe und über den Start-Screen von S1 wieder öffne (ohne S1 komplett beendet zu haben), hat sich die CPU Last plötzlich verdoppelt. Wiederhole ich dieses, ist die CPU komplett ausgelastet und S1 steht fast völlig. Beende ich S1 komplett und lade den Track neu, geht das Spielchen von vorne los. Für mich scheint es, als ob irgendwelche Ressourcen nicht richtig freigegeben werden?
Da ich oft an einem Track lange rumbastel und dann merke, das das Ganze nichts geworden ist, schliesse ich den Song und fange wieder von vorne an. Bei dieser Vorgehensweise ist das Verhalten von Studio One natürlich nicht sehr vertrauenserweckend.....

Ich denke Optimierungen am PC habe ich alle schon durch (BIOS, CPU States, Energy Management, CPU Kerne deaktiviert usw....).

Für Erfahrungen ähnlicher Art und Lösungsvorschläge (vielleicht von Eike als Entwickler) wäre ich sehr dankbar....

Schönen Gruß
Alex
 
Bei einem Track habe ich allerdings ein merkwürdiges Verhalten
Wenns nur bei einem Track ist, ist es fraglich, dass S1 die Ursache dafür ist.

Wo liegt der Unterschied zu den anderen Tracks? Andere Plugins verwendet als sonst? Möglicherweise hat auch die Projektdatei ne Macke?
Kannst Du den Fehler mit einem neu aufgesetzten Stück reproduzieren? Oder mit neuem Projekt, in das Du die Spuren des defekten Projektes einkopiert hast?
 
Bei einem Track habe ich allerdings ein merkwürdiges Verhalten
Wenns nur bei einem Track ist, ist es fraglich, dass S1 die Ursache dafür ist.

Wo liegt der Unterschied zu den anderen Tracks? Andere Plugins verwendet als sonst? Möglicherweise hat auch die Projektdatei ne Macke?
Kannst Du den Fehler mit einem neu aufgesetzten Stück reproduzieren? Oder mit neuem Projekt, in das Du die Spuren des defekten Projektes einkopiert hast?

Vielen Dank für die Antwort.

Die Plugins sind bei mir eigentlich zum Mixen immer dieselben. Da ist nichts neues oder aussergewöhnliches dazu gekommen. Ich habe auch selektiv alle Plugins deaktiviert bzw. gelöscht, bis keines mehr im Projekt vorhanden war. Das Verhalten hat sich allerdings nicht geändert!?.
Das mit der Projektdatei könnte gut sein...
Ein neues Projekt habe ich bereits aufgesetzt, hier hat alles funktioniert.....allerdings habe ich nicht alle Routings usw. rekonstruiert.

So dramatisch ist das Ganze nun nicht, allerdings denke ich, wenn es sich um einen Bug handeln sollte, das schon ein ziemlich ärgerlicher ist.
 
moin alex!

schoener rechner. den bios quatsch haetteste dir mit unserem power-profil schenken koennen (wuerde ich auch immer noch empfehlen), aber das tut nix zum problem..
also, wenn du das programm beendest, kann nix mehr laufen, was sich nicht einen separaten process startet. wenn es um speicher ginge, da kanns schon mal vorkommen. aber ein plugin sollte im audio-thread von studio one laufen. wenn der beendet ist, sollte auch das plugin beendet sein. alle programm-eigenen threads sowieso. die vermutung liegt also sehr nahe, dass es sich um ein komisches plugin handelt. wahrscheinlich eins, wo der schoepfer zu schreibt, dass es toll optimiert ist. du koenntest ja mal im ressource monitor gucken, welcher thread nach dem beenden von S1 diese load erzeugt.
ups. hmm. also du schreibst, dass die load nur da ist, solange S1 offen ist. aber auch, wenn nichts geladen ist, kein song, kein projekt? das wiederum deutet auf einen der dienste hin, moeglicherweise auch die soundkarte. geht die load weg, wenn du probehalber auf windows audio umschaltest? was ist das fuer eine karte? es koennte aber auch einer der anderen dienste sein, ich halte das allerdings fuer unwahrscheinlich..

viele gruesse,
eike
 
moin alex!

schoener rechner. den bios quatsch haetteste dir mit unserem power-profil schenken koennen (wuerde ich auch immer noch empfehlen), aber das tut nix zum problem..
also, wenn du das programm beendest, kann nix mehr laufen, was sich nicht einen separaten process startet. wenn es um speicher ginge, da kanns schon mal vorkommen. aber ein plugin sollte im audio-thread von studio one laufen. wenn der beendet ist, sollte auch das plugin beendet sein. alle programm-eigenen threads sowieso. die vermutung liegt also sehr nahe, dass es sich um ein komisches plugin handelt. wahrscheinlich eins, wo der schoepfer zu schreibt, dass es toll optimiert ist. du koenntest ja mal im ressource monitor gucken, welcher thread nach dem beenden von S1 diese load erzeugt.
ups. hmm. also du schreibst, dass die load nur da ist, solange S1 offen ist. aber auch, wenn nichts geladen ist, kein song, kein projekt? das wiederum deutet auf einen der dienste hin, moeglicherweise auch die soundkarte. geht die load weg, wenn du probehalber auf windows audio umschaltest? was ist das fuer eine karte? es koennte aber auch einer der anderen dienste sein, ich halte das allerdings fuer unwahrscheinlich..

viele gruesse,
eike

Hi Eike,

vielen Dank für die ausführliche Antwort! Klasse...

das Power Profile habe ich im nachhinein auch gefunden ;-)

Da habe ich mich vielleicht etwas missverständlich ausgedrückt...
Ich versuche es nochmal ;-)

1. Song in S1 laden
2. Alles gut, 40 Prozent CPU Last
3. Song schliessen (nicht S1) -> CPU Auslastung ist weg bzw. normaler Level
4. Song über den Startbildschirm von S1 wieder laden (S1 ist immer noch nicht beendet)
5. CPU Last ist nun 80 Prozent (als ob alles Plugins doppelt laufen...)
6. Dasselbe nochmal, Song schliessen, Song neu laden, S1 ist immer noch nicht beendet worden
7. CPU Last ist nun 100 Prozent..
9. Nun ->S1 komplett beenden<- und neustarten
10. Song laden, alles wieder in Ordnung, CPU Last 40 Prozent

Hoffe, das war eine bessere Erklärung?

Schönen Gruß
Alex
 
#4
welcher thread nach dem beenden von S1 diese load erzeugt.
Ist irrelevant, weil das Problem nach Neustarten von S1 nicht mehr existiert.

Abgesehen davon: Das Problem existiert nur bei einem Song. Und es scheint nicht rekonstruierbar zu sein. Aus dem Grund sind alle anderen Vorschläge aus Deinem Post eher unpassend.

Wenns ein Bug ist, dann müsste der auch rekonstruierbar sein - selbst dann, wenn der Bug nur unter bestimmten Bedingungen auftritt.
Ansonsten bleibt nicht mehr viel: Defektes Plugin, Bedienfehler, Macke im Projekt.
Wenn der Fehler weg ist mit neuem Projekt, dann lohnt auch die Forschung nicht weiters. Obwohl - vielleicht kommt dann raus, an welcher Stelle wer falsch gedreht hat... :D
 
#4
welcher thread nach dem beenden von S1 diese load erzeugt.
Ist irrelevant, weil das Problem nach Neustarten von S1 nicht mehr existiert.

Abgesehen davon: Das Problem existiert nur bei einem Song. Und es scheint nicht rekonstruierbar zu sein. Aus dem Grund sind alle anderen Vorschläge aus Deinem Post eher unpassend.

Wenns ein Bug ist, dann müsste der auch rekonstruierbar sein - selbst dann, wenn der Bug nur unter bestimmten Bedingungen auftritt.
Ansonsten bleibt nicht mehr viel: Defektes Plugin, Bedienfehler, Macke im Projekt.
Wenn der Fehler weg ist mit neuem Projekt, dann lohnt auch die Forschung nicht weiters. Obwohl - vielleicht kommt dann raus, an welcher Stelle wer falsch gedreht hat... :D

Naja, rekonstruierbar ist das Verhalten ja schon irgendwie...jedoch nur im Moment bei dem einen Song.

Interessieren würde mich das Ganze auch schon.....möchte ja schließlich nicht, das das nochmal auftritt.
 
3. Song schliessen (nicht S1) -> CPU Auslastung ist weg bzw. normaler Level
4. Song über den Startbildschirm von S1 wieder laden (S1 ist immer noch nicht beendet)
5. CPU Last ist nun 80 Prozent (als ob alles Plugins doppelt laufen...)
ok. alle plugins mal einzeln ausschalten. da muesste der boesewicht zu finden sein. es sei denn es ist unser multithreading.
bug ist bug, nur wenns reproduzierbar ist, kann mans einfacher beheben. aber genaue infos koennen auch helfen.
 
3. Song schliessen (nicht S1) -> CPU Auslastung ist weg bzw. normaler Level
4. Song über den Startbildschirm von S1 wieder laden (S1 ist immer noch nicht beendet)
5. CPU Last ist nun 80 Prozent (als ob alles Plugins doppelt laufen...)
ok. alle plugins mal einzeln ausschalten. da muesste der boesewicht zu finden sein. es sei denn es ist unser multithreading.
bug ist bug, nur wenns reproduzierbar ist, kann mans einfacher beheben. aber genaue infos koennen auch helfen.

Die Plugins habe ich schon einzeln abgeschaltet...bis zum letzten ;-)

Ich habe sie sogar komplett gelöscht aus dem Projekt, eines nach dem anderen..leider ist die hohe CPU Last geblieben. Das hat mich ja darauf gebracht, das eventuell Resourcen nicht richtig freigeben werden...
 
Ich habe sie sogar komplett gelöscht aus dem Projekt,
Du solltest vielleicht mal den umgekehrten Weg gehen. Ein neues Projekt machen und dann nach und nach mit dem vorhandenen Material mit den Plugins und Einstellungen und Routings aufbauen.

Dann müsste ja eigentlich, wenn irgendein Part buggy ist, sobald dieser Part erreicht ist, der Fehler wieder auftreten.
 
alex hat mir freundlicherweise den song geschickt.
mit dem ergebnis, das ziemlich eindeutig reaktor die thread-priorisierung versaut. (der setzt die naemlich beim schliessen um. ohne zu wissen wohin. nur weil ER nicht laeuft, wenn er niedrige prio hat.. )

die jungs von NI meinen ja immer, sie koennten die ganze multiprocessing-scheduling von innerhalb ihrer plugins VERBESSERN. :nudelholz: Selbstverstaendlich verhindern sie damit nur, dass der Host die Kontrolle hat, und damit keinen gleichmaessigen Datenstrom zur Audio-Hardware mehr sicherstellen kann. Leider bietet Reaktor wohl keine Schalter an, um das Verhalten zu verbessern (ein paar von den NI plugins haben ja inzwischen schalter, um das plugin-interne multiprocessing abzuschalten). ca 80% der mir bekannt gewordenen CPU-Last-Auffaelligkeiten (nich nur in unserem host..) haben mit NI-plugins zu tun..
.. Da hilft nur noch Kunden-Beschwerde, Kunden-Beschwerde, Kunden-Beschwerde .. :sauer:
 
Das ist wirklich höchst ärgerlich. Ich verzichte aus diesen Gründen schon seit geraumer Zeit auf NI-Produkte.
 
alex hat mir freundlicherweise den song geschickt.
mit dem ergebnis, das ziemlich eindeutig reaktor die thread-priorisierung versaut. (der setzt die naemlich beim schliessen um. ohne zu wissen wohin. nur weil ER nicht laeuft, wenn er niedrige prio hat.. )

die jungs von NI meinen ja immer, sie koennten die ganze multiprocessing-scheduling von innerhalb ihrer plugins VERBESSERN. :nudelholz: Selbstverstaendlich verhindern sie damit nur, dass der Host die Kontrolle hat, und damit keinen gleichmaessigen Datenstrom zur Audio-Hardware mehr sicherstellen kann. Leider bietet Reaktor wohl keine Schalter an, um das Verhalten zu verbessern (ein paar von den NI plugins haben ja inzwischen schalter, um das plugin-interne multiprocessing abzuschalten). ca 80% der mir bekannt gewordenen CPU-Last-Auffaelligkeiten (nich nur in unserem host..) haben mit NI-plugins zu tun..
.. Da hilft nur noch Kunden-Beschwerde, Kunden-Beschwerde, Kunden-Beschwerde .. :sauer:

ihr könntet eine funktion für "schwierige plugins", die ihre child threads selbst zu hoch priorisieren einbauen, die die prioritäten der threads der plugins im nachhinein ändern
ist zwar nur ein workaround und das ziemlich dreckig - aber es sollte für solche fälle ausreichen!
entsprechende erforderliche api's die nötig sind um threads zu finden und zu ändern sind ja ausreichend vorhanden.
 
alex hat mir freundlicherweise den song geschickt.
mit dem ergebnis, das ziemlich eindeutig reaktor die thread-priorisierung versaut. (der setzt die naemlich beim schliessen um. ohne zu wissen wohin. nur weil ER nicht laeuft, wenn er niedrige prio hat.. )

die jungs von NI meinen ja immer, sie koennten die ganze multiprocessing-scheduling von innerhalb ihrer plugins VERBESSERN. :nudelholz: Selbstverstaendlich verhindern sie damit nur, dass der Host die Kontrolle hat, und damit keinen gleichmaessigen Datenstrom zur Audio-Hardware mehr sicherstellen kann. Leider bietet Reaktor wohl keine Schalter an, um das Verhalten zu verbessern (ein paar von den NI plugins haben ja inzwischen schalter, um das plugin-interne multiprocessing abzuschalten). ca 80% der mir bekannt gewordenen CPU-Last-Auffaelligkeiten (nich nur in unserem host..) haben mit NI-plugins zu tun..
.. Da hilft nur noch Kunden-Beschwerde, Kunden-Beschwerde, Kunden-Beschwerde .. :sauer:

Hallo Eike,

vielen Dank für Dein schnelles Feedback!
Ok, die Erklärung klingt einleuchtend ;-) Da muss ich dann wohl erstmal mit Leben....wäre klasse wenn ihr einen Workaround finden würdet....

Eine neue Version von Reaktor ist ja schon in Planung...vielleicht hilft die ja auch weiter!

Schönen Dank nochmal für deine Analyse
Alex
 
das hacken waer natuerlich ne moeglichkeit.. mal schauen.

laesst sich reaktor eigentlich auch per rewire einbinden?
 
das hacken waer natuerlich ne moeglichkeit.. mal schauen.

laesst sich reaktor eigentlich auch per rewire einbinden?

Hacken ist immer gut ;-)....

Nein. leider hat Reaktor keine ReWire Unterstützung...doch langsam glaube ich, das wäre die bessere Anbindung...
 
Kann man die jBridge in S1 laden?
Und Reaktor in jBridge?
Damit könnte man Reaktor in einen anderen Prozess verbannen.
 

Ähnliche Themen

moonbooter
    • Danke
  • Artikel
Testberichte Test: Korg Prologue 8
Antworten
6
Aufrufe
20K
NorthernDecay
NorthernDecay
Can
    • Danke
  • Artikel
Antworten
11
Aufrufe
50K
oove
oove
Can
Antworten
15
Aufrufe
133K
Asmotiv
A
twinnpeaks
  • Artikel
Antworten
9
Aufrufe
44K
twinnpeaks
twinnpeaks

Oft gelesene Themen

Zurück
Oben