• Das es für den Alsamixer eine grafische Oberfläche geben soll, ist mir neu. Im Terminal kann es jedenfalls nicht funktionieren, das ist nur Pseudografik.

    Außerdem wird das Programm so gut wie nie gebraucht, wozu der Aufwand.

    Ich komme noch aus der guten DOS Welt. Da war die Welt noch in Ordnung.

    Man kann sich das heute gar nicht mehr vorstellen: Wir haben damals Texte geschrieben, Kalkulationen durchgeführt, Datenbanken programmiert und das alles auf einer bzw. zwei Disketten mit max 600 KB. Natürlich Daten und Programme streng getrennt. Wenn dann mal irgend was kaputt war, hat man halt das Betriebssystem neu gemacht, oder ein anderes Programm kopiert oder auf andere Daten zugegriffen.

    Mit Win95 begann dann die große Katastrophe!

    Ich habe 10 Jahre in einer Computerfirma gearbeitet - an vorderster Front - im Kundensupport.

    Wir haben damals keine Fehler im Betriebssystem suchen und ausbügeln müssen. Der DAU saß in der Regel vor dem Bildschirm.

    Das eine Maus so was von unergonomisch ist, spüre ich jetzt im Alter.

    Die Handygeneration wird noch ganz andere Probleme bekommen.

    Das soll gesund sein???? Viel Spaß damit. Ab Win XP habe ich im Alter von 50 Jahren noch mal umgeschult - zum Sicherheitsingenieur.

    Da war dann für mich wieder die Welt in Ordnung - klare und nachvollziehbare Regeln!

  • Auch grand orgue bekomme ich leider nicht hin: Fehlermeldung beim Öffnen: " Öffnen des Audio Streams für ALSA (PA) : M-Audio .. ICE Multi (hw:0,0) fehlgeschlagen. ungültige Anzahl von Kanälen"

  • Ich glaube, das Orgelspielen schützt Hände und Hirn vor der Alterung :)

  • Auch grand orgue bekomme ich leider nicht hin: Fehlermeldung beim Öffnen: " Öffnen des Audio Streams für ALSA (PA) : M-Audio .. ICE Multi (hw:0,0) fehlgeschlagen. ungültige Anzahl von Kanälen"

    Das kommt mir irgendwie bekannt vor!

    Ich poste mal meine Einstellungen:

    Bildschirmfoto von 2021-04-22 19-35-13.png

    Bildschirmfoto von 2021-04-22 19-39-08.png

    Versuche doch mal den Knopf: Zurück zu den Vorgabewerten

  • Aber ich habe auch meine Linux-Phasen gehabt wo Updates mir Sachen zerschossen haben. Das ist der Grund, warum ich schon seit ein paar Jahren wieder unter Windows unterwegs bin.

    Ja, aber der große Vorteil von Linux ist eben, dass es hier noch eine hehre Trennung von Betriebssystem, Programmen und Daten gibt.

    Ein Ubuntu ist in etwa 15 min aufgesetzt. Datensicherung zurückspielen - fertig.

    Mach das mal mit Windooofs

  • Ja, das wird funktionieren.

    Für den "normalen" nicht besonders computeraffinen User ist diese Lösung aber schon sehr komplex.

    Wahrscheinlich wird es funktionieren, aber eine Voraussetzung dafür ist, dass der Windows 7 ASIO-Treiber des M-Audio auch unter Windows 10 funktioniert.

    Es scheint komplizierter als es ist. Wenn der einzige Zweck darin besteht, eine Audiokarte mit dem ASIO-Treiber über WDM / KS mit GO zu verbinden, ist dies tatsächlich sehr einfach:

    Wenn wir keine VST-Plugins verwenden, benötigen wir Cantabile nicht und können anstelle der umfangreicheren Version „Voicemeeter Banana“ den Audiomixer „Voicemeeter“ (https://vb-audio.com/Voicemeeter) verwenden.

    Wir verwenden dann nur die Option, die Voicemeeter bietet, um über den Audioeingang über WDM / KS mit GO zu kommunizieren und dann das Ausgangssignal von GO als ASIO an die Soundkarte zu liefern.

    Das Routing ist dann wie folgt:

    • GO-Ausgabe: WDM-KS (Voicemeeter vaio)>> Virtuelle Voicemeeter-Eingänge (Voicemeeter VAIO)> SchalterA nach A eingeschaltet > Hardware-Ausgabe A >> ASIO-audiogerät.

    Ich habe diese M-Audio-Soundkarte nicht, aber ich habe es mit einem Fousrite-USB-Audiogerät überprüft. Im Anhang finden Sie eine Beschreibung, die zeigt, wie einfach es geht.

    N.B.Wie für Ubuntu:

    Mit Ubuntu (der vorherigen Version) habe ich die Erfahrung gemacht, dass die Touch-Befehle auf meinem Touchscreen bei GrandOrgue nicht richtig interpretiert wurden. Bei Berührung wurde ein Stopp aktiviert, der jedoch beim Loslassen sofort ausgeschaltet wurde. Mit Hauptwerk, das ich unter Wine über Wine zum Laufen gebracht hatte (also kein Dual-Boot), funktionierte es aber gut.

    Deshalb bin ich wieder zu Windows 10 zurückgekehrt, ohne eine Verbindung zum Internet herzustellen. Das funktioniert gut.

  • Die Hinweise von Klassikfreund haben mir sehr geholfen. Vielen Dank noch einmal. Ich konnte zunächst unter Einstellungen nur Alsa default einstellen. Damit war ich offensichtlich mit der Board-eigenen Soundkarte unterwegs hatte jedoch schon einen guten Klang und vor allem sehr geringe Latenz. Jetzt habe ich auch die M-Audio aktivieren können und experimentiere nur noch mit sample rate und samples/buffer. Leider sind die Einstellungen bei jedem Neustart wieder weg. Mein Fazit bis hierher: Es ist ein himmelweiter Unterschied zwischen Grandorgue auf ubuntu und Windows zugunsten von ubuntu. Allerdings braucht man sehr spezielle Kenntnisse-oder bekommt Hilfe, von einem, der diese Kenntnisse hat. Jetzt gehe ich erst einmal schlafen :)

  • Du solltest die Einstellungen unter Datei/Speichern (oder STRG+S) speichern!

    Alsa Default greift auch auf Deine M-Audio zu, sie ist j als default Gerät angegeben.

    Unter Audio/MIDI/Sound Output State kannst Du die Latenz ablesen.

    Die Samplerate solltest Du auf die Rate der verwendeten Samples abstimmen (in der Regel 44 oder 48 kHz).

    Mit den Puffer kannst Du so weit runter gehen bis erste Ausfälle zu hören sind und dann wieder etwas erhöhen, so dass Du einen stabilen Betrieb auch bei vollgrifigen Akkorden hast.

    Weiter Hinweise zur weiteren Reduzierung der Latenz bei Bedarf von mir.

  • Spricht denn etwas dagegen, die samplerate auf 96000 anzuheben. Hintergrund der Frage ist, dass der Faltungshall nur bei samples/buffer von 1024 funktioniert und bei nierdigeren sampleraten die Latenz wieder ansteigt.

  • Hallo,

    zur Reduzierung der Latenz mit GO scheint es offensichtlich kein einfaches Rezept zu geben.

    Bevor ich in neue Hardware investiere ohne genau zu wissen was die Latenz wie beeinflusst habe ich erst mal angefangen ein wenig zu testen.

    Dazu habe ich GO zunächst auf einem Standard Office Notebook von HP mit I5 Prozessor und nur mageren 8 GB Arbeitsspeicher unter WIN 10 installiert. Das Demosample läuft damit, sogar das Friesach Sample lässt sich laden allerdings mit deutlich reduzierter Auflösung.  

    Die Orgeln lassen sich mit 360 Samples per Buffer und 48KHz Samplerate ohne nennenswerte Knack- und Störgeräusche sowohl über die Onboard Soundausgabe (DirectSound Realtek Audio) als auch über eine externe USB Soundblaster spielen.

    Im SoundOutput Dialog von GO wird dabei eine Latenz von 15ms angezeigt, gefühlt allerdings schien es mir deutlich mehr zu sein. 

    Daraufhin habe ich die Latenz gemessen und siehe da es sind deutlich höhere Werte als die GO Anzeige vorgibt. 

    Die Messung erfolgte mit Audacity auf einem zweiten Notebook, indem ein Kanal aus dem Lineout Ausgang des Orgelkeyboards auf den rechten Aufnahmekanal und ein Kanal der Virtuellen Orgel von GO auf den linken Kanal gelegt wurde. Aus der Aufnahme lässt sich dann die Verzögerung zwischen rechtem und linken Kanal, also Orgelkeyboard direkt und virtueller Orgel messen. Als Orgelkeyboard verwende ich das Cantorum Duo.

    Ich habe mit unterschiedlichen Einstellungen der Samples per Buffer gemessen und komme mit dem Demo Sample Set zu folgenden Ergebnissen:

    360 Buffer pro Sample und Samplerate 48KHz Latenzanzeige Sound Output GO 15ms >> Messergebnis: 61ms Differenz: 46ms
    512 Buffer pro Sample und Samplerate 48KHz Latenzanzeige Sound Output GO 21ms >> Messergebnis: 75ms Differenz: 54ms
    1024 Buffer pro Sample und Samplerate 48KHz Latenzanzeige Sound Output GO 42ms >> Messergebnis: 122ms Differenz: 80ms 

    Die Bildschirmfotos der Messergebnisse kann ich gerne zur Verfügung stellen. 

    Die Hintergrundprozesse von Win 10 waren für die Messung nicht deaktiviert die Energieeinstellung war jedoch auf Höchstleistung. Die Ergebnisse zeigen dass im Soundprozess zusätzlich zu der Latenz die sich aus Buffergröße und Samplerate ergibt noch zusätzliche nicht unerhebliche Verzögerungen entstehen, die sich möglicherweise aus dem Zusammenspiel zwischen Hardware und Treibern ergeben.

    Spannende Frage dabei ist welche der Komponenten erzeugen welche Verzögerungen. 

    Falls jemand die Latenz auch mal wie vor beschrieben gemessen hat, wären die Ergebnisse zum Vergleich interessant besonders bei abweichender Hard und Treiberkonstellation.

    Ich habe auch schon den Weg von GO über Voicemeeter und von dort zur Audioausgabe probiert, was aber die Latenz nur erhöht hat, da ich keine Soundkarte mit ASIO Untertützung habe.

    Mit der Audioausgabe über WASAPI Treiber sind für eine störungsfreie Wiedergabe entgegen DirectSound wenigstens 1024 Buffer pro Sample notwendig mit der dann höheren Latenz von 42ms + x. Lösung also offen.

    Ein weiterer Versuch wäre GO unter Linux zu betreiben und die Messung zum Vergleich durchzuführen.

    Gruß

    sygo
      

    Einmal editiert, zuletzt von sygo (27. Mai 2021 um 17:37)

  • Ein weiterer Versuch wäre GO unter Linux zu betreiben und die Messung zum Vergleich durchzuführen.

    Das wäre von Interesse! Ich spiele zwar nicht mit GO, halte es aber für Supportanfragen in beiden Welten vor.

    Unter Linux habe ich bezüglich Latenz keine Probleme. Eine Messung wäre sehr aufschlussreich.

    LG Wolfram

  • Die Orgeln lassen sich mit 360 Samples per Buffer und 48KHz Samplerate ohne nennenswerte Knack- und Störgeräusche sowohl über die Onboard Soundausgabe (DirectSound Realtek Audio) als auch über eine externe USB Soundblaster spielen.

    Im SoundOutput Dialog von GO wird dabei eine Latenz von 15ms angezeigt, gefühlt allerdings schien es mir deutlich mehr zu sein. 


    Mit der Audioausgabe über WASAPI Treiber sind für eine störungsfreie Wiedergabe entgegen DirectSound wenigstens 1024 Buffer pro Sample notwendig mit der dann höheren Latenz von 42ms + x. Lösung also offen.

    Ein weiterer Versuch wäre GO unter Linux zu betreiben und die Messung zum Vergleich durchzuführen.

    Sehr interessant. Ich bin auch gespannt, wie Hauptwerk aus dem gleichen Test herauskommen würde.

    Welche Treiber haben Sie mit der Puffereinstellung bei 360 Samples verwendet?

    Haben Sie überprüft, ob die neuesten Audiotreiber installiert sind? Mit Windows 10 bietet Microsoft Entwicklern von WDM-KS-Audiotreibern die Möglichkeit, die Latenz zu optimieren. Puffereinstellungen, die zuvor auf Standardwerte gesetzt wurden, können jetzt über den Treiber definiert werden. WDM-KS kann daher unter Windows 10 mit einer geringeren Latenz als unter Windows 7 oder 8 arbeiten, sofern die richtigen Treiber verwendet werden. (https://docs.microsoft.com/en-us/windows-…w-latency-audio)

  • Danke für die Hinweise.

    Ich habe unter WIN10 getestet bislang allerdings nur mit der Onboard Soundkomponente von Realtek. Die Treiber sind aktueller Stand ebenso das BIOS.

    In der Soundausgabe in GO habe ich bislang immer nur mit der Einstellung DirectSound Realtek Audio wiedergegeben, da nur mit dieser Einstellung die geringste Latenz im Soundoutput Dialog von GO angezeigt wurde.

    Der Screenshot mit der Auswahlliste der Audiogeräte ist unten beigefügt.

    Die blau markierte Einstellung ist die Audioeinstellung für den Test. Die gelb markierten habe ich ebenfalls ausprobiert der Latenzwert im GO Dialog hat sich dabei aber immer vergrößert, daher habe ich das nicht weiter verfolgt.

    Eben gerade aktuell habe ich nach Ihrem Hinweis die grüne Einstellung WDM-KS probiert und kann damit sogar bis 128 Samples per Buffer runtergehen ohne dass es kratzt. Die Latenz wird mit 17ms im GO Dialog angegeben. Das werde ich jetzt auch ausmessen und bin sehr gespannt was da noch dazukommt.

    Da ich nur eine externe USB AUDIO Soundkarte von Creative habe, musste ich diese für die Aufnahme im Testaufbau verwenden, da mein zweites Notebook keinen LineIn Eingang hat. Sobald ich dafür eine zusätzliche Lösung habe teste ich auch noch mit der externen Audiokarte.

    Zudem interessiert mich auch noch welchen Einfluss das Abschalten der Hintergrungprozesse durch Fidelizer hat.

    Einen Test unter LINUX werde ich auch noch machen. Ich habe allerdings nur eine lauffähige Linuxinstallation mit GO auf einem USB Stick.

    Mit Hauptwerk habe ich mich noch nicht auseinandergesetzt, da ich nicht gleich eine Lizenz kaufen möchte bzw. ich noch nicht herausbekommen habe wie das mit einer Testlizenz oder Demo funktioniert.

    pasted-from-clipboard.png

  • WDM-KS kann daher unter Windows 10 mit einer geringeren Latenz als unter Windows 7 oder 8 arbeiten, sofern die richtigen Treiber verwendet werden. (https://docs.microsoft.com/en-us/windows-…w-latency-audio)

    Ihr Hinweis die WDM-KS Treiber unter WIN10 zu verwenden und die Latenz nach unten auszuloten hat sich als Toplösung herausgestellt.

    Mit der GO Einstellung Audioausgabe WDM-KS wurde zunächst eine Anfangs-Latenz von 24ms angezeigt. Darauhin habe ich die Samples per Buffer Schrittweise von 512 auf - 256 - 128 - 64 reduziert. Nach jeder Einstellung Überprüfung der Wiedergabequalität. Bis 64 Samples ist die Wiedergabe ohne Kratzen und Aussetzer auch mit Vollplenum und mehr als 20 Tasten möglich.

    Noch kleinere Buffer habe ich nicht weiter ausgetestet. Jedoch war im Soundoutput Dialog die angezeigte Latenz bei 23ms stehengeblieben.

    Daraufhin habe ich die Erwartete Ausgabe Latenz im GO Audio Ausgabe Dialog unter Eigenschaften der WDM-KA Ausgabe auch Schrittweise reduziert. Bei 6ms wurde kein Audiosignal mehr ausgegeben. Ich habe auf 8 ms gestellt. Im GO Soundoutput Dialog wird mit dieser Vorgabe eine Latenz von 13ms angezeigt.

    Das hat mich inspiriert gleich eine Messung durchzuführen. Schon an der Orgel habe ich über Kopfhörer festgestellt dass kaum noch eine Latenz wahrnehmbar war.

    Messergebnis:

    64 Buffer pro Sample und Samplerate 48KHz Latenzanzeige Sound Output GO 13ms >> Messergebnis: 15ms Differenz: 2ms

    Das hatte ich nicht erwartet.

    Daraufhin habe ich versucht die WDM-KA Audioausgabe auch mit der externen Soundkarte Creative Soundblaster THX durchzuführen. Was soll ich sagen, die WDM Treiber funktionieren für die Soundblaster nicht. Die Soundblaster lassen sich nur über WASAPI oder DirectSound ansprechen, und da nicht unter 360 Samples per Buffer mit einer zusätzlichen Latenz von mehr als doppelt so viel wie jeweils im GO Soundoutput Dialog anzeigt wird.

    Wenn GO unter WIN10 verwendet wird sollte daher unbedingt die onboard Sound Komponente mit aktuellen Treibern und WDM-KA Ausgabe ausprobiert werden. Nur wenn Mehrkanal gefordert wird, ist ein externes Soundmodul incl. Treibern für GO notwendig.

    Bei den gemessenen 15ms Latenz zwischen Orgelkeyboard und Virtueller GO Orgel lassen sich die Register von beiden Orgeln sogar ohne spürbare Verzögerung mixen und so die Klangfarben der Cantorum Duo genial erweitern, vorausgesetzt der Nachhall von beiden Soundoausgaben ist entsprechend angepasst.

    Screenshot des Messergebnisses64sample 48kh 13msGO-doc.png

    • Offizieller Beitrag

    Die Idee zwei Quellen auf zwei Kanäle in Audacity darzustellen finde ich sehr gut. Ich habe dies in anderem Zusammenhang auch schon getan.

    Ich hatte einmal die Möglichkeit auf der Dom Orgel in Berlin zu spielen.

    Sie ist pneumatisch gesteuert. Das oberste Werk ist ca 15 m vom Spieltisch entfernt. Die Zeit zwischen Tastendruck und Ventilöffnung ist erheblich. Wer beim Spielen auf den Ton wartet wird immer langsamer und hat verloren. Wenn man auf solch einem Instrument spielt ist die Latenz in GO fast nebensächlich. Ich muss Mal messen wie lang sie bei mir ist. Nach meinem Gefühl Recht kurz und nicht störend. Bin gespannt wie ihr sie verkürzt

    • Offizieller Beitrag

    stimmt, man muss rigeros zählen und im Takt bleben. Die Domorgel ist rein pneumatisch. Das ist schon herausfordernd wenn man das erste mal darauf spielt.

    Die Orgel der Auenkirche wurde seinerzeit von Pneumatik auf Elektropneumatik umgebaut. Die Verzögerungen sind noch deutlich. Wenn man immer darauf spielt kann man sich dann doch zuhören

  • Wie schon angedeutet habe ich noch eine Latenz Messung der Virtuellen GO unter Linux Mint durchgeführt. Linux Mint ist auf einem 64GB USB Stick persistent installiert damit die GrandOrgue Installation dauerhaft mit allen Einstellungen erhalten bleibt. Linux Mint läuft auf einem System mit i7 Prozessor (ASUS Zenbook) mit 12GB Speicher.

    Die Messungen sind mit unterschiedlichen Samples per Buffer und unterschiedlichen Vorgabe Latenzzeiten durchgeführt.

    Die Messergebnisse sind wie folgt:

    64 Samples pro Buffer und Samplerate 48KHz Latenzanzeige Sound Output GO 5ms >> Messergebnis: 25ms Differenz: 20ms

    32 Samples pro Buffer und Samplerate 48KHz Latenzanzeige Sound Output GO 6ms >> Messergebnis: 15ms Differenz: 9ms

    16 Samples pro Buffer und Samplerate 48KHz Latenzanzeige Sound Output GO 4ms >> Messergebnis: 11ms Differenz: 7ms

    Unter Linux mit dem ALSA Audiotreiber treten demnach je nach Buffergröße doch noch erheblich größere Latenzen auf als unter WIN10 mit WDM-KS Treibern. (siehe letzten Beitrag)


    Die Messungen sind alle mit den default Einstellungen von GO erfolgt. Unter Linux war das GO Demo Sample nicht mitinstalliert, so dass ich dort das Giubiasco Sampleset verwendet habe. In den Messaufnahmen sieht man, dass das Anschwellen der Töne auf Maximallautstärke zwischen dem virtuellen Orgelton und dem direkten Ton aus dem Orgelkeyboard sehr unterschiedlich ist was sicherlich auch der Akustik bei der Aufnahme der Samples geschuldet ist. Die Nachhallzeiten habe ich für beide Ausgaben minimiert.

    Die Anschlagsdynamik des MIDI Ausgangs der Cantorum Duo ist fest auf Maximalwert eingestellt.

    Grundsätzlich lässt sich festhalten dass Latenzen kleiner 20ms kaum stören. Im Vergleich mit einer Pneumatischen Traktur sind das verschwindend kleine Zeitdifferenzen. Bei meinen ersten Versuchen allerdings hatte ich wie die Messungen belegen Latenzen von 70ms und mehr und das führt in der Tat dazu dass man immer langsamer wird.

    16sample 48kh 4msGO-linux-doc.png