na da bin ich mal gespannt, denn ich habe nach wie vor ein ähnliches problem mit genau dieser 1010LT und den mitgelieferten asio-treibern.
Hi zusammen,
nach der Hilfe von Malte habe ich gestern einen Langzeittest gemacht, leider ohne Erfolg. Ich habe den Puffer bei Aufnahme auf 1000 ms hochgeschraubt, hat nichts gebracht. Das einzige war, dass der Fehler beim ersten mal später auftrat als sonst ( statt nach 10 min. erst nach 35 min. ) das würde ich jetzt aber unter Zufall verbuchen.
Bin ziemlich ratlos bei der Geschichte :-\
Hi,
ich weiß nicht…hilft uns das weiter "ASIO Driver offers lower latency in recording to a computer-based DAW application. "
http://www.zoom.co.jp/downloads/g21u/software/
Vielleicht könnt ihr mir ja beim Einrichten meiner M-Audio 1010LT helfen, das wäre super nett
uppppsss…muss mir noch 2 XLR Kabel besorgen, bin bisher vom Compressor von XLR auf Cinch (Soundkarte) Input gegangen.
Gruß Jörg
Was dort beworben wird, kommt aus dem Recording bereich. Dort musst Du quasi Echtzeit aufnehmen, damit das was z.B. der Sänger gerade singt, in der Aufnahme auch vom Timing her, an der richtigen Stelle steht. Und nicht voll neben dem Takt liegt.
Sonst müsste man jede Spur um ein paar millisekunden nach vorne ziehen, das ist eine schweine Arbeit.
Die Latenzen können Dir in Deinem Anwendungsfall eigentlich egal sein, denn das was über den Encoder geht, hörst Du ja nicht direkt mit. Du hörst ja den Output vom Michschpult ab, also das Signal was in den Rechner rein geht. Und bei der Latenz von 10-30 Sekunden, die der Shoutcast Server bzw. der Buffer im Player beim Hörer noch erzeugen, kommt es auf die eine oder andere Millisekunde, die durch die Soundkarte erzeugt wird auch nicht mehr an.
Bei der Wiedergabe eigentlich auch, denn ob die Musik ein paar Millisekunden später startet nach dem Du den Play butten gedrückt hast, das hörst Du unter umständen gar nicht. Wir machen mit mAirList ja keinen Beat Mix, wie im DJ Bereich.
Soweit ich weiß wird ASIO in der BASS.DLL (die Audio Engine, die Torben Verwendet) auch nur durch Plugins realsiert, d.H. da entsteht eine zusätzliche Latenz.
Je nach Betriebssystem hast Du also 2 Varianten zur Auswahl, die Sinn ergeben.
Unter XP und älter DirecSound und unter Vista oder neuer WASAPI.
ASIO geht sicher auch irgendwie, aber meist handelt man sich damit zusätzlichen Konfigurationsärger ein.
Was das Problem bei mEGGs angeht, bin ich mit meinem Latein langsam am Ende.
Ich vermute irgendwo gibt es noch ein Treiber Problem, nur wo? Und warum tritt das Problem nur mir mAirList auf und nicht mit z.B. Virtual DJ?
Warum ausgerechnet bei der Aufnahme?
Hallo Malte,
habe gestern auch darüber gelesen…http://www.delamar.de/musikproduktion/latenz-verbessern-latenzprobleme-4519
oder hier auch: http://www.magix.info/de/probleme-mit-asio-treibern-latenz-synchronisation.wissen.62414.html
desweiteren habe ich gelesen (finde es aber nicht) das die On Bord Grafikkarten ohne Speicher diese Probleme auch hevorrufen können. Man sollte wohl immer möglichst eine Grafikkarte mit externen Speicher wohl nutzen, da diese das wohl ausgleichen können.
wünsche Schönes WE und warte jetzt noch auf meine 2 XLR Kabel damit ich meine neue Soundkarte damit verbinden kann.
In voller Erwartung
Gruß Jörg
genau das ist die frage die ich hier schon mal gestellt hatte.
mein system ist 2 jahre stabil gelaufen, am system wurde nix geändert, selbst ein neuaufsetzen des PCs incl. aller updates und einer nagelneuen mairlistinstallation (ohne schnickschnack) haben nix geändert.
und: im VDJ ist alles sauber. (mit genau den einstellungen wie im mairlist)
selbst im audioprogramm wie cubease laufen die asiotreiber einwandfrei.
Ich lese hier die ganze Zeit interessiert mit, und auch wenn mir noch keine konkrete Lösung eingefallen ist, ist es doch gut, dass ihr alle möglichen Tests gemacht habt und Informationen zusammengetragen habt. Das wird bei der Analyse sicherlich helfen.
Ich will an dieser Stelle noch einmal die Funktionsweise des Encoders erläutern:
Im Grunde handelt es sich beim Encoder um ein kleines Mischpult mit drei Eingängen und 1+x Ausgängen.
Die Eingänge sind:
- Der Player-Eingang, in dem alle Signale derjenigen Player ankommen, deren Ausgabe auf “Encoder” steht.
- Der Line-Eingang.
- Der Mic-Eingang.
Die Ausgänge sind:
- Das lokale Wiedergabegerät wie in der Audio-Konfiguration eingestellt.
- Je ein Ausgang für jede eingetragene Encoder-Verbindung.
Digitale Mischpulte funktionieren so, dass sie von jedem Eingang ein Sample (x Bytes) nehmen, diese addieren, und das Summensample dann an jeden Ausgang weiterreichen. Das dann immer in einer Endlosschleife (wobei immer ein Block von mehreren Samples gleichzeitig verarbeitet wird). Genau das tut auch der Encoder.
Man kann sich das bildlich wie ein kleines Uhrwerk mit Zahnrädern vorstellen: Das “Mischpult” als großes Zahnrad in der Mitte, und die Ein- und Ausgänge als kleine Zahnräder außenrum.
Damit dieses Uhrwerk immer in gleichmäßiger Geschwindigkeit läuft, ist es zwingend notwendig, dass alle Ein- und Ausgänge die Daten schnell genug bearbeiten. Das heißt insbesondere: Wann immer der Mischer in der Mitte das nächste Sample von einem Eingang braucht, muss dort auch eins anliegen. Wenn der Mischer erst auf das Sample warten muss, stockt das gesamte Uhrwerk. Das nimmt man dann als Aussetzer oder Knistern in der Wiedergabe war, weil für einen kurzen Moment keine Daten mehr ankommen.
Zu solchen Verzögerungen bei den Eingängen kommt es insbesondere dann, wenn die Soundkarte aus irgendeinem Grund die Daten nicht schnell genug liefert. Häufig spielen Hardwarekonflikte dabei eine Rolle, zum Beispiel wenn sich die Karte den IRQ mit einer anderen Karte (z.B. Netzwerk) teilt.
Um dem entgegenzuwirken, arbeiten die Soundkarten mit Puffern. Die aufgenommenen Samples werden also zunächst in einen Bereich im RAM geschrieben, von wo aus sie dann von der Anwendung abgeholt werden. Je größer der Puffer, desto größer die Wahrscheinlichkeit, dass immer genug Samples in ihm vorhanden sind, auch wenn der “Nachschub” mal einen kurzen Moment auf sich warten lässt.
Der Nachteil an diesem Puffer ist Latenz: Wenn jedes Sample erst eine Zeitlang in dem Puffer verbringt, bevor es von der Anwendung abgeholt wird, dann kommen die aufgenommenen Daten verzögert in der Anwendung an. Oder anders gesagt: Man hört sich selbst oder das Mischpultsignal mit einiger Verzögerung.
Das ist insbesondere für diejenigen schlecht, die ohne Mischpult arbeiten und ihr Mikrofon direkt am PC angeschlossen haben. Die wollen sich ja mit möglichst wenig Verzögerung auf dem Soundkartenausgang hören.
Wer hingegen über das Mischpult vorhört und den Encoder nur zur Aufnahme und zum Streaming nutzt (aber ohne lokale Wiedergabe), dem kann die Latenz im Prinzip egal sein - auf dem Weg zum Hörer kommen ja noch mehr und größere Puffer ins Spiel.
Unter dem Strich geht es also darum eine Puffergröße zu finden, die den persönlichen Anforderungen und den Gegebenheiten der Hardware gerecht wird.
mAirList 4.2 versucht einigermaßen intelligent solchen verzögert eintreffenden Samples entgegenzuwirken, indem es in diesem Fall einfach Stille in den Stream einfügt, um zu verhindern, dass das Uhrwerk ins Stocken gerät.
Für den reinen Mischpultbetrieb ohne lokale Wiedergabe ist dies aber eher von Nachteil; da wäre es vielleicht besser, einfach auf die Samples zu warten und sich darauf zu verlassen, dass das von den Puffern in den Playern der Hörer wieder glattgebügelt wird. Oder nicht? Ich denke mal darüber nach.
Der zweite Ansatz, den ich sehe, ist innerhalb von mAirList einen zusätzlichen Puffer einzuführen, der den Hardwarepuffer der Soundkarte noch einmal unterstützt. Also eine künstliche Vergrößerung, auf Kosten von mehr Latenz, aber mit der Hoffnung, dass immer genug Samples am Ausgang anliegen.
Ich überlege mal, wie sich das kurzfristig realisieren ließe.
also für wichtig erachte ich schon mal, dass grundlegenede einstellungen im system übereinstimmen müssen?
beispiel:
in der soundkartenkonfig des windows hat jemand 48000 angegeben. (weshalb auch immer)
in mairlist aber nur 41000.
schon muss wahrscheinlich der PC umrechnen ? kostet ggf. ressourcen.
Auch diverse andere Umrechnungen kosten Kraft. (gerade bei älteren rechnern)
Beispiel: mp3 ist eine 192mp3
und der stream ist auf 128 AAC eingestellt.
da hat dann wohl jeder CPU zu tun.
Auch sollte man bei der Fehlersuche diverse Soundprocessinggeschichten deaktivieren.
ich hab bei mir alles auf 44100 und den ASIO bei 512 samples in der M-Audio 1010lt.
IRQ - keine Probleme.
hab gestern mal testweise Proppfrexx installiert und hatte keine probleme mit ASIOtreibern.
die Angabe in Mairlist (Audio-Einstellungen - Asio - Puffergröße) 0 = Standard bedeutet, es wird der Puffer der Soundkarte ausgelesen und in mairlist verwendet?
ist das immer noch so ?
macht es ggf. Sinn dort einen wert einzutragen (der ggf. auch kleiner ist als der Wert in der SoundKarte)?
ach und ich hab mal sowas gefunden, mal so zum lesen über Latenzen für alle die es betrifft.
Danke Torben für die ausführliche Beschreibung.
Ich kann mein Problem mittlerweile auf den Mairlist Encoder eingrenzen.
Ich habe am Freitag eine komplette Sendung ( 2 std. + 1 bonussstunde ) mit Mairlist ausgespielt und als Encoder Simplecast genutzt. Ich gehe dabei über ein Mischpult. Es gab keine Störungen.
Der Mairlist Encoder scheint also irgendein Problem mit meiner Hardwarekonfig zu haben, verschiedene Puffereinstellungen usw. habe ich bereits mit Malte zusammen probiert.
Bin gespannt auf 4.2. ob der Fehler dann für meine Konfig. weg ist.
Teste auf jeden Fall mal die v4.2. Die ist ja eh so gut wie released. Wir sollten unsere Untersuchungen also auf diese neue Version konzentrieren.
Hi Torben,
gibt es in aktuellen OS immer noch “Probleme” mit IRQ Sharing? Ich bin der Meining seit WinXP ist das vorbei, weil das OS entsprechend weitere virtuelle IRQs erzeugt. Denn es ist in aktueller Hardware fast gar nicht mehr möglich die Soundkarte auf einen eigenen IRQ zu legen.
Also alles an Aufwand, was man bis Win2000 noch machen musste um ASIO Echtzeit zu ermöglichen, soll ab XP sogar kontraproduktiv sein. (hab ich irgendwo gelesen).
Greetz
Malte
Du hast recht, auf dem Papier gibt es solche Konflikte nicht mehr. Früher musste man ja partout vermeiden, dass zwei Karten denselben IRQ verwenden.
Heute gibt es “IRQ-Sharing”, grundsätzlich können sich also mehrere Karten einen IRQ teilen - allerdings scheinen nicht alle Hersteller dies korrekt umzusetzen. Es sind Fälle bekannt, in denen die Soundausgabe erst korrekt funktionierte, als die auf demselben IRQ sitzende WLAN-Karte deaktiviert wurde.
Moderne Mainboards weisen die IRQ meist fest einem bestimmten Slot zu; man kann den IRQ also allenfalls durch Umstecken von Karten ändern.
[quote=“Torben, post:72, topic:8262”]Du hast recht, auf dem Papier gibt es solche Konflikte nicht mehr. Früher musste man ja partout vermeiden, dass zwei Karten denselben IRQ verwenden.
Heute gibt es “IRQ-Sharing”, grundsätzlich können sich also mehrere Karten einen IRQ teilen - allerdings scheinen nicht alle Hersteller dies korrekt umzusetzen. Es sind Fälle bekannt, in denen die Soundausgabe erst korrekt funktionierte, als die auf demselben IRQ sitzende WLAN-Karte deaktiviert wurde.
Moderne Mainboards weisen die IRQ meist fest einem bestimmten Slot zu; man kann den IRQ also allenfalls durch Umstecken von Karten ändern.[/quote]
Richtig, vor dem umstecken, aber am besten alle Treiber deinstallieren. Nicht nur über die Systemsteuerung->Software, sondern auch im Gerätemanger–> Gerät entfernen. Dann runterfahren, dann umstecken.
W-LAN scheint generell da rein zu “funken”. Das ist dann aber eher ein BIOS bzw. Embedded Controller (EC)-firmware Bug, sowas kann man sehr schön mit “dpc latency checker” herausfinden.
Damit bringe ich unsere BIOS Entwickler immer zur Verzeiflung, wenn wir ein neues Produkt haben… 
Oft findet man auch Dienste, die die Lantenz durch solche Bugs verursacht, noch verstärkt. Hab ich mal mit dem Search Indexer und den Tablet PC Features auf einer ATOM Low-Power Kiste gehabt. Nach dem Bug-Fix machte es keinen Unterschied mehr, ob die Dienste leifen oder nicht.
Die Tablet PC Features sind übrigens immer aktive wenn Windows einen entsprechenden Touchscreentreiber findet. Also auch auf Desktop Rechnern möglich. Kann man für die Verwendung von mAirList locker deaktivieren (hab gerade den entsprechenden Dienst nicht im Kopf, google fragen). Der Touch als Mausersatz funktioniert dann trotzdem noch, nur rechtsklick oder ein On-Screen Keyboard fallen dann weg.
Gut, können wir bei mEEGs ausschließen, der hat kein Touchscreen.
Search Indexer würde ich hier auch nicht unbedingt ausschalten, da der Rechner nicht nur für mAirList da ist. Ich glaube auch nicht wirklich dass es in diesem Fall was bringt (kann ich technisch aber gerade nicht begründen).
Greetz
Malte
Hier mal ne kleine Rückmeldung zum bisherigen (auf Grund meiner Schichtarbeit dauert das halt etwas länger) Stand meiner Versuche. Soweit wie sich das für mich und speziell in meinem Fall (siehe am Anfang) hier abzeichnet, scheint das Problem wohl eher am Betriebssystem zu liegen. Wie komme ich zu dieser Überzeugung? Ganz einfach, den bisherigen Verlauf kann man oben nachlesen. Ich hab mich also an den Support von M$ gewandt und habe von dort die Auskunft bekommen, da es sich bei meinem Betriebssystem um eine OEM-Version handelt, solle ich mich an den Hersteller meines PC´s wenden und wenn der mir nicht weiterhelfen kann bleibt mir immer noch der kostenpflichtige Support von M$ mit einem Preis von 72 Euro/Anfrage (Sarkasmus an schicker Stundenlohn, könnte mir auch gefallen Sarkasmus aus). Bevor ich mich aber an den Hersteller wende hat mich jemand anderes auf eine neue Idee gebracht was man noch ausprobieren könnte. Ich habe heute, da ja der komplette Datenstrom (Up- und Downstream) jeweils immer abreißt, kurzer Hand den Onboard-LAN-Anschluß deaktiviert und einfach mal ne LAN-Karte eingebaut. Denn wenn es an der Hardware liegt müsste sich das Problem ja damit dann erledigt haben.
Aber Pustekuchen. Nichts da, das selbe Problem. Alle ca. 5 min rauscht der komplette Traffic auf Null für kurze Zeit um dann wieder ganz normal zu funktionieren als sei nichts gewesen.
Ich hab inzwischen wieder jede Menge graue Haare dazu bekommen. 
Hier nochmal alles zum mitmeißeln in Stichpunkten:
[ul][li]Problem: der komplette Traffic setzt alle 5 min für einige Sekunden aus und verursacht Aussetzer und Verzerrungen auf dem Stream, es sind aber keine Veränderungen an der Hardware bzw. Software vorgenommen worden. Alles hat vorher in der selben und unveränderten Konfiguration wunderbar funktioniert.[/li][/ul]
[ul][li]1.Versuch: Software (mAirList, LAME-Encoder, Treiber für Soundkarte und LAN-Anschluß) geupdatet -> kein Erfolg[/li]
[li]2.Versuch: die komplette TK-Anlage (Splitter, Fritzbox usw.) neu gestartet -> kein Erfolg[/li]
[li]3.Versuch: mAirList 4.2 ausprobiert -> kein Erfolg[/li]
[li]4.Versuch: andere Soundkarte (eine die noch nie im System eingebaut war) ausprobiert -> kein Erfolg[/li]
[li]5.Versuch: Anruf bei M$ -> bisher ohne Erfolg[/li]
[li]6.Versuch: andere LAN-Karte (war ebenfalls noch nie im System eingebaut) eingebaut -> kein Erfolg[/li][/ul]
[ul][li]es steht jetzt noch der Anruf beim Support des PC-Herstellers (auf anraten von M$) aus. Werde ich so schnell wie möglich machen.[/li][/ul]
Ich halte Euch weiter auf dem Laufenden. Ich will endlich wieder senden. :’(
Hallo dann will ich auch mal einen nachsetzen :-[
also bei mir ist es “nur” das abreißen des Streams bzw. Stottern nach ca. 2-3 min. (wie als wenn die CD oder Plattennadel springt) beim einsetzen eines PlugIns, ob es das mairlist eigene (Soundprocessing’s) oder das winamp vst plugin ist, spielt auch hier keine Rolle, alle machen den selben fehler. Ohne plugin läuft es.
Habe mittlerweile eine neue Soundkarte eingebaut, M-Audio 1010LT (hat sich aber trotzdem gelohnt die Investition).
Werde morgen noch mal den Jumper von der Soundkarte umstellen (bedämpft um 11dB).
Ich werde dann auch morgen bzw. dieser Tage davon berichten.
Beste Grüße, und nimm es nicht so schwer Silvio (alles wird gut)
Jörg
Testet doch bitte mal den neuen Build 1641 von mAirList 4.2. Dort wurden einige Änderungen an den Encoder-Routinen vorgenommen, die mit den beschriebenen Problemen in Zusammenhang stehen könnten.
Ich hatte heute eine etwas längere Debug-Session mit einem Kunden, der mehrere streamende Instanzen auf einem Server betreibt. Dort gab es ähnlich Effekte, die offenbar mit der CPU-Auslastung zusammenhingen und damit, mit welcher Priorität mAirList die Encoder-Threads abwickelt. Das wurde im besagten Build 1641 dahingehend angepasst, dass der “Zahnrad-Thread” jetzt mit der höchstmöglichen Priotität läuft. Vielleicht hilft es was.
erledigt,
ich hatte dadurch nen lizenzfehler ? den hab ich ignoriert, und dann gings trotzdem ?
Werd ich probieren, obwohl ich, wie gesagt, der Meinung bin das es bei mir defenitiv am Betriebssystem liegen muß, da ich diese Trafficabrisse auch im normalen Betrieb habe. Aber probieren geht über studieren. Ich werds auf alle Fälle ausprobieren.
Hallo zusammen,
Hallo Torben,
ich kann nur sagen…es läuft ! Bitte so lassen ;D (Build 1641)
habe jetzt eine Stunde getestest, mit Automation mit Assist mit allen PlugIns inkl. Winamp vst. Kein Ruckeln, kein knistern, kein Stottern.
ich habe mal ein screen gemacht, während der Testphase, die CPU ist in der 1 halben Stunde bis auf 70% gewesen und danach hat sie sich bei 20-30% eingepegelt.
ich hoffe bei den Kollegen läuft es jetzt auch.
PS: eine kleinigkeit ist mir aufgefallen, daß der Encoder jetzt bis in den roten bereich geht obwohl meine Stücke alle bis max. 90dB haben.
dann allen einen schönen resttag noch, werde mal noch weiter testen.
Gruß Jörg
Screen CPU.doc (182 KB)
kurzes Feedback,
nach 30 min mit nem Quadcore und der M-Audio 1010lt und Asio mit 512 samples läuft es im Moment sauber,
ich dreh nun mal auf meine Standard 256 Samples runter.
Achja, VST-Plugin ist aktiv.
CPU bei ca. 5 - 6 % in der Summe (Mairlist - 0 %)