Die Anwendung des AES-24 ID Entwurfs auf Audiogeräte
Vortrag zur Tonmeistertagung 1994
Kurze Vorbemerkung zum Thema
Dieser Bericht beschreibt, wie das vorläufige AES-24 ID Protokoll auf einen typischen, graphischen 1/3-Oktav Entzerrer angewendet werden kann. Die Änderungen der sogenannten „Amber“-Revision wurden, wie bei der Sitzung der SC-10-2 Arbeitsgruppe vorgeschlagen, bereits entsprechend berücksichtigt. Das Ziel dieses Vortrages ist es, das Protokoll weitgehend verständlich zu erläutern und eventuelle erste Versuche im Labor zu ermöglichen. Protokolle sollen eine allgemein anzuwendende Form der Datenübertragung definieren. Die Erfordernisse der Industrie wie auch kostengünstige technische Lösungen sollen dabei berücksichtigt werden. Dies verhindert aber leider eine schnelle Vollendung dieses Standards. Wir bitten, diesen Umstand bei der Bewertung des nachstehenden Textes zu berücksichtigen.
Das AES-24 ID Protokoll bietet einen neuen Ansatz, verschiedenste Audiogeräte mittels geeigneter Rechner fernsteuerbar zu machen. Ansätze zur Harmonisierung der Bemühungen in der Industrie hat es in den letzten Jahren viele gegeben. Die kommerziell erfolgreichste, wenn auch leider in ihren Möglichkeiten sehr beschränkte Lösung stellte das MIDI-Protokoll dar. Mittlerweile ist dieses Protokoll gute 15 Jahre alt und basiert immer noch auf den Hardwarebeschränkungen der Zeit, zu der es entworfen wurde. Daher ist man bemüht, zügig einen neuen Standard ins Leben zu rufen, der wiederum herstellerübergreifende Gültigkeit besitzt.
Wie das leider bei der Erstellung eines Protokolls häufig der Fall ist, gibt es mittlerweile viele Ansätze, die aber meist nur proprietäre Insellösungen darstellen und von der Mehrheit – aus rein kommerziellen wie Prestigegründen – abgelehnt werden. Grundsätzlich sind alle diese Lösungen schon vom Ansatz her nicht kompatibel. Daher ist eine gemeinsame Steuerung zur Zeit nicht möglich.
Schnelle und preiswerte Datenübertragung bis zu 130 MB/sec stehen heute zur Verfügung. Daher ist es nicht notwendig, eine Master-Slave Konfiguration zu implementieren. Vielmehr ist es heute möglich, dezentrale Intelligenz bzw. das sogenannte Peer-to-Peer Design erfolgreich anzuwenden.
Vergleich Master-Slave mit Peer-to-Peer
Die AES (Audio Engineering Society) hat sich entschlossen, durch die Bildung von Arbeitsgruppen für eine schnellere Erstellung eines möglichen industrieweiten Protokolls zu sorgen. Dabei wird beabsichtigt, durch eine geeignete Struktur Weiterentwicklungen möglich zu machen und den Herstellern entsprechenden Spielraum zu lassen. Um dies zu erreichen, einigte man sich auf einen Ansatz, der sieben Ebenen innerhalb des Steuerprotokolls vorsieht. Ebene 1 stellt hierbei die physische Plattform, Ebene 7 die Applikationsoberfläche (z.B. Bedienfeld auf dem Computermonitor) dar.
Die Ebenen unterteilen sich wie folgt:
Ebene 1-4: Data Communication (betreut von der
SC-10-1 Abeitsgruppe)
Ebene 5-7: Application Protocol (SC-10-2 Arbeitsgruppe)
Ebene 7: Information (SC-10-3 Arbeitsgruppe)
Das OSI 7-Layer-Modell
Der Vorteil dieser Aufteilung in 7 Ebenen liegt vor allen Dingen darin, daß jede Ebene im Bedarfsfalle durch neue Erkenntnisse ergänzt bzw. ausgetauscht wird. Hinzu kommt die Eigenschaft, den Kommunikationsaufwand verhältnismäßig gering halten zu können, da jede Ebene nur mit den beiden unmittelbar benachbarten Informationen austauschen muß.
Einen dem AES-Standard übrigens sehr verwandten Vorschlag bildet das MediaLink Protokoll der Firma Lone Wolf. Im Unterschied zum AES-Protokoll verwendet es nur 3 Ebenen. Dieser augenscheinliche Nachteil wird aber durch Kostenersparnis und ein wesentlich einfacheres Steuerprotokoll kompensiert.
Anhand eines Bespieles wollen wir uns den Unterschied des Prokolls zu dem gängigen PA-422 Steuercode betrachten. Die nachstehende Graphik erläutert auf anschauliche Weise die Eigenschaften beider Protokolle und den offensichtlichen Vorteil des AES-24 ID:
Datenaustausch AES-24 und PA-422
Der offensichtliche Nachteil liegt – abgesehen von der antiquierten Master-Slave Konfiguration mit einem Datenaustausch zwischen den Slaves ausschließlich über den Master – vor allen Dingen in der Tatsache, daß konstruktionsbedingt Informationspakete abgesandt werden. Diese Pakete enthalten überflüssigerweise alle Informationen zur Einstellung des jeweilig gemeinten Gerätes, anstatt nur der zu ändernden Parameter. Hierdurch ergibt sich zwangsläufig eine erheblich größere Datenmenge, die zwar den Leiter (egal ob LWL oder „Twisted Pair“) wahrscheinlich nicht blockiert, wohl aber den Master erheblich in Anspruch nimmt. Hinzu kommt eine größere Fehleranfälligkeit, die bereits bei kleinen Ursachen (z.B. Format-Mismatch) zum Systemstillstand führt.
Das AES-24ID Protokoll hingegen spricht zuerst die gemeinten Objekte an. Erst dann werden die Änderungen, und nur diese (!) durchgegeben. Bei dem angestrebten Peer-to-Peer Design, welches die Vorteile der dezentralen Intelligenz voll ausnützt, wird daher die notwendige Datenrate dramatisch beschränkt. Hinzu kommt die äußerst positive Eigenschaft, daß Fehler einfach ignoriert werden. Wenn also z. B. das 30. Band eines 28-bandigen Entzerrers angesprochen wird, so wird diese fehlerhafte Nachricht einfach ignoriert. Der Vollständigkeit halber sei angefügt, daß das Protokoll eine Untersuchung der angeschlossenen Geräte vornimmt (bidirektionaler Informationsaustausch!) und daher von Anfang an solche fehlerhaften Daten nicht abgesandt werden können.
Leider sprengt der Umfang des Protokolls die Möglichkeiten eines halbstündigen Vortrages. Daher bitte ich Sie, sich bei der AES – Europa-Büro Brüssel – die verfügbare Version (die ja nur als Diskussionsgrundlage dienen kann) anzufordern. Wenn sich auch die Form noch ändern kann und wahrscheinlich wird, so ist es jedem ernsthaft Interessierten dringend zu empfehlen, bereits heute mit entsprechenden Vorbereitungen zu beginnen.
