Leider hat das Steinberg die Eigenschaft das der Line in dessen im Windows fest auf 2 Kanal 48000 kHz steht. Wodurch leider bei VT aufnahmen die Stimme nur auf einer Seite zu hören ist.
Im Live Betrieb konnte ich bei Encoder-Soundprozessing den Mono zu Stereo einstellen was auch super funktioniert. Nur klappt das leider bei den VT Sachen nicht.
Gibt es eine Möglichkeit, ohne außerhalb von Mairlist mit Zusatzprogrammen das Problem auch intern zu lösen?
Hier liegt ein Denkfehler vor: Das eine hat mit dem anderen absolut überhaupt nichts zu tun.
Du hast ein zweikanaliges Interface: Eingang 1 = links, 2 = rechts. Das ist vollkommen normal so.
In DAWs fällt das üblicherweise nicht auf, weil das (Mono)-Mikrofoneingänge sind. Würdest Du hingegen auf Stereotonspuren aufnehmen, träte das Phänomen dort ebenso auf.
Damit sind wir bei mAirList:
Das ist so, wie Du das machst, gar nicht nötig.
Du solltest Dein UR22 vielmehr als Mic In konfigurieren / routen, dann klappt’s auch mit Mono. Und die Option Mono zu Stereo dürfte damit auch überflüssig werden.
Das ist mir schon bewusst gewesen.
Aber genau deswegen entsteht ja das Problem. Ein Microfon ist ja nur Mono also auch nur eine Wiedergabeseite. Wie das Problem entsteht ist mir vollkommen klar.
Genau das ist bei diesem Interface nicht möglich.
Weder in den Asio Einstellungen:
Oder im Windows Mixer:
Daher hatte ich mich beim Livebetrieb mit folgender Lösung beholfen:
Aber ich habe bereits die Lösung:
Leider geht das nur im WASAPI Modus und nicht im ASIO bereich.
(Sollte jemand wissen wie ich ASIO besser konfigurieren kann lasst es mich bitte wissen)
Man stelle ( So wie du UliNobbe Es vermutlich auch vorgeschlagen hast ) die Eingangskanäle im Bereich Aufnahmegeräte MANUELL auf 1 und geht auf Übernehmen.
Als Pfeil auf und ab Auswahl geht hierbei jedoch nur 2, 4, 6 etc… also MANUEL 1 eintippen und auf Anwenden klicken.
Das Mic selbst sollte nicht auf Anhören gestellt sein denn das erledigt das Steinberg von selbst intern. Es entsteht zwar eine kleine Latenz aber diese ist ja, dadurch das man nicht direkt aus mAirlist abhört sondern vom Interface selbst nicht hörbar.
Wäre auch bei 1000ms eher schrecklich.
Hm, ich bin mir nicht so sicher - möglicherweise schreiben wir aneinander vorbei.
Der PC mit meiner Steinberg (242 ) hat leider kein “richtiges” mAirList. Ich werde es später mal mit der v6.1 - die mit dem Demo-Modus - testen.
Ich denke das passt schon so wie wir beide das vorhatten.
Auch im Exclusiv Modus lässt sich im Windows Mixer das leider nicht einstellen.
Ich kann mich noch grau an alte Virtual Dj zeiten erinnern als ich für ASIO immer Asio4All treiber verwendet hab. Mal testen ob es damit einfacher geht… oder zumindest zuverlässiger.
@Torben was müsste ich bei Manueller Konfiguration der Kanalgruppen eintragen das mAirlist somit nur einen Mono Kanal des Interface hernehmen würde.
Das betrifft nur den ASIO Betrieb. WASAPI hab ich ja bereits die Lösung weiter oben beschrieben. Danke
Hat funktioniert. Manchmal muss man eben einfach Denken.
Nun hab ich auch ASIO4ALL am laufen und es klappt einwandfrei. Danke @Torben
BTW: Gäbe es für VT Micro auch VST Sachen zum einbinden und wenn ja wie?
Ich bin ja jemand, der gerne dazu lernt. Kannst Du mir erklären, wozu genau man hier ASIO4ALL braucht?
In meiner naiven Art und Weise hätte ich einfach WASAPI direkt in mAirlist benutzt, weil Du ja weiter oben schreibst, dass es mit dieser Audioschnittstelle funktioniert. Mal ganz abgesehen davon, dass das Audiogerät einen Treiber vom Hersteller mitbringt. Steinberg hat ASIO erfunden, wenn also jemand optimierte ASIO Treiber für seine Hardware entwickeln kann, dann Steinberg.
ASIO4All setzt auf die WDM Schnittstelle auf, also auf einer viel höheren Treiber Schicht als der Steinberg ASIO Treiber und somit mit höherer Latenz haben muss wie der ASIO Treiber von Steinberg.
Wenn ich das noch richtig im Kopf habe, ist die BassASIO, auf die mAirlist hier aufsetzt um überhaupt mit ASIO Soundkarten reden zu können, wiederum ein Aufsatz, der eine weitere Zwischenschicht einzieht und für weitere Latenz sorgt.
Da Du aber das Direct Monitoring der Karte benutzt, ist eine etwaige Latenz sowieso völlig Irrelevant. mAirlist funktioniert bekannter massen am besten mit WASAPI im nicht exklusiven Modus.
Warum also noch Experimente und zusätzliche unnötige Software und Treiberschichten?
Ich verstehe hier den Ansatz überhaupt nicht, kannst Du mir die technischen Hintergründe dazu bitte erläutern? Warum überhaupt ASIO und wenn ASIO, warum ASIO4All? Warum nicht einfach WASAPI?
Um an der Stelle mal reinzugrätschen:
Die Latenz betreffend “sich selber hören” ist bei diesem Interface natürlich nicht relevant - aber da es hier um Voicetracking geht, möchte @TomJumbo83 natürlich so präzise wie möglich arbeiten.
Ob es dabei auf 500 - 1.000 ms exakt ankommt, ist sicher streitbar, aber zu meinen (schlechten) Anfangszeiten mit SAM wollte ich auf die letzten drei Töne von Stevie Wonders “I Just Called To Say I Love You” ein Cha Cha Cha moderieren - und lag tatsächlich um die Latenz daneben (was ich damals™ als super peinlich empfand).
Im Zweifelsfall sollte man sein Vorhaben also nicht unbedingt in Abrede stellen.
Dass man eine möglichst geringe Latenz erreichen möchte, habe ich ja auch gar nicht in Abrede gestellt. Das wird mit ASIO4All aber mit ziemlicher Sicherheit nicht so gut sein, wie mit dem Original Steinberg Treiber. Wenn wir mAirlist mal aussen vor lassen, in dieser Betrachtung.
Wenn man sich mal die Architektur von Windows Audio ansieht:
Dann kann ASIO4All nur oberhalb der CoreAudio greifen, während der ASIO Treiber von Steinberg am Windows System vorbei, direkt auf unterster Ebene, gleich oberhalb der Hardware greift.
Ich bin mir nicht ganz sicher ob ASIO4All, irgendwo im Block ganz rechts greifen kann. Wenn ja, sieht es vielleicht etwas anders aus aber immer noch alles andere als Optimal.
Wenn man die darüberliegenden Schichten von mAirlist noch mit einbezieht, sieht es noch mal anders aus. Ich habe leider kein Ähnliches Blockdiagramm der Bass.dll gefunden.
Man müsste also mit WASAPI, ein genügend niedrige Latenz erreichen, dass der von Dir beschriebene “SAM Effekt” nicht eintritt.
Wäre mal interessant zu sehen, wie sich die einzelnen Blöcke übereinander legen um mal wirklich einen Gesamtüberblick zu bekommen auch für ASIO4All.
Meines Wissens ist der Hauptzweck von ASIO4ALL, den Zugriff auf ASIO-Treiber zu gewähren für Anwendungen, die von Haus aus kein ASIO unterstützen. Also quasi ein Adapter ASIO->WDM.
Da mAirList aber direkt mit ASIO umgehen kann, sehe ich keinen Sinn darin, ASIO4ALL zu verwenden.
Meines wissens nach, genau anders herum. Es stellt eine ASIO Schnittstelle zur Verfügung, für Soundkarten, die keinen eigenen ASIO Treiber mitbringen um mit ASIO Anwendungen auf die Soundkarten trotzdem zugreifen zu können.
Es kann auch mehrere Soundkarten, zu einer zusammenfassen, so wie auf MacOS, die Aggregated Audio-Devices.
Die die Soundkarte aber einen eigenen ASIO Treiber mitbringt, sehe ich keinen Sinn darin ASIO4All zu verwenden. Daher meine Nachfrage.
Der einzige Grund warum ich für das Microfon Asio4all eingebaut habe, war das ich bei VT Mic Eingang KEIN Asio auswählen konnte. Thats it.
Mittlerweile fehler dain gefunden Nur Direct Sound oder Wasapi.
Obwohl ich mit fast allen anderen Wiedergabe Elementen Asio auswählen konnte.
Ich habe auch meine Treiber überprüft und da passt alles.
Thema Latenz Spielt das bei mir wirklich keine Rolle denn ich höre mich selbst nicht durch Windows sondern Hardware intern im Interface selbst. Natürlich habe ich das Mic “nicht” auf lokale Soundkarte wiedergeben eingestellt.
Und im Interface selbst entsteht ja noch keine Latenz.
@Torben
Wäre es möglich auch hier VST sachen einstellen zu können?
Oder AGC einstellungen? Denn soweit ich das bisher gesehen habe geht bei VT das Routing direkt in die Aufnahme.
Es gibt in der Konfiguration unter “Voice Tracking” eine DSP-Chain für das Mikrofonsignal. Da kann man theoretisch auch VSTs einbinden. Die Bearbeitung erfolgt allerdings nicht in Echtzeit sondern erst nach der Aufnahme.
Stichwort “Normalisierung”:
Hier wird als Effekt die “einfache” Normalisierung (dBFS, kein TP?) angeboten - wäre es sehr aufwändig, hier auch eine Normalisierung nach den Vorgaben aus der Konfig (EBU R.128 iVm dBTP) anzubieten?
Schließlich sollte die R.128 sich ja auch schon auf die Produktion auswirken.