Wenn der Linuxer mehr Audio-Ausgänge braucht
Früher oder später wünscht man sich mehr Aus- und Eingänge, um unterschiedliche Mixe bereitstellen zu können. Vorher habe ich mit kleineren Scarletts (Solo, 2i2, 2i4 – Gen1 und Gen2) gearbeitet und mir die Flexibilität mit einem Behringer Ultralink Pro Mixer und einem Ultra-Curve Pro EQ zusammengesteckt. Ich schielte immer öfter auf Audio-Interfaces mit mehr Ein- und Ausgängen. Die gibt es aber nicht ohne internen Mixer, und der will bedient werden. Leider hat den meisten Herstellern noch keiner gesagt, dass sie minimalen Aufwand und maximale Zielgruppe durch ein plattformunabhängiges Design erreichen. Daher wursteln sie lieber zweigleisig mit Steuersoftware für Windows und Mac herum und ignorieren bewährte Standards – z.B. dokumentierte MIDI-Befehle oder Web-Interfaces. MIDI würde eine Automatisierung aus der DAW ermöglichen und das Interface somit weiter aufwerten, ganz zu schweigen von Community-Software, die damit ermöglicht werden würde.
Fragt man danach und erwähnt Linux, kommt meist reflexartig „Wir unterstützen kein Linux“. Man hat also nicht einmal verstanden, dass man Linux nicht speziell unterstützen muss, wenn man es richtig macht.
MOTU hat die Scheuklappen abgelegt und spendiert seinem UltraLite AVB einen Mixer, der per Web-Browser zu bedienen ist. Das ist nicht nur interaktiv möglich, sondern auch per JSON-API. So kann der Linuxer bei der Anmeldung ein Script laufen lassen, das ein Preset lädt. Dazu weiter unten mehr.
Der Betrieb erfolgt wie bei allen USB-Interfaces unter Linux als Class Compliant Interface. Wer den Effekt hat, dass er hin und wieder kleine Knackser bei 44,1 kHz hört, der ist nicht alleine, und das liegt nicht am MOTU-Interface. Das USB-System von Linux mag es am liebsten, wenn ganze Puffer von 1 ms gefüllt werden. Das ist mit 44,1 kHz nicht zu erreichen, mit 48 kHz aber sehr wohl, zumal wenn die Anzahl der jack-Puffer (meist 2 oder 3) noch mit eingeht.
Entgegen vieler Gerüchte muss die jack-Puffergröße keine Potenz von 2 sein. Es gibt allerdings Software, die bei der FFT (Fast Fourier Transformation) über abweichende Puffergrößen stolpert, z.B. Guitarix. Vermutlich ist es nur eine Frage der Zeit, wann die mathematischen Tricks beim Umgang mit beliebigen Puffergrößen bei der FFT so in Bibliotheken verpackt sind, dass sie ohne viel Überlegen eingesetzt werden.
Empfohlene Kombinationen von jack-Puffergrößen (-p) und der Anzahl von Puffern (-n) für USB-Interfaces findet man unter https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_ideal_for_usb_interface
Nach einigen Monaten Betrieb des MOTU UltraLite AVB weiß ich, wie ich seine kleinen Macken umgehen kann. Alle diese Macken bedeuten keine Einschränkung für die Arbeit mit dem Interface, daher habe ich es nicht zurückgegeben, und man müsste es mir aus den kalten, toten Händen reißen.
- Es startet nicht automatisch, wenn Spannung anliegt und muss per Druck auf den ganz links liegenden Drehregler eingeschaltet werden. Dabei braucht es ca. 30 Sekunden zum Booten. Damit kann ich leben.
- In der aktuellen Firmware steckt ein Bug, der im Class Compliant Mode (den wir für Linux brauchen) für ein Modulo-8-Channel-Hopping sorgt. Wenn man über Ausgang 1 und 2 ausgibt, wird der Klang erst kratzig und verschwindet dann, um auf Ausgang 9 und 10 aufzutauchen. Dann geht das Spiel weiter. Ich habe den Bug gemeldet, und statt mit dem üblichen linuxophoben Spruch abgemeiert zu werden, schrieb der Support, dass das Problem bekannt sei und man daran arbeite. Bis dahin empfehle ich die Firmware-Version 1.3.2+520, die man unter https://motu.com/techsupport/technotes/firmwarechangelog/ herunterladen kann.
- Ist der per USB angeschlossene Rechner gestartet, schaltet das MOTU UltraLite AVB auf 192 kHz um. Solange sollte man warten, bis man dem Gerät irgendwelche Kommandos schickt. Leute, die mehr Erfahrung mit Audiodigitalisierung haben als ich, legen auf https://people.xiph.org/~xiphmont/demo/neil-young.html dar, warum Samplingfrequenzen über 48 kHz nur Nachteile bringen. Ich will natürlich keinem Goldöhrchen mit sauerstofffreien, langsam eingebrannten Audiokabeln seine Illusionen nehmen. Schließlich gibt es auch den Osterhasen tatsächlich.
- Man kann die jack-Puffergröße im laufenden Betrieb mit jack_bufsize ändern. Da die meisten Audioprogramme das nicht goutieren, macht es kaum jemand. Das MOTU UltraLite Pro mag es auch nicht besonders. Spätestens, wenn man sich fragt, warum denn auf einmal in jedem Song künstliche Plattenknackser reingemischt wurden, hat man diesen Bug entdeckt. Er äußert sich auch durch Modulo-8-Channelhopping bei den Eingängen.
- Wenn ich mein Userpreset lade, vergisst er im Mixer, den gesetzten Highshelv-EQ zu aktivieren. Dafür gibt es aber separate Befehle, siehe weiter unten.
Infos über das OSC- und JSON-API findet man auf https://motu.com/proaudio/index.html unter „External control APIs“.
Für die Steuerung per JSON-API muss man die ip-Adresse und die ID des Interfaces kennen. Die Adresse lässt man am besten vom Router fest zuteilen (anhängig von der MAC-Adresse des Interfaces). Ich hab ihm in meinem Heim-DNS einen Namen gegeben („motu“). Die ID findet man im Web-Interface auf der Device-Seite ganz unten unter GUID. Für manch Befehle braucht man sie, für manche nicht.
Um die Befehle zum Interface zu schicken, nutzt man natürlich nicht einen aufgeblasenen Browser, sondern was Schlankes wie curl. Wenn die ID in $AVBID steht, die ip-Adresse oder der Name in $AVBHOST und die Samplingfrequenz in $FREQ, dann kann man mit folgendem Befehl diese Frequenz einstellen:
curl -s –data ‚json={„value“:“$FREQ“}‘ ${AVBHOST}/datastore/avb/${AVBID}/cfg/0/current_sampling_rate
Das erste Userpreset hat die Nummer 1000, das lade ich mit:
curl -s –data ‚json={„value“:“1000″}‘ ${AVBHOST}/datastore/ext/presets/load
Und weil er vergisst, den EQ zu aktivieren, schiebe ich das nach:
curl -s –data ‚json={„value“:“1″}‘ ${AVBHOST}/datastore/mix/main/0/eq/highshelf/enable
Erst danach starte ich jack. Es kann sinnvoll sein, zwischen den Kommandos ein paar Sekunden zu warten (mit sleep). Versuch macht kluch.
Das sieht nach viel Gebastel aus, aber man darf nicht vergessen, dass es sich um zusätzliche Möglichkeiten zur Automatisierung des Setups handelt. Linuxer sind nun mal besonders faul und überlegen daher, wie sie wiederkehrendes manuelles Geklicke vermeiden können. Man kann sebstverständlich das Interface auch manuell zurechtklicken bzw. darauf vertrauen, dass es die Einstellungen über Neustarts hinweg beibehält. Den Gefallen tut es einem bei der Samplingrate bisher nicht, wenn man keine 192 kHz haben will.
Ist es eingestellt und ist jack gestartet, dann läuft das Interface stabil, auch über viele Stunden hinweg. Es ist jetzt mein Haupt-Interface, und das wird auch für längere Zeit so bleiben. Ich habe meinen Hauptmix mit leicht angehobenen Höhen, der zu den Aktivboxen geht, einen Mix zum Mixer-Kopfhörerverstärker ohne diese Anhebung und einen Mix zum Kopfhörerverstärker beim Mikrofonständer, da natürlich mit Direct Monitoring des Mikrofons.
Für die Gitarre schalte ich ein Focusrite Scarlett 2i4 vor, siehe dazu auch https://www.amazona.de/community/linux-guitarix-dickes-daw-projekt-und-die-loesung-des-latenzproblems/
Ich habe leider die curl-Zeilen nicht richtig formatiert. Da wurden schonmal zwei Bindestriche zu einem Bis-Strich zusammengefasst oder Gänsefüßchen zu typografisch korrekten Anführungszeichen.
Die „rohen“ curl-Zeilen gibt es unter http://sue.....te_AVB.txt
Moin,
also Knackser sollten auch bei eigentlich 44,1 kHz nicht als Regelfall vorkommen. Jedenfalls nicht, ohne dass ein xrun berichtet wird. Sollten die Knackser von xruns begleitet werden, dann ist die Jack Puffergröße wohl doch zu klein gewählt. Ggf. kann auch ein RT-Kernel helfen. Bei mir hat der allerdings nie etwas Grundlegendes geändert.
Wenn die Knackser aber ohne xrun kommen, dann ist da etwas faul mit dem MOTU interface. (Insbesondere, wenn sie periodisch kommen sollten.)
Zu MOTU selbst:
Dass MOTU Interfaces mittlerweile auch unter Linux laufen, ist wohl leider nur eine zufällige Nebenwirkung der durch Apple forcierten USB Compliancy. MOTU hat nie auch nur irgendwie Interesse gezeigt, sich für Linux zu öffnen. Ich sehe das auch weiterhin leider nicht.
@camarillo Die Knackser haben nichts mit Xruns zu tun. Den Effekt hatte ich auch mit unterschiedlichen Scarletts und beliebigen Puffergrößen. Hört man impulsarme, eher dumpfe Musik („Drones“), fällt es mehr auf: Es gibt ca. 1x in der Minute einen ganz leichten Knackser, so als wenn ein Kühlschrank an der selben Stromphase anspringt. Ich habe es mit Netzstromfiltern versucht, aber das hat nicht geholfen. Es kann sein, dass dieser Effekt nicht mit allen USB-Chipsets auftritt, aber ich bin nicht alleine damit.
Seitdem ich auf 48 kHz umgestellt habe, ist Ruhe. Insofern hake ich das Problem ab. Ich muss nur dran denken, beim mp3- und FLAC-Export aus Audacity (ich mastere immer in Echtzeit in Audacity hinein) die Projektfrequenz auf 44,1 kHz einzustellen.
Als Tuningmaßnahme kann ich einen RT-Kernel empfehlen (statt eines Lowlatency-Kernels), wenn man auf NVidia-Grafik und VirtualBox verzichtet. NVidia- und VirtualBox-Treiber können mit RT-Kerneln Probleme machen.
Daher meine Empfehlung:
– Intel Onboard-Grafik
– WLAN-Module blacklisten, da die Treiber schonmal für Xruns sorgen können
– Onboard-Audio auschalten (im BIOS oder per Blacklist)
– Mitigations für Heartbleed etc. in GRUB (/etc/default/grub) ausschalten. Wirklich interessant sind die nur für Hoster mit verschiedenen Kunden auf dem selben Blech.
– „Performance“-Governor einschalten
Natürlich profitieren die Linuxer sehr davon, dass die mobilen Apple-Geräte Class Compliance benötigen. Die Hersteller mögen Linux nicht, weil die Nutzer genau hinterfragen, was Software auf ihren Rechnern tun darf und welche Daten dem Hersteller zustehen.
MOTU ist auf einem guten Weg. Immerhin kann man die Firmware ohne Registrierung herunterladen.
@bluebell OK, ist das ungefähr einmal pro Minute zufällig gestreut oder eher regelmäßig im Minutentakt?
Hintergrund:
Es gab früher mal Probleme mit USB Audio Interfaces, die den zumindest vor etwa 10 Jahren selten genutzten „Implicit Feedback“ Modus verwendet haben. Da kam es ebefalls nur bei 441. und 88.2 kHz regelmäßig zu Knacksern, allerdings eher etwas häufiger als 1/min. Das hat damals zu einem ziemlich großen Umbau im USB Audio Teil des Kernels geführt. Die Probleme sollten gelöst sein und sind es bei meinen Geräten auch. Sind dir da von Anderen ebenfalls Berichte bekannt, dass es beim MOTU dieses Problem gibt? Ich habe auf die Schnelle nichts gefunden.
@camarillo Der Wechsel von 44100 auf 48000 erfolgte noch mit den Scarletts. Ich müsste bei Gelegenheit mal testen, ob es auch mit dem MOTU noch auftritt. Da mit 48000 nichts knackst, hab ich diesbezüglich keinen Leidensdruck.
@bluebell OK, dann fände ich es ehrlicherweise schön, wenn du den entsprechenden Abschnitt raus editieren könntest. Es ensteht momentan nämlich der Eindruck, dass
a) du das Knacksen bei 44,1 kHz mit deinem MOTU UltraLite AVB beobachtet hättest, und
b) es sich um ein allgemeines Problem von Linux im Umgang mit USB Audio Interfaces bei 44,1 kHz handelt.
Dass a) nicht richtig ist, hast du gerade geschrieben. Dass b) ebenfalls nicht richtig ist, kann ich aus meiner eigenen Erfahrung mit verschiedenen Interfaces bestätigen. Darüber hinaus müssten die Mailinglisten überquellen vor lauter Problemberichten, wäre das tatsächlich ein allgemeines Problem.
@camarillo Ich habe nicht geschrieben, dass das Knacksen beim MOTU definitiv auftritt, ich halte es lediglich für möglich, mache dann aber nicht das MOTU verantwortlich: „Wer den Effekt hat, dass er hin und wieder kleine Knackser bei 44,1 kHz hört, der ist nicht alleine, und das liegt nicht am MOTU-Interface.“
Ich denke, das ist hinreichend deutlich. Ändern kann ich eh nichts mehr am Artikel, so wie ich das Eingabeinterface verstanden habe.
Bei solch subtilen Störgeräuschen, die bei dem meisten Programm-Material in den Impulsen der Drums untergehen, würde ich nicht darauf wetten, dass die Mehrzahl der Betroffenen das auch hört – zumal diese Knackser nicht ihren Weg in ein erzeugtes WAV, FLAC oder mp3 finden.
Bezüglich des Osterhasen-Links unter Punkt „3“ eine Leseempfehlung zum Thema digitale Auflösung: https://www.adt-audio.de/ProAudio_WhitePapers/GrenzenDerDigitaltechnik_1.html
Ich verstehe es auch nicht, wie ein Hardwarehersteller mit einem solchen Kundenkreis diesen Esoterikartikel veröffentlichen kann. Erst dachte ich, der Autor hat bloß den Schritt von der Analogverarbeitung zur digitalen Abtastung nicht verstanden, aber auch seine Betrachtungen zu Obertönen durch Nichtlinearitäten und realen Klanggemischen würde ich nicht auf solch einer Seite erwarten.
Dass wissenschaftliche Untersuchungen zum Thema bisher nicht existieren, gibt er immerhin zu.
Mangelnde Erfahrung mit dem Thema zeigt sich darin, dass er davon ausgeht, dass die Weiterverarbeitung der Daten mit der selben Auflösung erfolgt wie die Auflösung der A/D-Wandler im Interface. Dabei erfolgt die Verarbeitung mit mindestens 32 Bit und bietet selbst bei vielfältigen Rundungsfehlern mehr, als man sich im analogen Bereich erträumen kann.
Beim Runterrechnen des Signals kennt er nur den naiven Ansatz, Bits abzuschneiden. Dass man mit Dithering die Quantisierungsfehler im Spektrum verteilen und auch geschickt platzieren kann und dass eine Abtastratenkonvertierung bei Verwendung von (sin(x))/x zur Interpolation keine Qualitätsprobleme hat, weiß er auch nicht.
Ihm fehlen mathematische Grundlagen, und die gleicht er durch Bauchgefühl aus.
Auch wenn ich keinen Uniabschluss in Nachrichten- und Hochfrequenztechnik hätte, hätte ich den Artikel nicht zu Ende lesen können. Der meint das ernst. Daher kann ich darüber nicht lachen.
@bluebell Womit du Recht hast.Ich hab die Grütze mal gelernt und lang genug praktiziert. Und habs nicht bis zum Ende geschafft.
Hallo PSV DDV,
ich möchte auf der nächsten SB mit dir gerne mal über Shannon Nyquist, das Gross und Kleinsignalverhalten reden. Ich hab tapfer versucht den Artikel zu lesen. Aber als ich bei der Bitweisen Addition von zwei 24Bit Summanden 26 Bit las, war ich raus. Das Ergebnis ist dann ein Overflow. Weil höher als 1 oder 0 gehts digital nicht. Sorry. So einfach ist das nicht. Ich zieh doch nicht einfach Von 29 Kanälen, 13 Känale ab um, dann bei 16 bit zu landen. Da wird einiges verwechselt und mit anderem verwürfelt.
@TobyB Interessant, Toby, da bin ich sofort dabei. Ein gemütlicher Tisch auf der SB wird reserviert :) Diesbezüglich (nicht wg. des Tisches) toben ja regelrechte Glaubenskriege. Ich bin lediglich Anwender mit Hasenohren, aber mir fällt auf, dass bei diesem Thema die jeweilige Gegenseite von beiden Glaubensseiten immer als komplett ahnungslos und dumm dargestellt wird (siehe oben). Meine Hörerfahrung ist, dass Unterschiede zwischen den Datenformaten hörbar sind. Warum auch immer. Die technischen Gründe täten mich interessieren.
Vielleicht sollte man das mal hier in einem geeigneten Artikel unvoreingenommen thematisieren.
Man muss immer genau benennen, worüber man redet:
– Digital vs. analog?
Da kann man unterschiedlicher Meinung sein, was besser klingt, und ob „besser“ nun „mit wenig Verzerrung“ oder „mit schöner Verzerrung“ bedeutet. Nicht umsonst gibt es Plugins, die die Unzulänglichkeiten analoger Technik (Sättigung) nachbilden, weil wir uns daran gewöhnt haben.
– WAV vs. 320 kBit mp3 vs. 128 kBit mp3?
Macht Euch mal den Spaß und testet, ob Ihr die höchste Qualität zuverlässig heraushört. Ich nicht. Ich hab bei den ersten vier Beispielen die 320 kBit-Version ausgewählt und bei den nächsten beiden die 128 kBit-Version. Vielleicht waren es gerade die Unzulänglichkeiten, die ich im Klang mochte.
https://www.npr.org/sections/therecord/2015/06/02/411473508/how-well-can-you-hear-audio-quality?t=1566409202274&t=1568820486742
@bluebell Genau Bluebell,
Psycho-Akustik und Mathematik und Nachrichtentechnik sind voller Fallstricke. Die Mathematik dahinter ist zwar nicht komplex man muss aber aufpassen sich nicht selber die Beine wegzuhauen. Zweimal 24 Bit Worte addieren ergibt eben nicht 25 oder 26 Bit. Genausowenig wie ich von 29 Kanälen 13 abziehen kann und dann bei 16 bit lande.
–
Ich kann dem Aufsatz argumentativ folgen und verstehe worauf er hinauswill, dass macht den Aufsatz inhaltlich auch nicht richtiger. Hören und Höreindruck hat erstmal nichts mit Mathe zu tun. Ich bin der Meinung das man das bitte strikt trennen sollte.
@bluebell Hallo bluebell, ich bezog mich eindeutig auf Deinen Punkt 3, in dem die These verbreitet wird, dass Samplingraten über 48kHz nur Nachteile bringen.
Mir geht es demnach um die klanglichen Auswirkungen des gewählten linearen Datenformates.
Ich denke schon, dass man in manchen Fällen Material heraushören könnte, das mit höheren Samplingraten aufgenommen ist. Die unhörbaren hohen Frequenzen fallen bei der Aufnahme nicht auf, können aber im Mix zu hörbaren Intermodulationen führen – also zu etwas, was man nicht beabsichtigt hatte und vermutlich auch nicht will.
Um das zu vermeiden, muss man einen High-Cut ansetzen. Dann ist aber die höhere Abtastfrequenz nichts als verbratene CPU und Plattenplatz.
Ein punktuelles Oversampling kann dagegen durchaus sinnvoll sein, z.B. in einem Limiter-Plugin, um Inter-Sample-Peaks zu vermeiden.
Das Argument, dass der Tiefpass weniger steil sein kann, wenn man höher abtastet, lasse ich gelten, aber dann redet man nicht über 96 kHz statt 48 kHz, sondern über vielleicht 64 kHz. Das sind Nuancen. Die Diskussion bei den Goldöhrchen geht ja eher darum, ob 96 kHz noch reichen, oder ob es 192 oder gar 384 kHz sein müssen, damit das Zungenpiercingklicken der Sängerin ausreichend Air hat.
Letztlich geht es um Gewohnheit. In den 50ern war eine verzerrte Gitarre unerhört, nun lieben wir sie. Aufnahmen populärer Musik ohne Dynamikkompression – undenkbar. Wechselnde Vinylqualität von außen nach innen und mangelnde Kanaltrennung klingen „warm“ und „analog“. An den sägenden Klang dauerhaft mitlaufender Autotunes haben sich die Jungen Leute seit Shania Twain gewöhnt. Kein Popsong geht ohne. Und wer weiß, vielleicht werden wir es irgendwann vermissen, wenn keine hörbaren Intermodulationen mehr einen leichten Ringmodulatoreffekt andeuten.
@bluebell Ich finde das ist ein sehr spannendes Thema, bei dem viele Fragen offen sind. Ich persönlich habe mich mit meiner Hardware bei 24 Bit und 96kHz eingespielt. Bei manchen Geräten klingt eine niedrigere SR. allerdings besser. Ich denke das ist stark von der verwendeten Hardware und gegebenenfalls auch Softwarekette abhängig. Ich höre da, wie gesagt, bezüglich der SR. deutliche Unterschiede aber nicht immer ist mehr auch besser. Die technischen und wahrnehmungsphysiologischen Hintergründe interessieren mich sehr und ich hatte das Gefühl, dass der von Dir verlinkte Artikel das zu voreingenommen betrachtet. Ich kenne mich allerdings sehr viel schlechter mit der softwareseitigen Datenverarbeitung als mit der elektronisch-/biologischen Seite der Kette aus und lerne immer gerne dazu. Was ist eigentlich das Gegenteil vom Goldöhrchen? Das Betonohr? ;-)
Masstab oder besser Referenz für die Qualität der Audioreproduktion ist meiner Meinung nach nicht so sehr die sich immerfort wandelnde kulturelle Gewöhnung an Multibandkompression oder Frau Twain (oder Frau Cher) als vielmehr die Referenz des direkten physischen Erlebens von Stimme und Instrumenten. Ersteres sind lediglich stilistische Episoden also eine kulturelle Modulation der grundlegenden Referenzerfahrung.
Hallo psvddv,
super, ich geb ne Wurst und ein Bier aus ;-) Ich bin kein Freund von Glaubens und Forenkriegen. Wissen erwerben, Wissen festigen, Wissen verteilen. Das gefällt mir besser. Der Punkt ist, das der Verfasser zwei Sachen vermischt und eines davon nur empirisch zu belegen ist oder auch nicht, Hören und Höreindruck. Die anderen Themen, wie ADDA Wandlung, Transkodierung, Reduktion der Bittiefe sind mehr oder minder aus der Grundlagenforschung raus und entwickeln sich weiter. Das ist halt immer schwierig sowas, wir erinnern und an die BBD Diskussion und ob ein BBD nun analog, diskret(Zeit und Wert) ist. Und am Ende kommt Einer und sagt ja die Ladung wird analog gespeichert. Aber das die diskrete Ladungsspeicherung eben hier Teil der Übertragungsfunktion ist, wird dann wegignoriert. Und wenn du den BBD nicht sauber abstimmst, kannst du das hören, siehe Behringer ;-) (Nein das ist kein Bashing) Scotty kann auch hören, wenn im Intermix der Enterprise was nicht rund läuft. Der Punkt ist halt das man eigenes Erfahren auch mal hinterfragen muss. Und andersrum wenn etwas gut klingt ist es okay :-)
@TobyB Moin Toby,
richtig, ich bin auch kein Freund von Glaubens- oder Forenkriegen, wohl aber von intensiven Diskussionen mit dem Ziel der Wissensvertiefung. Leider verschwimmen die Grenzen im Netz da schnell. Solange es nicht persönlich wird ist für mich alles im grünen Bereich. Ich erinnere mich gut an die BBD Diskussion und bin mir sicher, da hat trotz der verfestigten Standpunkte mindestens Einer was gelernt hat. :)
Grüße!
In dem Zusammenhang will ich mal auf den AVB Treiber für Linux aufmerksam machen:
https://github.com/Drumfix/avb4linux
Audio direkt über Ethernet ohne JACK-Zwischenschicht ist eine gute Sache, da Hardwarehersteller keine Lust haben, JACK in ihre Interfaces einzubauen.
Schade, dass AVB so designt ist, dass man spezielle NICs braucht. Hat man ein Notebook, dann kann man nicht mitspielen (außer vielleicht mit einem Apple-Gerät, da hab ich keine Infos).
@bluebell Hallo Bluebell, so ganz ohne war AVB unter MacOS X auch nicht, das hat sich aber eingepegelt. Ich für meinen Teil hab das selbst auf meinem Asbach iMac von 2007 mit El Capitan fröhlich laufen. Es gab später dann wohl ein iMac und Mac Pro Modell wo AVB dank nicht komplett kompatibler NICs den avb daemon crashte. Sierra/High Sierra war auch Problematisch, weil dort bis zu einem Bufix Probleme mit Avid HW gab, kein Audioplayback, Drop Outs etc.
–
AVB NICs sind für jeden Geldbeutel erhältlich. Schwieriger wird dann schon mit Switchen und Geräten.
NEWS NEWS NEWS
MOTU hat beim UltraLite AVB mit neuerer Firmware etwas am USB-Protokoll geändert („implicit feedback“). Darauf ist der Linux-Standardkernel im Zusammenspiel mit dem UltraLite AVB noch nicht vorbereitet.
Für Leute, die einen Kernel backen können, gibt es einen Treiber für Linux 5.8. Läuft bei mir schon viele Tage ohne Probleme. Auch gibt es Erfolgsmeldungen von Leuten mit 828ES.
Siehe https://linuxmusicians.com/viewtopic.php?p=122814#p122814
Eine Minianleitung zum Kernelbacken ist dabei.
Der Beitrag ist ja schon ein paar Takte alt, trotzdem hätte ich eine Frage:
Ich schaffe es nicht ein User-Preset mit cURL zu laden. Die Factory-Presets (und auch andere Einstellungen) lassen sich mit
curl -s –data ‚json={„value“:“2″}‘ http://url.....esets/load
aufrufen. Nur wenn ich die ID eines User-Presets nutzen will, z. B. {„value“:“1003″} tut sich gar nichts. Allerdings nutze ich ein 828es mit Firmware 1.3.5+184
Hat das schon jemand hinbekommen bzw. weiß jemand, ob Motu das vielleicht geändert hat?
@markusd Vielleicht beginnen die bei Deinem Gerät nicht mit 1000.
Dump doch mal alles, vielleicht hilft das.
curl http://deindevice/datastore