AxeFx II Audio-Interface Diskussion im internationalen Forum

[funkstation777]

Danke für die Info!

Wobei ja bereits nachgewiesen wurde, daß sowas im Bereich der Consumer Elektronik üblich ist, daß man Bauteile absichtlich mit ner kurzen Lebensdauer versieht... Siehe chronische Arschlochitis...

 

[Pacosipulami]

Und wenn's nun doch an Apple liegt? Denen wird doch eine kleine Firma wie FAS doch am Allerwertesten vorbeigehen, oder?
Denn, nur mal um die äußerst beschränkten Möglichkeiten beim iPad in Bezug auf Import und Export von Daten (nur über die Cloud oder ITunes, keine Möglichkeit über Usbsticks Daten auszutauschen, etc.) zu erwähnen, vielleicht blocken die bei Apple ?
Das soll jetzt nicht als Bashing verstanden werden, aber ist es möglich, daß sich da Apple querstellt?

Logic gehört ja Apple - einen Teufel würden die tun und ihren hauseigenen Sequenzer nicht Supporten...aber wie sieht's da mit "Non-Big-Playern" aus, die nicht über Konzernhintergrund verfügen?

Da bin ich fast geneigt, denen die selbe chronische "Arschlochitis" zu attestieren wie dem Microsoft-Konzern...

Das würde immer noch nicht erklären, wieso FAS für Windoof extra einen ASIO-Treiber bastelt, wo doch ihr lustiges Windows den "far superior audio class 2.0 support gar nicht bieten kann". Wenn FAS konsequent gewesen wären, hätten sie gesagt - blasst uns in die Schuhe, wir wollen class compliant Betrieb am AxeFx - das geht bei Windows leider nicht, sorry ihr müsst ein Betriebssystem wählen, welches unseren Masterplan unterstützt - haha! Das ist doch Quatsch, oder? Also hat man eigens einen Treiber programmiert.
Theoretisch könnte es tatsächlich Apples Schuld sein, aber es ist gemessen am Beispiel von Blue Microphones eben auch höchst wahrscheinlich, dass da irgendwas Komisches in FAS soft usb controller geraten ist. Cliff nimmt ja immer noch nicht Stellung daz, weiso er für MAc nicht den gleichen Support bietet wie für Windows. Und es erklärt auch nicht wieso andere audio class 2.0 devices an Macs problemlos ihren Dienst tun....Presonus Audiobox USB ist auch so ein Teil. Für WIN braucht es Treiber, für MAc ist es class compliant - im Gegensatz zu FAS funktioniert es allerdings plattformübergreifend!

@ H575: Wie willst Du es dann bei Computer nennen, bei denen bestimmte Betriebsysteme nicht mehr geladen werden können, weil deren Hardwarearchitektur zu alt ist, nur um eine Funktion zu benutzen können, die mit der veralteten Hardwarearchitektur aber rein gar nichts gemeinsam hat? Okey - nennen wir es alterntiv "Funktionelle Obsoleszenz" damit auch die Haare schön gespalten bleiben

In der USB-Proper Log steht zwar tatsächlich Internal Fixed Clock

 

[funkstation777]

Dasselbe Problem hatte ich mit einer RME hammerfall. Da stellte RME den Treibersupport ab win7 ein, weil die Karte nur im Kompatibilitätsmodus funkte...
Ab einemgewissen Zeitpunkt macht es einfach keinen Sinn mehr, einer ehemaligen, gut funktionierenden Lösung hinterherzuweinen...wenn ich an die Fette Leistung denke, mit der mein 6-Kern Rechner (PC) mit SSDs , 32 Gb RAM
Mehrere Instanzen von Trilian, Omnisphere, Abbey Road Drums in Super Low latency ohne knackser im Studio One zuläßt....da wünsch ich mir die alte Schrottmühle mit der Hammerfall nicht mal eine Nanosekunde lang zurück, auch wenn die superstabil lief, wobei mein jetziger Rechner seit ich ihn in der Konfiguration habe, noch nicht mal 1x abgestürzt ist.

Das erwarte ich mir für den Preis neuerer Hardware aber auch, weswegen sich mein Zorn in Punkto " Grafikkarte zu alt, na geh ' keine Treiber mehr für diese oder jene Hardware...in Grenzen hält.

Ob das nun manche für den Weg des geringsten Widerstandes halten oder ein absolutes Zugeständnis an die Industrie ist mir total schnuppe, einige meiner "alten" Systeme laufen noch in Proberäumen befreundeter Bands und Funken tadellos...für manche muß es eben nicht immer der heiße Scheiß sein...

Und viele Leute aus den Foren vergessen meiner Meinung nach eben immer wieder auf den Hauptgrund für den Kauf des Axe...und das ist NICHT das Axe-Edit, oder?

Solange der Sound soooo unglaublich geil ist, und das Monster vor geilen Features nur so strotzt, ist doch das Axe-Edit
Eher nur ein Zuckerstreusel auf der Torte, oder?

 

[Pacosipulami]

Ich glaub ich hab die Rätsels Lösung! Falls mir jemand von Euch IT-Spezialisten das Thema "implicit feedback data endpoint vs. asynchronous data endpoint" und die Bedeutung der "Max Packet Size" (transaction opportunities per microframe) auf Deutsch erläutern kann, wage ich mal einen Versuch den USB soft controller "umzuschreiben". Da er ja eh flüchtig ist, kann dem AxeFx nichts passieren.....

FAS soll ruhig merken dass ich über den "Fanboy-Status" hinaus diskutieren kann. Ich glaube das hat nun selbst Cliff gemerkt

Yes, sort of. The host and peripheral clocks run at different speeds. For example the Axe-Fx clock might be 48.000001 kHz. The host clock might be 47.99999 kHz. Over time this error builds up. The peripheral cannot alter it's rate of transmission since it's clock is fixed. The host MUST adapt to the peripheral. This is accomplished using rate feedback.

This is very advanced stuff and probably over everyone's heads.

Ich könnte nun sehr böse sein: "Der Peripheral clock kann sich nicht verstellen" - muss er nicht, der Buffer sollte den Job übernehmen die Daten-Rate dem Host Clock anzupassen.

Ob WIN ebenfalls Audio Class 2.0 nutzt, ist ehrlich gesagt nicht wichtig wenn es gar nicht als Solches unterstützt werden kann, weil "Microsoft dosen't care" - ASIO nutzt darüber hinweg ein eigenes Protokoll. Aber das verstehen auch die wenigsten im internationalen Forum. Deshalb, so what?

Pacosipulami over and out!

Ich hab nun ne ganze Nacht getüftelt anstatt zu schlafen......wird lustig in paar Stunden Arbeiten zu gehen....aua!

 

[Pacosipulami]

Bin wieder zurück - kaum geschlafen, aber einsatzfähig!

Zusammengefasst:
Das AxeFx nutzt scheinbar seinen eigenen Clock, auch bei der Audio Class 2.0 implementierung, die nur unter OSX genutzt werden kann. Die Parameter haben zwar auch unter WIN Gültigkeit, werden dort einfach nicht gebraucht - sprich es wurde ein dedizierter Treiber dafür geschrieben (Cliff schreibt, 3rd party!). Das Problem ist scheinbar eben dass sich das AxeFx nicht an leichtem Clock Drift anpassen kann, da die Datenbuffer meiner Ansicht nach zu klein gewählt sind.

Erklärung:

Wird eine Millisekunde an Audio übertragen, wird diese vom Audio-Clock in 48 Samples unterteilt . Läuft nun der Audioclock des Host-Rechners nicht samplegenau mit dem seines eigenen Clockgenerators, ergeben sich differenzen, die nach einiger Zeit zu groben Fehler in der Datenübertragung führen können. Um dies zu verhindern, benutzt man einen Buffer, die solche Anpassungsschwierigkeiten ausgleichen. Ein Buffer darf man sich dabei als Daten-Zwischenspeicher vorstellen, der die einkommenden Daten für eine kleine Zeit zurückhält.

Es gibt zwei Orte um die Daten zu buffern, entweder man man nutzt einen speziellen Treiber (ASIO oder CoreAudio) auf dem Host, oder man definiert diese Buffergrössen im USB Controller. Class Compliant bedeutet in dieser Hinsicht nur, dass auf Grund eines bestimmten Definitionscode, die Funktion eines externen Gerätes bestummen werden kann, welches dann auf extra dafür bereitgestellte Resourcen direkt aus dem Betriebssystem zugreifen kann. Die jeweiligen Anpassungsparameter legt das Gerät aber in seinem Definitionsfile des USB Controllers fest.

Meiner Meinung nach ist die Definition der Datenbuffer und Buffergrösse des Definitionsfiles beim AxeFx II zu klein gewählt. Ebenso die Datenübertragungs-Definition der IN Endpunkte (also der Datenflussrichtung dem Host zugewandt) komplett anders, als die des erwähnten HS Audio Class 2.0 Gerät von Blue Microphones - welches ebenso über I/O-Kapazitäten verfügt und von mir deshalb einen guten Vergleich wert ist.

Endpunkte sind vordefinierte Unteradressen für den Datenfluss. Es geht immer jeweils ein Datenstrom zwischen zwei Endpunkten hin und her. So

 

[fbuerger]

Ich glaub ich hab die Rätsels Lösung! Falls mir jemand von Euch IT-Spezialisten das Thema "implicit feedback data endpoint vs. asynchronous data endpoint" und die Bedeutung der "Max Packet Size" (transaction opportunities per microframe) auf Deutsch erläutern kann, wage ich mal einen Versuch den USB soft controller "umzuschreiben". Da er ja eh flüchtig ist, kann dem AxeFx nichts passieren.....

Ich habe zwar NULL Ahnung davon, aber in der Hoffnung das es hilft:

Schau doch bitte in der Documentation von XCODE die "Technical Note TN2274" an. Tabelle 3-5 und danach wird die Berechnung der Maximum Packet Size beschrieben. Vielleicht ist es ja so, das sie tatsächlich vergessen haben, dass die unit Aus- und Eingänge hat, oder irgend so etwas ähnliches....

Aber wie ich Dich mittlerweile kenne, haste das schon längst "Assimiliert". Na denn, viel Spaß auf dem "normalen Job"

Gruß Frank

 

[fbuerger]

Was mir Anhand dieser TN2274 noch aufgefallen ist:

Screenshot meines AXE FX ist hier im Anhang.....Clock Source:....??? Was ist Standard???? Logic? Scheinbar ja....

Sonst müßte man ja in dem Audio-MIDI-Setup die Clock auf External Clock einstellen können. Ist auch in den TN2274 weiter unten beschrieben. Kapitel "Clock Entities".

(Btw. Die Benennung der Eingänge/Definition ist auch grottig, können es nicht 4 Mono Kanäle sein? Mir "zerreißt" es nämlich jedesmal meine fertigen Stereo-Templates-Dateien in Logic, in jedem anderen Audio-Interface geht dat' auch...)

 

[Pacosipulami]

Na denn, viel Spaß auf dem "normalen Job"

Den habe ich - es läuft momentan wie geschmiert! Notfall-Reps etc. wie aus dem Ei geprellt - ich hatte noch nie so ein guten Tag wie heute - dies obschon ich nur zwei Stunden Schlaf hatte (!!). Das Problem ist halt eben, dass das USB Interface nicht nur für Audio verwendet wird. Ich weiss noch immer nicht ob die Daten-Anbindung nur per Midi geschieht, oder dort ein speziell schnelles Datenprotokoll verwendet wird. Die meisten anderen Audio-Interfaces haben ja diese Doppelfunktion nicht, MIDI hingegen ist als Zusatz keine Besonderheit Nützt man nun eine softwareseitige Datenbufferung via 3rd party (oder bei Apple als "core audio" bezeichnet) Audio-Stream Protokoll, dann kann dort spezifisch für Audio Stream umgeschaltet werden. Bei Class Compliant fehlt mir diese Info.....oder ich weiss nicht wo suchen.

Ich denke aber dass bezüglich der Mac Performance genau dort der Hase im Pfeffer liegt

Ich stelle mir das ja alles "nur" vor, ich habe von solchem Zeugs nur eine "Basisahnung" aber eine geübte konzeptbasierte Denkweise und da ich so mit Cliff nicht wie ein Entwickler reden kann, muss ich es halt mit der "nasty customer methode" probieren. Da ich ja weiss dass ich den CEO direkt erreiche, wirble ich bewusst und unbewusst einige Dinge durcheinander um ihm die Infos zu entlocken, die er mir ansonsten niemals geben würde - erst war ich natürlich etwas sauer als er meine Aussagen durcheinander gebracht hat (da damit die ganze Fanboy-Meute erst recht auf mir hätte rumhacken können) , doch dann hab ich gemerkt, dass er mich auf direktem Weg zu der benötigten Info führt - das rechne ich ihm extrem hoch an!



Max packet size ist beim AxeFx II glaube 42byte Out und 84byte in - ich mache heute nochmals einen Read-Out mit USB-Prober. Und dann will ich mal probieren ob ich die Daten "verändern" kann.

 

[Pacosipulami]

Screenshot meines AXE FX ist hier im Anhang.....Clock Source:....??? Was ist Standard????

Standard ist die Standard Definition - die ist dabei nicht näher erläutert. Im USB Prober spuckt er die Info raus, dass es Local Fixed Clock sei - als doch das AxeFX als Clock-Source (und nicht Apples Host clock wie ich erst vermutet hatte) nützt. Die Anbindung funktioniert laut Cliff asynchron-isochron, wobei isochron bedeutet dass die Priorität bei der Übertragung auf der Datenrate und nicht auf deren Inhalt liegt.

 

[H-575]

@Funke:
... ja, man liest gelegentlich schon unterschwellig die Botschaften deutlich raus und daß Du nicht nur als Axe-Fest-&Forum-Entertainer (was Du zweifelsfrei bist!) am Start bist ;-) Schönen Urlaub!

 

[wildlive]

Lese ja schon ein wenig interessiert mit, da mich die technische Details immer interessieren. Nun habe ich von den Apple, PC und AXE Schnittstellen keine detaillierte Ahnung nur aus anderem beruflich bedingtem Hintergrund kann ich sagen, dass wenn Datenquelle und Senke mit auch noch so geringen unterschiedlichem Clock arbeiten es nach einer gewissen Zeit knallen muß, egal wie gering der Unterschied auch sein mag. Die Buffergroße zu ändern würde nur etwas bringen, wenn sich die Taktunterschiede über die Zeit ausgleichen. Das glaube ich aber in diesem Fall nicht (falls ich das Problem richtig verstanden habe!!). Toleranzen bei Quarzoszillatoren liegen zwar im ppm Bereich, aber auch das reicht schon aus. Eine übliche Lösung zwei auf unterschiedlichen (seien sie auch noch so klein) Abtastraten arbeitende Systeme miteinander sicher kommunizieren zu lassen in ein SRC (Sample Rate Converter). Wenn beide Geräte davon ausgehen, dass das Gegenüber entweder den eigenen Clock oder einen SRC nutz, ist ein Bufferüberlauf unausweichlich. Das ist dann ein Fehler in der Systemkonzeption eines der beiden oder beider Geräte. Jetzt stellt sich wohl nur die Frage wer zuerst da war Ein SRC bedeutet allerdings immer Aufwand und das Audiosignal wird dadurch auch nicht besser (erst Abtastrate durch Interpolationsfilter hochjubeln und dann durch Dezimationsfilter wieder runter.... dann noch eine Regelungsstrecke wegen der variablen Taktquellen... )! Eine bessere Lösung ist wohl immer nur einen Clock im System zu verwenden, den dann alle als Abtastrate verwenden. Keine Ahnung wie das von Apple aus angedacht ist.

Ich weiß nicht, ob ich das Problem richtig verstanden habe. Falls nicht, mein Gesülze einfach ignorieren. Falls doch, könnte dies das ein oder andere Problem erklären.

 

[Pacosipulami]

Ein Bufferüber- oder Unterlauf wäre kalkulierbar so lange man sich an die Specs der Audio Class driver hält, der einen Asynchronous-Betrieb vorsieht.
Die In- und Out-Buffer werden dabei über die USB Controller Description definiert, sie befinden sich aber im class audio driver, der Part des OS ist. Nun ist die Frage "wie" man sie auf Grund welcher möglichen gewünschten Performance konfiguriert. Soweit hab ich das mittlerweile kapiert.

Denn USB Audio Class 2.0 gibt es in zig Varianten von diversen Herstellern, alles läuft ohne Probleme am Mac oder auch an den neuen iPads (Stichwort RME!) rocksolid! Wenn nun FAS behauptet es läge an Apple, wieso können es dann andere Hersteller wie Apogee, RME, Presonus, Tascam, Blue etc. ohne die genannten Probleme?

Ich werde mal den aktuellen Bootloader-Treiber fürs Axe nehmen und ihn versuchen OS 10.6.8-audiokompatibel zu machen. Falls ich das hinkriege wäre die funktionelle Obsoleszenz gestoppt

 

[Pacosipulami]

btw *grins* http://forum.fractalaudio.com/axe-fx-ii-reviews/73242-not-worth-%A32000-9.html#post898989

 

[Pacosipulami]

The problem is that I am the only person here who can do USB firmware programming and I'm busy with other things. USB audio is very difficult. I hired a consultant a while back to help out and he was virtually useless (ironic because he actually helped write the USB spec but that shows you just how difficult USB is).

Soviel Ehrlichkeit lob ich mir....

You need to update your OS X in order to to use the Axe II as an interface. Per the support page:

Axe-Fx II USB Setup (167) for OS X Jun 21 2013 - Required for Axe-Fx II USB Audio and MIDI-over-USB functionality under Max OS X. Requires 10.5.7 for MIDI-over-USB and 10.7.4 for USB Audio.

Ich glaube die Sachlage ist klar - die Herausforderung auch.... heisst: V167 Audio für OSX 10.6.8. Heute Abend verschicke ich die Einladungen für die UOS-Group http://www.axefx.de/group.php?groupid=1