Bearbeiten von „RoarAudio/Vortrag/Erster Vortrag“

Zu diesem Zweck werden mehre Protokolle unterstützt: [[UNIX Domain Socket]]s für lokale Verbindungen sowie TCP/IP und [[DECnet]] für Verbindungen mit entfernten Rechnern. Auch existiert Support für verschiedene Proxy Typen.

Ein Stream Objekt stellt einen eigentlichen Audio Datenstrom dar. Dieses Objekt beinhaltet diverse Informationen über den Datenstrom: Informationen wie der roard ihn auslesen kann, Sample Rate/Bits/Channels, Meta Daten und vieles mehr. Ein Stream gehört immer zu einem Client, wobei der Client auch der roard selbst sein kann. Er lässt sich durch ''attachen'' wechseln. Dies kommt zum Einsatz um Hintergrund-Streams zu ermöglichen.

Bei jedem Audio Datenstrom der in den roard hinein oder heraus fließt handelt es sich um einen Stream. Dies schließt Datenströme zu Geräten wie Soundcards mit ein. Hierdurch ist eine maximale Flexibilität gegeben.

Es gibt diverse verschiedene Streamtypen. Die folgende Tabelle beschreibt sie kurz:

  | Dieser Stream dient zum Zwischenschalten von Filtern im Mixer

Beim Mischen in Realtime kommen zu den Problemen, die beim normalen Mischen von Audio auftreten, noch weitere hinzu.

* Resampling - Wenn nicht alle Streams dieselbe Abtastfrequenz haben müssen die betroffenen Streams auf die Abtastrate des Ausgangs umgerechnet werden. Hierzu gibt es diverse Verfahren. Man kann sich das etwa wie das Skalieren eines Bildes vorstellen: Es gibt Filter die schnell sind und welche die gut sind. Muss man in Realtime resampeln so muss man vor allem schnell sein, will aber auch noch möglichst gut sein. Viele Soundserver behalten schlichtweg die Pegel entsprechend der neuen Abtasterate länger oder kürzer bei (s.g. zoh - Zero Order Hold). Dies erzeugt Rechteck Signale welche wiederum diverse Oberwellen erzeugen. RoarAudio setzt hier Polynomapproximation dritten Grades ein. Dies reduziert die Oberwellen schon deutlich dank leichter Tiefpass Eigenschaft.

* Vor allem beim Pegel-Umrechnen kommt es selbstverständlich zu Rechenungenauigkeiten. Um diese zu minimieren skaliert RoarAudio die Signale auf bis zu ihrer doppelten Größe um Rechenungenauigkeiten zu vermeiden. bei einem 16 Bit Eingangssignal wird als Beispiel auf 32 Bit skaliert was zusätzliche 96dB Rauschabstand während der Umrechnung liefert.

* <s>Einige Formate sind nicht Frame basierend. Dies sind vor allem MIDI Formate. Hier kann es passieren daß die Synchronisation zwischen diesen Streams und den anderen sich an Frame-Grenzen treffe. Dies kann zu unschönen Nebeneffekten führen. Manche Codecs sind auch nur in der Lage auf gewisse Zeitraster Ende-Marken zu setzen was in unsauberen Enden mit Artefakten enden kann. Im Realtime Bereich lässt sich dies nicht korrigieren und solche Codecs sollten vermieden werden.</s>

* Wie jede Hardware besitzen Soundkarten eine Verzögerung. Das heißt daß sie eine gewisse Zeit brauchen zwischen Erhalt von Daten und deren Ausgabe. Diese Zeit liegt im Bereich von wenigen Millisekunden (z.B. Studio Karten) und kann bis in den Bereich von mehren hundert Millisekunden gehen (z.B. 2.5 Euro USB Karten von $SUPERMARKT), je nach Karte. Die meisten Karten bieten aber eine Möglichkeit abzufragen wo sie gerade in ihrem Puffer sind. Wie dies genau funktioniert ist von Karte zu Karte unterschiedlich. Der Treiber der Karte ist dafür zuständig diese Funktionen an höhere Interfaces (OSS, alsa, sndio,...) weiterzureichen und den Applikationen zur Verfügung zu stellen.

* Neben dem Delay in der Hardware erzeugen selbstverständlich auch der Kernel und die Treiber eine weitere Verzögerung. Dies passiert aus vielen Gründen: Der Programmcode muss natürlich erst einmal ausgeführt werden. Auch werden Interupts nicht unbedingt sofort bearbeitet (zum Beispiel weil gerade ein anderer, höherwertiger bearbeitet wird).

* '''Ignorieren''' - Diverse Probleme lassen sich schlichtweg einfach ignorieren. Dies sind vor allem Probleme die sich statistisch über die Zeit aufheben. Ist diese Strategie möglich so sollte sie verfolgt werden im Sinne von KISS (Keep It Small and Simple). Sie kann natürlich auch extrem daneben liegen und man sollte sich um eine echte Lösung bemühen.

* '''TOS''' - Setzen des TOS (Type Of Service) Feldes bei IP mag helfen. Viele Backbone Provider ignorieren dieses Feld zwar aber im LAN kann es durchaus helfen. Gerade bei anderer starker, lang packetiger Kommunikation zwischen dem eignen und dem Ziehl Rechner (file transfers).

* '''QoS''' - Benutzung von QoS (Quality of Service) kann im Backbone Bereich die Latenz erheblich senken da man das Puffer-Verhalten der Geräte beeinflusst. Der Nachteil ist, daß hierzu Unterstützung da sein muss. mit IPv6 scheint sich hier aber einiges zu bessern.

* '''Künstlicher Delay''' - Es besteht die Möglichkeit einzelne Streams oder Ereignisse künstlich leicht zu verzögern. Hierdurch kann ein Abgleich der Latenzen gemacht werden was dazu dient Synchronität herzustellen. Normalerweise werden alle Streams so lange verzögert bis sie eine ''künstliche'' Latenz gleich dem Stream haben der die höchste Latenz aufweist.

* '''Resampling''' - Sind mehre Clocks beteiligt oder kommen die Daten etwas zu schnell oder zu langsam kann man leichtes Resampling betreiben. Das heißt das das Signal künstlich gestaucht oder in die Länge gezogen wird. Geschieht dies nicht ruckartig kann das Gehör den Unterschied nicht wahrnehmen solange dieses Resamping nur in kleinen Bereichen passiert (je nach Literatur 2% bis 5%, Werte die größer sind als die Ungenauigkeit von Quarzen und somit geeignet sind um Clock driffting auszugleichen.).