MiCaDo Projektbericht - artecLab - Universität Bremen
MiCaDo Projektbericht - artecLab - Universität Bremen
MiCaDo Projektbericht - artecLab - Universität Bremen
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Positionen der Klänge sowie Informationen darüber, wann ein solcher abzuspielen und wieder zu<br />
stoppen ist, sind dabei vom Master an alle Slaves zu verteilen.<br />
Problematisch ist hierbei, dass eine perfekte Synchronisation der Soundkarten über das Netzwerk<br />
praktisch unmöglich ist. Sendet beispielsweise der Master allen Slaves via UDP Multicast den Befehl,<br />
einen bestimmten Klang abzuspielen, so werden ihn die Empfänger in der Regel alle mit unterschiedlichen<br />
Verzögerungen ausführen. Letztere sind beispielsweise davon abhängig, wann ein Rechner<br />
das jeweilige Netzwerkpaket erhält, dessen Betriebssystem das Paket an die Cave-Anwendung weitergibt<br />
5 , diese es bearbeiten kann, und wann die von ihr gemachten neuesten Audioausgaben spätestens<br />
hörbar werden 6 . Werden diese Verzögerungen zu groß, dann nimmt der Benutzer ein, von<br />
zwei benachbarten Rechnern wiedergegebenes, Geräusch nicht mehr als eine einzige virtuelle Quelle<br />
wahr, sondern als zwei getrennte. Auch wird dann bei Richtungsveränderungen die Equal Power<br />
Eigenschaft hörbar verletzt, wenn zwei Rechner zu einem Zeitpunkt stark unterschiedliche Werte<br />
für den Zeitparameter t verwenden.<br />
Nach einer Betrachtung, mit welchen Verzögerungen zwischen den Leinwänden in der Praxis zu<br />
rechnen ist, haben wir uns jedoch für eine Realisierung des oben vorgestellten Systems entschieden,<br />
mit der Option, bei zu schlechten Ergebnissen auf die Verwendung einer Mehrkanalsoundkarte<br />
zurückzugreifen 7 . Bei Verwendung eines Ringpuffers von 512 Bytes für die Stereo-Soundausgabe in<br />
CD-Qualität 8 , deckt dieser genau 128 Stereo-Abtastwerte ab und somit etwa 2,9 ms. Bei den Netzwerkpaketen<br />
gehen wir einmal von einer Verzögerung von grob 0,3 ms aus, was uns nach einzelnen<br />
Tests durchaus realistisch erscheint. In dieser Verzögerung ist eine Scheduling Latenz von unter 0,1<br />
ms in etwa 92% der Fälle 9 bereits enthalten. Insgesamt haben wir demnach mit einer durchschnittlichen<br />
Latenz zwischen 3 und 4 ms zu rechnen. Wenn man bedenkt, dass der Schall bei Raumtemperatur<br />
etwa 2,92 ms benötigt, um eine Strecke von einem Meter zurückzulegen, scheinen dies relativ<br />
gute Rahmenbedingungen zu sein: In einem Kinosaal der Größe 15 m × 15 m sind abhängig von<br />
der Hörposition Verzögerungen von bis zu 60 ms zwischen dem Eintreffen der Schallwellen der<br />
einzelnen Boxen beim Hörer möglich 10 . Unser Cave hat deutlich kleinere Abmessungen, der Schall<br />
benötigt daher nur wenige Millisekunden, um von einer Leinwandseite zur gegenüberliegenden zu<br />
gelangen. Im Vergleich zum Szenario des Kinosaals erschien uns die im Cave zu erwartende (eben-<br />
5 Stichwort: Kernel Latency.<br />
6 Dies ist abhängig von der Größe des verwendeten Audio-Ringpuffers.<br />
7 Unter Wechsel von SDL mixer auf eine andere Soundbibliothek wie OpenAL, siehe auch [OAL04].<br />
8 16 Bit pro Abtastwert und Kanal bei 44,1 kHz Abtastrate ergibt eine Datenrate von 176.400 Bytes/sec.<br />
9 Wir stützen uns hier einmal auf [Wil02], eine Untersuchung des Linux Kernels 2.4.17 zu diesem Thema.<br />
10 Im Gegensatz zu unserem Szenario ist diese Verzögerung über die Zeit konstant.<br />
83