RoarAudio/Vortrag/Erster Vortrag - Versionsgeschichte

Ph3-der-loewe: hat „RoarAudio/Vortrag“ nach „RoarAudio/Vortrag/Erster Vortrag“ verschoben: Restrukturierung der Artikel

2010-07-05T13:14:11Z

hat „RoarAudio/Vortrag“ nach „RoarAudio/Vortrag/Erster Vortrag“ verschoben: Restrukturierung der Artikel

← Nächstältere Version	Version vom 5. Juli 2010, 13:14 Uhr
(kein Unterschied)

Ph3-der-loewe: /* Netzwerk-Transparenz */ innerwikilinks

2009-12-30T13:01:44Z

Netzwerk-Transparenz: innerwikilinks

← Nächstältere Version		Version vom 30. Dezember 2009, 13:01 Uhr
Zeile 77:		Zeile 77:
	RoarAudio ist Netzwerks-transparent, das heißt das Applikationen keinen Unterschied sehen zwischen Verbindungen mit einer lokalen Instanz oder einer auf einem anderen Rechner.		RoarAudio ist Netzwerks-transparent, das heißt das Applikationen keinen Unterschied sehen zwischen Verbindungen mit einer lokalen Instanz oder einer auf einem anderen Rechner.

	Zu diesem Zweck werden mehre Protokolle unterstützt: UNIX Domain ~~Sockets~~ für lokale Verbindungen sowie TCP/IP und DECnet für Verbindungen mit entfernten Rechnern. Auch existiert Support für verschiedene Proxy Typen.		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.

	==== Background Streams ====		==== Background Streams ====

Ph3-der-loewe: +kat

2009-11-27T22:28:35Z

+kat

← Nächstältere Version		Version vom 27. November 2009, 22:28 Uhr
Zeile 312:		Zeile 312:
	* ''immer gerne''		* ''immer gerne''

			[[Kategorie:RoarAudio]]
	[[Kategorie:Vortrag]]		[[Kategorie:Vortrag]]
	[[Kategorie:Software]]		[[Kategorie:Software]]
	[[Kategorie:Sound]]		[[Kategorie:Sound]]

Ph3-der-loewe: Hinweis ueber versionen

2009-05-27T08:28:30Z

Hinweis ueber versionen

← Nächstältere Version		Version vom 27. Mai 2009, 08:28 Uhr
Zeile 1:		Zeile 1:
			{{Hinweis\|Dieser Vortrag bezieht sich auf die Versionen 0.2. Er ist nicht kompatibel mit den Versionen 0.1 und nur bedingt mit den Versionen 0.3/1.0.}}

	<div style="background:#fee846;text-align:left; color: #000;font-weight:bold;font-size:125%;margin: 0px 5px 0px 0; padding: 4px 4px 4px 14px;">Was ist RoarAudio?</div>		<div style="background:#fee846;text-align:left; color: #000;font-weight:bold;font-size:125%;margin: 0px 5px 0px 0; padding: 4px 4px 4px 14px;">Was ist RoarAudio?</div>
	<div style="margin: 0 5px 5px 0; padding: 1em 1em 1em 1em; border: 1px solid #fee846; background-color:#fffdf5;">		<div style="margin: 0 5px 5px 0; padding: 1em 1em 1em 1em; border: 1px solid #fee846; background-color:#fffdf5;">

Che: /* Probleme des Realtime Audio Mischens */ Typo

2009-02-06T10:35:25Z

Probleme des Realtime Audio Mischens: Typo

Che: /* Clients und Streams */ Typo

2009-02-06T09:51:31Z

Clients und Streams: Typo

← Nächstältere Version		Version vom 6. Februar 2009, 09:51 Uhr
Zeile 135:		Zeile 135:
	Ein Client Objekt verkörpert einen (Netzwerk) Client, zum Beispiel einen Player oder ein Steuerprogramm wie roarctl. Es kann auch Stream Objekte assoziiert haben (Beispielsweise im Falle von Abspielen von Musik).		Ein Client Objekt verkörpert einen (Netzwerk) Client, zum Beispiel einen Player oder ein Steuerprogramm wie roarctl. Es kann auch Stream Objekte assoziiert haben (Beispielsweise im Falle von Abspielen von Musik).

	Ein Stream Objekt stellt einen eigentlichen Audio Datenstrom da. 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. Er lässt sich durch ''attachen'' wechseln. Dies kommt zum Einsatz um Hintergrund Streams zu ermöglichen.		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. ~~Hier durch~~ ist eine maximale Flexibilität gegeben.		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.

	===== Stream Typen =====		===== Stream Typen =====
	Es gibt diverse ~~Verschiedene Stream typen~~. Die folgende Tabelle ~~Beschreibt~~ sie kurz:		Es gibt diverse verschiedene Streamtypen. Die folgende Tabelle beschreibt sie kurz:

	{\| class="wikitable"		{\| class="wikitable"
Zeile 157:		Zeile 157:
	\| Filter		\| Filter
	\| bidirektional		\| bidirektional
	\| Dieser Stream dient zum ~~zwischenschalten~~ von Filtern im Mixer		\| Dieser Stream dient zum Zwischenschalten von Filtern im Mixer
	\|-		\|-
	\| Output		\| Output

Che: /* Kompatibilitäts Bibliotheken */ Typo

2009-02-06T09:47:57Z

Kompatibilitäts Bibliotheken: Typo

← Nächstältere Version		Version vom 6. Februar 2009, 09:47 Uhr
Zeile 95:		Zeile 95:
	Dazu müssen sie schlichtweg einfach anstelle der Bibliothek des entsprechen Systems installiert werden und leiten dann alle Anfragen an RoarAudio weiter. Dies geschieht natürlich nur im Rahmen des Funktionsumfang der entsprechenden Bibliothek.		Dazu müssen sie schlichtweg einfach anstelle der Bibliothek des entsprechen Systems installiert werden und leiten dann alle Anfragen an RoarAudio weiter. Dies geschieht natürlich nur im Rahmen des Funktionsumfang der entsprechenden Bibliothek.

	Die mit Abstand wohl wichtigste ist '''libroaresd''' welche das [[EsounD]] Interface emuliert. das EsounD Interface wird von den allermeisten Applikationen unterstützt da es das wohl älteste Soundserver Interface ist. Es existiert seit 1998.		Die mit Abstand wohl wichtigste ist '''libroaresd''', welche das [[EsounD]] Interface emuliert. das EsounD Interface wird von den allermeisten Applikationen unterstützt da es das wohl älteste Soundserver Interface ist. Es existiert seit 1998.

	Weitere Kompatibilitäts Bibliotheken gibt es für das YIFF Sound System, KDEs aRtsc und PulseAudio. Zusammen mit den existierenden Plugins deckt dies nahezu den vollständigen Player Markt fuer GNU/Linux und BSD ab.		Weitere Kompatibilitäts Bibliotheken gibt es für das YIFF Sound System, KDEs aRtsc und PulseAudio. Zusammen mit den existierenden Plugins deckt dies nahezu den vollständigen Player Markt fuer GNU/Linux und BSD ab.

Che: /* Meta Daten */ Typo

2009-02-06T09:46:38Z

Meta Daten: Typo

← Nächstältere Version		Version vom 6. Februar 2009, 09:46 Uhr
Zeile 81:		Zeile 81:

	==== Meta Daten ====		==== Meta Daten ====
	RoarAudio hat die Fähigkeit auf per Stream Basis Meta Daten ab zu legen. Die Mechanismen sind denen von Vorbis Comments ~~nach empfunden~~ und können prinzipiell mehr. Einiges davon ist allerdings noch nicht vollständig implementiert.		RoarAudio hat die Fähigkeit auf per Stream Basis Meta Daten ab zu legen. Die Mechanismen sind denen von Vorbis Comments nachempfunden und können prinzipiell mehr. Einiges davon ist allerdings noch nicht vollständig implementiert.

	Es besteht neben dem ~~Manuellen~~ Setzen die Möglichkeit ~~das~~ ein Player sie setzt und das ''roard'' sie selbstständig setzt. Im letzteren Falle werden diese von ~~Verschiedenen~~ anderen Streams zusammen gesetzt. Dies kann nützlich sein um automatisch beim Streaming die ~~Meta daten~~ von einem Player zu übernehmen um die Titel Informationen weiter zu führen. Manuelles setzen ~~Mag~~ als Beispiel interessant sein um den Sendernamen zu setzen.		Es besteht neben dem manuellen Setzen die Möglichkeit daß ein Player sie setzt und das ''roard'' sie selbstständig setzt. Im letzteren Falle werden diese von verschiedenen anderen Streams zusammen gesetzt. Dies kann nützlich sein um automatisch beim Streaming die Metadaten von einem Player zu übernehmen um die Titel-Informationen weiter zu führen. Manuelles setzen mag als Beispiel interessant sein um den Sendernamen zu setzen.

	==== Virtual IO ====		==== Virtual IO ====

Che: /* Netzwerk-Transparenz */ Typo

2009-02-06T09:44:47Z

Netzwerk-Transparenz: Typo

← Nächstältere Version		Version vom 6. Februar 2009, 09:44 Uhr
Zeile 73:		Zeile 73:

	==== Netzwerk-Transparenz ====		==== Netzwerk-Transparenz ====
	RoarAudio ist ~~Netzwerk~~ transparent, das heißt das Applikationen keinen Unterschied sehen zwischen Verbindungen mit einer lokalen Instanz oder einer auf einem anderen Rechner.		RoarAudio ist Netzwerks-transparent, das heißt das Applikationen keinen Unterschied sehen zwischen Verbindungen mit einer lokalen Instanz oder einer auf einem anderen Rechner.

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

	==== Background Streams ====		==== Background Streams ====

Che: /* Codecs */ Typo

2009-02-06T09:43:44Z

Codecs: Typo

← Nächstältere Version		Version vom 6. Februar 2009, 09:43 Uhr
Zeile 68:		Zeile 68:
	RoarAudio zeichnet sich dadurch aus daß er zusätzlich zu PCM Rohdaten auch höher Codecs versteht. Dies hat mehre Vorteile:		RoarAudio zeichnet sich dadurch aus daß er zusätzlich zu PCM Rohdaten auch höher Codecs versteht. Dies hat mehre Vorteile:

	* Der Server kann Streams in höheren Codecs selbstständig verarbeiten. Dies ist zum Beispiel wichtig um Webradio als Background Stream ~~ab zu spielen~~.		* Der Server kann Streams in höheren Codecs selbstständig verarbeiten. Dies ist zum Beispiel wichtig um Webradio als Background Stream abzuspielen.
	* Es ist dem Server möglich direkt Streaming-Server wie [[icecast]] zu bedienen. Es ist keine weitere ''lange pipe'' nötig um Webradio zu senden. Dies verringert die Störanfälligkeit erheblich und verringert die Latenz, da pipe-Puffer entfallen.		* Es ist dem Server möglich direkt Streaming-Server wie [[icecast]] zu bedienen. Es ist keine weitere ''lange pipe'' nötig um Webradio zu senden. Dies verringert die Störanfälligkeit erheblich und verringert die Latenz, da pipe-Puffer entfallen.
	* Auch ist es nur mit stark komprimierenden Codecs möglich über die dem Heim-Anwender zur Verfügung stehenden Schmalband Anschlüsse Audio entweder von Client zu Server oder zwischen zwei Servern auszutauschen. Auch eine Kopplung über ISDN Kanäle ist so möglich.		* Auch ist es nur mit stark komprimierenden Codecs möglich über die dem Heim-Anwender zur Verfügung stehenden Schmalband-Anschlüsse Audio entweder von Client zu Server oder zwischen zwei Servern auszutauschen. Auch eine Kopplung über ISDN Kanäle ist so möglich.

	==== Netzwerk-Transparenz ====		==== Netzwerk-Transparenz ====

← Nächstältere Version		Version vom 6. Februar 2009, 10:35 Uhr
Zeile 227:		Zeile 227:

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

	Die wichtigsten Probleme sind:		Die wichtigsten Probleme sind:

	* Resampling - Wenn nicht alle Streams dieselbe ~~Abtastfrequens~~ 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 ~~Abtaste Rate~~ 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.		* 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.
	* Da nicht für den gesamten Titel der Amplituden-Gang bestimmt werden kann ist es möglich daß es zu sogenanntem Clipping kommt. Clipping bezeichnet das Problem, daß die Summe der Amplituden aller Eingangssignale größer ist als der zulässige Wertebereich. In diesem Falle wird das Ausgangssignal geclippt, sprich es wird auf den maximalen sich im zulässigen Wertebereich liegenden Wert herunter gesetzt. Dies lässt sich nicht vollkommen vermeiden aber durch geschickte Wahl des Mischverfahrens reduzieren. Es empfiehlt sich dennoch einen ReplayGain einzubeziehen. Dieser kann das Clipping zwar auch nicht komplett verhindern aber der Soundserver kann besser abschätzen wie die Gefahr für Clipping ist und rechtzeitig reagieren.		* Da nicht für den gesamten Titel der Amplituden-Gang bestimmt werden kann ist es möglich daß es zu sogenanntem Clipping kommt. Clipping bezeichnet das Problem, daß die Summe der Amplituden aller Eingangssignale größer ist als der zulässige Wertebereich. In diesem Falle wird das Ausgangssignal geclippt, sprich es wird auf den maximalen sich im zulässigen Wertebereich liegenden Wert herunter gesetzt. Dies lässt sich nicht vollkommen vermeiden aber durch geschickte Wahl des Mischverfahrens reduzieren. Es empfiehlt sich dennoch einen ReplayGain einzubeziehen. Dieser kann das Clipping zwar auch nicht komplett verhindern aber der Soundserver kann besser abschätzen wie die Gefahr für Clipping ist und rechtzeitig reagieren.
	* 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 ~~auf~~ 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.		* 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>Werden Signale mit verschiedenen Pegeln gemischt so kann es sinnvoll sein mit der Breite der Ausgangs-Samples hoch zu gehen. Als Beispiel: wenn zwei Signale mit je 16 Bit mit den Pegeln 1 und 1/4 gemischt werden reduziert der Rauschabstand des zweiten Signals um 12dB. Man sollte überlegen auf 24 Bit am Ausgang zu wechseln. Die Allgemeine Regel lautet: für den Faktor 2 oder 6dB die ein Signal abgeschwächt wird braucht man am Ausgang ein Bit mehr. Wenn mal also eine Hintergrund-Musik mit -48dB auf Sprache mischt (durchaus realistisch) muss man von 16 Bit am Ausgang auf 24 Bit hoch gehen um keinen Qualitäts-Verlust der Musik zu erhalten.</s>		* <s>Werden Signale mit verschiedenen Pegeln gemischt so kann es sinnvoll sein mit der Breite der Ausgangs-Samples hoch zu gehen. Als Beispiel: wenn zwei Signale mit je 16 Bit mit den Pegeln 1 und 1/4 gemischt werden reduziert der Rauschabstand des zweiten Signals um 12dB. Man sollte überlegen auf 24 Bit am Ausgang zu wechseln. Die Allgemeine Regel lautet: für den Faktor 2 oder 6dB die ein Signal abgeschwächt wird braucht man am Ausgang ein Bit mehr. Wenn mal also eine Hintergrund-Musik mit -48dB auf Sprache mischt (durchaus realistisch) muss man von 16 Bit am Ausgang auf 24 Bit hoch gehen um keinen Qualitäts-Verlust der Musik zu erhalten.</s>
	* <s>Einige Formate sind nicht Frame basierend. Dies sind vor allem MIDI Formate Hier kann es passieren ~~das~~ 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>		* <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>


Zeile 241:		Zeile 241:
	Die wichtigsten Störfaktoren sind:		Die wichtigsten Störfaktoren sind:

	* 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 ~~ab zu fragen~~ 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.		* 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 ~~erzeugt~~ selbstverständlich auch der Kernel und die Treiber eine ~~weiter~~ Verzögerung. Dies passiert aus vielen Gründen: Der Programmcode muss natürlich erst einmal ausgeführt werden. Auch werden Interupts nicht ~~um bedingt~~ sofort bearbeitet (zum Beispiel weil gerade ein anderer, höherwertiger bearbeitet wird).		* 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).
	* Die nächste Schicht, die Sound APIs, erzeugen auf ähnliche Weise weitere Delays. Hier kommt dazu das viele mit relativ großen Puffern arbeiten (Beispielsweise EsounD mit 0.28sec - im Vergleich zu roard mit Standard Puffer von 0.01sec). Die Puffergröße ist in dem meisten Fällen die kleinste Einheit in der Synchronität gewährleistet werden kann.		* Die nächste Schicht, die Sound APIs, erzeugen auf ähnliche Weise weitere Delays. Hier kommt dazu das viele mit relativ großen Puffern arbeiten (Beispielsweise EsounD mit 0.28sec - im Vergleich zu roard mit Standard Puffer von 0.01sec). Die Puffergröße ist in dem meisten Fällen die kleinste Einheit in der Synchronität gewährleistet werden kann.
	* Da die meisten Systeme (alle auf denen RoarAudio läuft) Multitasking betreiben stellt sich ein weiteres Problem: Der entsprechende Prozess muss eine Zeitscheibe bekommen bevor er reagieren kann. Läuft ein anderer Prozess gerade so muss er potentiell warten. Auf den meisten POSIX kompatiblem Systemen basiert das Multitasking zwar auf Ereignissen, sprich ein Prozess läuft so lange bis ein anderer ein Ereignis zu bearbeiten hat (keine feste Zeitscheiben-Länge), was dazu führt das dieses Problem ist nicht all zu groß ist. Aber es kann natürlich gerade ein anderer Prozess mit höherer Priorität laufen der ein anderes Ereignis bearbeitet und somit nicht vom Kernel unterbrochen wird.		* Da die meisten Systeme (alle auf denen RoarAudio läuft) Multitasking betreiben stellt sich ein weiteres Problem: Der entsprechende Prozess muss eine Zeitscheibe bekommen bevor er reagieren kann. Läuft ein anderer Prozess gerade so muss er potentiell warten. Auf den meisten POSIX kompatiblem Systemen basiert das Multitasking zwar auf Ereignissen, sprich ein Prozess läuft so lange bis ein anderer ein Ereignis zu bearbeiten hat (keine feste Zeitscheiben-Länge), was dazu führt das dieses Problem ist nicht all zu groß ist. Aber es kann natürlich gerade ein anderer Prozess mit höherer Priorität laufen der ein anderes Ereignis bearbeitet und somit nicht vom Kernel unterbrochen wird.
Zeile 255:		Zeile 255:
	{{Vortrags Zeit\|10}}		{{Vortrags Zeit\|10}}

	* '''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.		* '''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 ignoriren~~ 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).		* '''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 da die Latenz erheblich senken da man das Puffer ~~verhalten~~ der Geräte beeinflusst. Der Nachteil ist ~~das~~ hierzu Unterstützung da sein muss. mit IPv6 scheint sich hier aber einiges zu bessern.		* '''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.
	* '''Geschickte Auswahl von Algorithmen und Protokollen''' - Die Auswahl der Algorithmen und Protokolle ist entscheidend. Für die meisten Aufgaben gibt es mehre mögliche Lösungen (''Viele Wege führen nach Rom''). Aber nicht alle sind gleich gut geeignet. Deswegen sollte hier eine sinnvolle Auswahl getroffen werden.		* '''Geschickte Auswahl von Algorithmen und Protokollen''' - Die Auswahl der Algorithmen und Protokolle ist entscheidend. Für die meisten Aufgaben gibt es mehre mögliche Lösungen (''Viele Wege führen nach Rom''). Aber nicht alle sind gleich gut geeignet. Deswegen sollte hier eine sinnvolle Auswahl getroffen werden.
	* '''Künstlicher Delay''' - Es besteht die Möglichkeit einzelne Streams oder Ereignisse künstlich leicht ~~heraus~~ zu ~~zögern~~. Hierdurch kann ein Abgleich der Latenzen gemacht werden was dazu dient ~~Syncronität her zu stellen~~. Normalerweise werden alle Streams so lange verzögert bis sie eine ''künstliche'' ~~Latenzs~~ gleich dem Stream haben der die höchste Latenz aufweist.		* '''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. ~~Geschiet~~ 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 ~~gegeigent~~ sind um Clock driffting ~~aus zu gleichen~~.).		* '''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.).

	=== Sonstiges ===		=== Sonstiges ===