Hallo
Ich hatte gestern eine 3 std Sendung gemacht,und ich habe festgestellt das das Levelmeter immer träger wird,woran kann es denn liegen??
Wo wir grad dabei sind: Ich wünsche mir für die Zukunft eine gewisse db-Einteilung für das Levelmeter… 
Ist ganz einfach: Ganz rechts ist 0dB.
Das habe ich ja auch schon irgendwie vermutet ;D
War ja nur so eine blöde Idee, kosmetischer Natur…
Nachtrag zur Sache:
Trägheiten des Programms (auch des Levelmeters, trotz Windows-“Ausleihe”…) kann ich nur beim Beenden feststellen, sofern eine Skin.ini verarbeitet wird. Ohne skin.ini ist das Programm schiclht dicht, wenn es geschlossen werden soll. Mit Verarbeitung eines Skins dauert es etwas länger.
Gruss
Maic
Im Moment ist das nur ein Standard-Windows-Fortschrittsbalken. Da kann man keine Skala dazumalen. Dazu müsste ich selbst ein Levelmeter implementieren. Ich gebe zu, die jetzige Lösung ist nicht besonders hübsch, war aber einfach und funktioniert. Mal gucken, was die Zukunft bringt.
EDIT: Und wenn der Balken hinterherhinken sollte, dann liegt das eher daran, dass die Audiodaten nicht schnell genug durch den Encoder bzw. zum Server kommen (Uplink dicht?). Das sollte man dann aber auch auf dem Stream hören.
Ich hatte dieses Problem gestern auch, nutze noch die Build 762.
Ich habe den Eindruck, dass der Komplette Encoder mit der Zeit hinterher hängt. Ich habe 3 Encoder eingerichtet, 2 Server & 1 Aircheck.
Die beiden Server waren nicht aktiviert, ich habe nur die Aircheck Funktion für Voicetracking zweckentfrendet und das auch nicht dauerhaft, sondern immer für maximal 1min bis 1min30, danach wieder getrennt.
Am Anfang der Aircheck Datei habe ich dann immer eine Stille gehabt und ich musste darauf achten, dass das VU Meter wieder auf null steht bevor ich trenne, sonst wurde am Ende etwas abgeschnitten.
Ich glaube also nicht, dass es daran liegt, dass der Encoder die Daten nicht schnell genug los wird.
Auf unserem Server (Build 764) beobachte ich gerade das Phänomen, dass mAirList den ganzen Rechner immer langsamer werden lässt, bis es dann mit eine Freeze Meldung stehen bleibt, lokale Wiedergabe läuft noch, aber den Encoder schickt nichts mehr raus. Dann muss man es über den Task Manager abschiessen, kein beenden möglich, auch nicht über die Bug Meldung.
Ich habe das gefühl beide Probleme haben eine ähnliche (oder die gleiche) Ursache.
Hi Shorty!
Ist das ein Web-Server (Root, VHost) oder eine Maschine, die bei Euch im Studio steht? mAirList (Build 775) fährt für einen unserer Kanäle die komplette Automation auf einem Win 2008 Server (Root), deshalb frage ich.
Gruss
Maic
Shorty, die Frage stelle ich mir auch. Weil du von “lokale Wiedergabe” sprichst. Hat der Server also eine Soundkarte, die ihr dafür nutzt?
Wenn ja, und wenn die lokale Wiedergabe in Ordnung ist, also nicht hinterherhängt (abgesehen von den paar ms Unterschied, die normal sind beim Encoder), dann kann das nicht der Effekt sein, den ich meine. Das Problem, was ich im Kopf hatte, kann nur bei “keine lokale Wiedergabe” auftreten. Da muss mAirList nämlich selbst dafür sorgen, dass die Daten schnell genug durch den Encoder kommen. Verwendet man hingegen eine Soundkarte, dann sorgt deren Treiber für das Timing.
Der Server läuft mit Win7 64Bit, ich bin nicht ganz sicher welche Edition, vermute mindestens Pro (Business) Also nix mit Webserver, der wurde extra dafür hergerichtet. Ein VNC Server für remote management, ein NSV Encoder (läuft unabhängig von mAirList)
Die lokale Soundkarte wird nicht genutzt, auf dem Server läuft ein Virtual Audio Cable, das vom Encoder Monitor zum Silence Detector geht. (Player gehen direkt auf den Encoder nicht über Soundkarten) Der soll als erstes mAirList neustarten, in der 2. Stufe den Rechner neustarten. mAirList neustarten hat bisher meistens ausgereicht, heute morgen nicht. Stream war still, aber lokale Wiedergabe war Ok. Also ich habe die Wiedergabe nicht gehört, aber wie mein Kollege dokumentiert hat, war normaler Pegel am Silence Detecor zu sehen.
Der Server hat einen 10Mbit Uplink zum Internet (also richtung Shoutcast Server), da sollten die Daten schnell genug weg kommen.
Wir haben hier völlig unterschiedliche Soundkarten. Der Server hat eine Realtek bzw. nutzt ja eigentlich nur das VAC.
Mein Rechner hat eine Realtek 7.1 und eine Mackie Spike. Der Encoder nimmt von der Realtek auf. Die Spike nutze ich nur für PFL, alles über WDM Treiber. OS ist WinXP pro
Hajo hat eine M-Audio oder Terratec karte (ist mir entfallen, Semi-Profi Karte jedenfalls) und nutzt auch die WDM Treiber unter WinXP, weil er seine Karte unter Win7 nur über ASIO an den Start bekommt. (OK das ist ein anderes Thema)
Greetz
Malte
Ok, also reden wir doch von der Variante “keine lokale Wiedergabe”. Dass das Levelmeter da flackert, hat erstmal nichts zu bedeuten, denn daran lässt sich ja noch nicht erkennen, ob die Audiodaten tatsächlich in der richtigen Geschwindigkeit und ohne Verzögerung verarbeitet werden.
“Stream war still”, bedeutet dass, es wurde Stille gesendet, oder es wurde gar nichts mehr gesendet (kein Datendurchsatz)?
Ich hab übrigens gerade noch einmal geschaut - ich verarbeite die Daten genauso, wie der BASS.DLL-Programmierer es vorschlägt: Vergleich der internen Uhrzeit (GetTickCount) mit der Streamposition, wenn Differenz, dann Daten ziehen. Auf diese Weise darf der Stream max. 10ms hinterherhängen.
Ich denke wir sollten den Server erstmal hier aussen vor lassen.
Das eigentliche Problem in diesem Thread war ja das träger werden des gesamten Encoders bei Benutzung einer Soundkarte.
Ich hab eine Realtek HD 7.1 und Hajo eine Terratec Phase 26.
Beide Systeme laufen auf WinXP und nutzen den WDM Treiber. Irgendwo muss da ein Problem sein, vor allem, weil es erst nach einer gewissen Betriebsdauer auftaucht. Ich hab allerdings vergessen gegen zu prüfen ob man den kompletten Rechner oder nur mAirLst neustarten muss um es zu beheben.
Greetz
Malte
Wie genau definierst du denn “Trägerwerden des Encoders” in diesem Fall? Wenn die Soundaugabe (lokale Wiedergabe mit Soundkarte) noch ok ist und nicht ruckelt, dann läuft auch der Encoder auf voller Geschwindigkeit.
Wenn lediglich die Aussteuerungsanzeige anfängt, sich sehr viel langsamer zu bewegen, dann kann das auch ein grundsätzliches GUI-Performanceproblem sein. In diesem Falle wäre interessant, ob auch der Rest der mAirList-GUI (Playlist etc.) “träge” wirkt.
Nein es betrifft nur den Encoder, der scheint insgesamt eine Latenz zu bekommen. Die liegt gefühlt irgendwo zwischen 1 und 2 Sekunden.
Träge ist warscheinlich der falsche Ausdruck, die Anzeige arbeitet zeitversetzt, man nimmt das als träge war, weil sie eben hinterher hängt.
Hajo kannst Du den Eindruck bestätigen?
Greetz
Malte
Passt denn die Aussteuerungsanzeige zu dem, was man über die Soundkarte hört?
[quote=“shorty.xs, post:14, topic:6921”]Nein es betrifft nur den Encoder, der scheint insgesamt eine Latenz zu bekommen. Die liegt gefühlt irgendwo zwischen 1 und 2 Sekunden.
Träge ist warscheinlich der falsche Ausdruck, die Anzeige arbeitet zeitversetzt, man nimmt das als träge war, weil sie eben hinterher hängt.
Hajo kannst Du den Eindruck bestätigen?
Greetz
Malte[/quote]
Hallo Malte
Ja das kann ich bestätigen,es ist erst nach ca 2 1/2 std Sendung aufgetretten, mein Pinguin Levelmeter ist
aber korekt gelaufen,ohne Verzögerung.
Hallo,
gibts hier inzwichen irgendeinen Fortschritt oder eine Lösung des Problems?
Fragt
Bernie
Nicht solange meine Fragen nicht beantwortet werden.
Also das Verhalten ist in der Version 3.1.2 immer noch identisch. Durch das Update der BASS.dlls hätte ich gedacht, dass etwas passiert. Ist also nicht der Fall.
Die Thematik auf unserem Server muss ich noch mal separat betrachten, das scheint was anderes zu sein. Dort suche ich aber gerade ein wichtigeres Problem. In meiner Studioumgebung habe ich kein Audiomonitoring des Encoders aktiviert.
Interessant finde ich die Tatsache, dass das Levelmeter auch träge wird, wenn der Encoder gar keine Verbindung hat, also quasi nur mit läuft.