UUGRN - Benutzerbeiträge [de]

UUGRN Diskussion:10 Jahre UUGRN e.V./Vorträge

2009-05-11T19:32:38Z

Che: ssh_config dafuer

{{Hinweis|{{UUGRN:10 Jahre UUGRN e.V./Orga}}}}

== Organisatorisches ==
Wir können am Freitag eher Kurzvorträge (je 15-30min) und Samstag eher die längeren (45 und 90 min) sinnvoll einbauen.
Freitag kann etwa 20-22:30 verwendet werden, Samstag ab 15 Uhr bis 22:30.

Die Tabelle auf der [[UUGRN:10 Jahre UUGRN e.V./Vorträge|Vortragsplanung]] ist als mögliche Richtschnur gedacht.

--[[Benutzer:Rabe|rabe]] 19:20, 29. Apr. 2009 (UTC)

: Kann man sich da einfach mal Eintragen? so auf verdacht? Oder wie willste das absprechen? --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 20:37, 29. Apr. 2009 (UTC)
:: Nein, bitte noch nichts vorwegnehmen. Die Liste soll mehr einfach nur ein mögliches Zeitraster zeigen.
:: Da ich aber noch weitere Referenten gezielt ansprechen will, die möglicherweise auch von weiter weg anreisen, will ich denen natürlich das Vorrecht auf einen Zeitslot lassen.
:: Und letztlich sollen die Vorträge auch eine Art Themenbogen spannen, d.h. ähnliche Themenbereiche gruppieren.
:: --[[Benutzer:Rabe|rabe]] 21:01, 29. Apr. 2009 (UTC)

Sollen die Vortraege im kleinen Raum oder im grossen stattfinden? Ich persoenlich favorisiere den kleinen Raum, da so das Publikum eher "sichtbar" ist und die nicht-interessierten nicht von Vortraegen ''gestoert'' werden. Alternative Vorschlaege? --[[Benutzer:SHL|SHL]] 09:52, 30. Apr. 2009 (UTC)
: Ich moechte nur kurz drauf hinweisen das das gantze jetzt auf der Orga ML besprochen wird. Nicht das sich jemand wundert :) --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 03:12, 1. Mai 2009 (UTC)

__TOC__

== CAcert Vortrag ==

''wonderer'' wuerde sich dazu bereit erklaeren einen Vortrag ueber CAcert zu halten. Genauer Inhalt koennte man vorher noch rechtzeitig mit ihm ab sprechen. Eine Assurance Veranstaltung im Anschluss ist auch moeglich. Bitte um Rueckmeldung damit ich ihm bescheit sagen kann. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:33, 5. Apr. 2009 (UTC)
: find ich gut --[[Benutzer:SHL|SHL]] 13:28, 6. Apr. 2009 (UTC)
: [x] Dafür ... eine genaue(!) Zeitplanung kann ich aber noch nicht anbieten. --[[Benutzer:Rabe|rabe]] 06:18, 29. Apr. 2009 (UTC)
: [x] Dafür ... weiß auch noch nix über neuerungen --[[Benutzer:BERT|BERT]] 15:33, 11. Mai 2009 (UTC)

== Kurtz Vortrag ssh_config ==

ich koennte an einen kurzen (15 min) Vortrag ueber ssh_config(5) halten. Denke das Der koennte auch am Fr. Abends wohl laufen. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:40, 5. Apr. 2009 (UTC)
: [x] Dafür: Für Freitag abend lohnt sich das. Ich würde das Thema allerdings etwas ausweiten auf "SSH als Transport". --[[Benutzer:Rabe|rabe]] 06:19, 29. Apr. 2009 (UTC)
: [X] auch dafuer. --[[Benutzer:SHL|SHL]] 06:58, 29. Apr. 2009 (UTC)
: Nur als Stichworte, was ich da gerne hören würde (u.a., vielleicht ist ja auch für mich etwas neues, nützliches dabei): Mastermode, Cipher-wahl (SSH-HPN), Pubkeys absichlich ignorieren (bestimmte Testrechner), ForwardAgent, X-forwarding
:: Ich wollte primaer darauf eingehen was man alles setzen koennte, vor allem auf Host-Profile. Was ich an sich nicht machen wollte sind crypto fragen da ich meine das man damit 1) ne ganze Woche fuellen kann, 2) die meisten abhaengt. Mastermode kann ich aber auf jeden Fall rein packen. Bei den anderen Sachen wuerde ich mal schauen wie ich die Zeit eingeteilt bekomme.
--[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 20:41, 29. Apr. 2009 (UTC)
: [X] auch dafuer. --[[Benutzer:Che|che]] 19:32, 11. Mai 2009 (UTC)

== VortragsWorkshop RoarAudio ==

ich wuerde gerne nochmal was zum thema [[RoarAudio]] machen nach dem das das letzte mal schief gegangen ist. Grade wenn man Publikum von etwas weiter weg anlocken kann sollte die schnitt menge der hoerer klein sein. Wuerde diesmal versuchen ihn kurz zu gestalten und ehr in Richtung workshop ueber gehen zu lassen. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:43, 5. Apr. 2009 (UTC)
: [X] keine Ahnung von der Materie, aber klingt nicht uninteressant. --[[Benutzer:SHL|SHL]] 06:58, 29. Apr. 2009 (UTC)
: [X] Das würd mich interessieren, v.a. da ich mal was gelesen habe mit Ansteuermöglichkeit eines MIDI Mixers --[[Benutzer:DocBone|DocBone]] 13:38, 11. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: RoarAudio Vortrags-Workshop (hat wer nen Titel? ;)
; Inhalt: Einführung in RoarAudio, Installation, Einrichten und Benutzen
; Zielgruppe: Alle die Musik mögen. Muschel Grundkenntnisse vorteilhaft
; Dauer: ca. 35-45 Minuten Vortrag, 10-20 Minuten Vorführung, N+ Minuten Praxis

== Meta-Vortrag: Vorträge halten ==

Ich könnte einen Metavortrag über das Halten von Vorträgen halten, wenn daran Interesse besteht. Stichpunktmäßige Inhalte: Vorbereitung, Tools, Foliengestaltung, Strukturierung, Auftreten. Meiungen? --[[Benutzer:Mile|Mile]] 20:47, 7. Apr. 2009 (UTC)
: gute Idee, das Thema gefällt mir - hättest Du ein Problem damit, diesen Vortrag auf Freitag zu setzen, und den Samstag für Fachvorträge "frei zu halten"? --[[Benutzer:SHL|SHL]] 12:57, 8. Apr. 2009 (UTC)
: Nachdem ich gestern bei einem Vortrag beinahe eingeschlafen bin ( als Zuhörer ) sind mit Tipps wie ich es selber besser machen kann immer willkommen. --[[Benutzer:Che|che]] 09:45, 9. Apr. 2009 (UTC)
:: Ok, dann bereite ich diesen Vortrag vor. Unten angefügte Zusammenfassung sei dem Review Panel hiermit zur Berücksichtigung bei der Auswahl der Vorträge vorgeschlagen. ;-) --[[Benutzer:Mile|Mile]] 13:09, 9. Apr. 2009 (UTC)
: [X] Dafuer --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 10:49, 2. Mai 2009 (UTC)
: [X] Dafür --[[Benutzer:BERT|BERT]] 15:34, 11. Mai 2009 (UTC)
=== Zusammenfassung ===
; Titel: Wie halte ich einen Vortrag
; Inhalt: Der Vortrag diskutiert die Vorbereitung, Erstellung und Durchführung von technischen oder wissenschaftlichen Vorträgen. Geeignete und ungeeignete Präsentationswerkzeuge werden skizziert. Es wird auf Foliengestaltung und die Vorbereitung von Grafiken - und dabei häufig gemachte Fehler - eingegangen. Ebenso werden Tipps für eine sinnvolle Strukturierung und ein angemessenes Auftreten gegeben.
; Zielgruppe: Alle, die technische oder wissenschaftliche Präsentationen halten.
; Dauer: 30-45 Minuten.

== Vortrag über den neuen Tiling-Window-Manager i3 ==

Ich könnte einen Vortrag über meinen Windowmanager [http://i3.zekjur.net/ i3] anbieten. Ich würde sowohl etwas über den Windowmanager an sich, als auch über die Entstehungsgeschichte und was so alles dazugehört erzählen. Interesse, anyone?
: [x] --[[Benutzer:Rabe|rabe]] 06:16, 29. Apr. 2009 (UTC)
: Interesse , aber bitte nicht nur erzählen sondern auch zeigen --[[Benutzer:Che|che]] 08:29, 30. Apr. 2009 (UTC)
:: Natürlich ist eine Demo inbegriffen. Wenn’s noch Fragen gibt, kann ich dir die dann auch direkt beantworten. Feel free :-). [[Benutzer:SECuRE|sECuRE]] 02:24, 1. Mai 2009 (UTC)

; Zielgruppe: Mindestens alle UUGRNler, prinzipiell ist das Thema für jeden interessant, der sich für Computer interessiert.
; Dauer: ca. 30 Minuten

== Informationsspeicherung und deren Möglichkeiten und Probleme ==

Nein, keine VDS sondern Ablage von Daten in Computersystemen. Über RAIDs, [[ZFS]], [[AFS]] und was man so als Heim-Anwender tun kann. --[[Benutzer:SHL|SHL]] 15:57, 30. Apr. 2009 (UTC)
: Gestern bei [[NoName:Chaotische_Viertelstunde]] gehalten. --[[Benutzer:SHL|SHL]] 08:11, 1. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: Informationsspeicherung
; Inhalt: An Hand eines recht einfachen Beispiels erkläre ich die Möglichkeiten und Probleme der modernen Informationsspeicherung sowie verschiedene RAID-Levels und Lösungsansätze.
; Zielgruppe: theoretisch alle, da das Thema sehr nicht-technisch gehalten ist
; Dauer: ca. 30 Minuten.

== Kerberos Security ==

''Dieser Vortrag existiert noch nicht und wird nur gebaut, wenn genug Leute Interesse haben.''

Kerberos im Detail und im täglichen Einsatz. --[[Benutzer:SHL|SHL]] 15:57, 30. Apr. 2009 (UTC)
: Dafür. Eventuell willst du das dann auch im NoName e.V. vortragen im Rahmen der lange geplanten C¼h halten. 02:26, 1. Mai 2009 (UTC)
:: Recycling lebt vom Mitmachen! Das war ja mein Plan ;) --[[Benutzer:SHL|SHL]] 07:20, 1. Mai 2009 (UTC)
:: BTW: siehe [[NoName:Chaotische_Viertelstunde]] --[[Benutzer:SHL|SHL]] 08:11, 1. Mai 2009 (UTC)

: [X] Dafuer --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 10:49, 2. Mai 2009 (UTC)
: [X] Dafuer --15:35, 11. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: Kerberos 5
; Inhalt: Kerberos: wo fängt man an, wie funktioniert das und was macht man damit?
; Zielgruppe: technisch versierte Zuhörer, Grundlagen von Security und Netzwerk-Technik sollte vorhanden sein
; Dauer: ca. 30 Minuten.

== OpenAFS ==

''Dieser Vortrag existiert noch nicht und wird nur gebaut, wenn genug Leute Interesse haben.''

[[OpenAFS]] für redundante Datenhaltung und halb-intelligenten Storage. --[[Benutzer:SHL|SHL]] 15:57, 30. Apr. 2009 (UTC)

=== Zusammenfassung ===
; Titel: OpenAFS
; Inhalt: Was ist OpenAFS, was kann man damit erreichen, wofür kann man es nutzen und wie macht man das alles?
; Zielgruppe: technisch versierte Zuhörer, Grundlagen von Storage und Kerberos sind prima
; Dauer: ca. 30 Minuten.

== Spatial Databases (Räumliche Datenbanken) ==

''Dieser Vortrag existiert noch nicht und wird nur gebaut, wenn genug Leute Interesse haben.''

: [X] Dafuer --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 10:49, 2. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: Spatial Databases
; Inhalt: Es wird zuerst kurz um die Theorie der Räumlichen Datenbanken gehen. Was sind überhaupt räumliche Daten, welche Queries, Indexstrukturen gibt es im Umfeld RDB. Danach werde ich eine kleine Einführung in PostGIS (die räumliche Erweiterung von PostgreSQL) geben. Diese wird allerdings sehr einfach ausfallen. Ich möchte hier gerne mehr auf die Theorie als auf die Praxis eingehen.
; Zielgruppe: Jeder der an Datenbanken interessiert ist und noch nicht mit RDB gearbeitet hat.
; Dauer: ca. 30 - 45 Minuten.

== OpenSolaris - Einführung ==

''Dieser Vortrag existiert noch nicht und wird nur gebaut, wenn genug Leute Interesse haben.'' --[[Benutzer:SHL|SHL]] 13:45, 1. Mai 2009 (UTC)

: [X] Dafuer --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 10:49, 2. Mai 2009 (UTC)
: [X] Dafuer --[[Benutzer:Che|che]] 18:35, 10. Mai 2009 (UTC)
: [X] Dafuer --[[Benutzer:DocBone|DocBone]] 13:35, 11. Mai 2009 (UTC)
: [X] Dafuer --[[Benutzer:BERT|BERT]] 15:36, 11. Mai 2009 (UTC)

: Was mich persoenlich interessieren wuerde waere das Packet System. Was ich denke was klar ist, ist allgemeines zu einem POSIX konformen/kompatiblen/aehnlichen System. Da vielleicht nur drauf eingehen wie weit es kompatibel bzw. konform ist. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 16:39, 11. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: OpenSolaris-Einführung
; Inhalt: Eine Einführung in [[OpenSolaris]] mit einer kurzen Übersicht über die Funktionalität und den aktuellen Stand.
; Zielgruppe: effektiv jeder
; Dauer: ca. 30 Minuten.

UUGRN Diskussion:10 Jahre UUGRN e.V./Vorträge

2009-05-10T18:35:12Z

Che: Opensolaris : dafuer

== Organisatorisches ==
Wir können am Freitag eher Kurzvorträge (je 15-30min) und Samstag eher die längeren (45 und 90 min) sinnvoll einbauen.
Freitag kann etwa 20-22:30 verwendet werden, Samstag ab 15 Uhr bis 22:30.

Die Tabelle auf der [[UUGRN:10 Jahre UUGRN e.V./Vorträge|Vortragsplanung]] ist als mögliche Richtschnur gedacht.

--[[Benutzer:Rabe|rabe]] 19:20, 29. Apr. 2009 (UTC)

: Kann man sich da einfach mal Eintragen? so auf verdacht? Oder wie willste das absprechen? --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 20:37, 29. Apr. 2009 (UTC)
:: Nein, bitte noch nichts vorwegnehmen. Die Liste soll mehr einfach nur ein mögliches Zeitraster zeigen.
:: Da ich aber noch weitere Referenten gezielt ansprechen will, die möglicherweise auch von weiter weg anreisen, will ich denen natürlich das Vorrecht auf einen Zeitslot lassen.
:: Und letztlich sollen die Vorträge auch eine Art Themenbogen spannen, d.h. ähnliche Themenbereiche gruppieren.
:: --[[Benutzer:Rabe|rabe]] 21:01, 29. Apr. 2009 (UTC)

Sollen die Vortraege im kleinen Raum oder im grossen stattfinden? Ich persoenlich favorisiere den kleinen Raum, da so das Publikum eher "sichtbar" ist und die nicht-interessierten nicht von Vortraegen ''gestoert'' werden. Alternative Vorschlaege? --[[Benutzer:SHL|SHL]] 09:52, 30. Apr. 2009 (UTC)
: Ich moechte nur kurz drauf hinweisen das das gantze jetzt auf der Orga ML besprochen wird. Nicht das sich jemand wundert :) --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 03:12, 1. Mai 2009 (UTC)

== CAcert Vortrag ==

''wonderer'' wuerde sich dazu bereit erklaeren einen Vortrag ueber CAcert zu halten. Genauer Inhalt koennte man vorher noch rechtzeitig mit ihm ab sprechen. Eine Assurance Veranstaltung im Anschluss ist auch moeglich. Bitte um Rueckmeldung damit ich ihm bescheit sagen kann. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:33, 5. Apr. 2009 (UTC)
: find ich gut --[[Benutzer:SHL|SHL]] 13:28, 6. Apr. 2009 (UTC)
: [x] Dafür ... eine genaue(!) Zeitplanung kann ich aber noch nicht anbieten. --[[Benutzer:Rabe|rabe]] 06:18, 29. Apr. 2009 (UTC)

== Kurtz Vortrag ssh_config ==

ich koennte an einen kurzen (15 min) Vortrag ueber ssh_config(5) halten. Denke das Der koennte auch am Fr. Abends wohl laufen. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:40, 5. Apr. 2009 (UTC)
: [x] Dafür: Für Freitag abend lohnt sich das. Ich würde das Thema allerdings etwas ausweiten auf "SSH als Transport". --[[Benutzer:Rabe|rabe]] 06:19, 29. Apr. 2009 (UTC)
: [X] auch dafuer. --[[Benutzer:SHL|SHL]] 06:58, 29. Apr. 2009 (UTC)
: Nur als Stichworte, was ich da gerne hören würde (u.a., vielleicht ist ja auch für mich etwas neues, nützliches dabei): Mastermode, Cipher-wahl (SSH-HPN), Pubkeys absichlich ignorieren (bestimmte Testrechner), ForwardAgent, X-forwarding
:: Ich wollte primaer darauf eingehen was man alles setzen koennte, vor allem auf Host-Profile. Was ich an sich nicht machen wollte sind crypto fragen da ich meine das man damit 1) ne ganze Woche fuellen kann, 2) die meisten abhaengt. Mastermode kann ich aber auf jeden Fall rein packen. Bei den anderen Sachen wuerde ich mal schauen wie ich die Zeit eingeteilt bekomme. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 20:41, 29. Apr. 2009 (UTC)

== VortragsWorkshop RoarAudio ==

ich wuerde gerne nochmal was zum thema [[RoarAudio]] machen nach dem das das letzte mal schief gegangen ist. Grade wenn man Publikum von etwas weiter weg anlocken kann sollte die schnitt menge der hoerer klein sein. Wuerde diesmal versuchen ihn kurz zu gestalten und ehr in Richtung workshop ueber gehen zu lassen. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:43, 5. Apr. 2009 (UTC)
: [X] keine Ahnung von der Materie, aber klingt nicht uninteressant. --[[Benutzer:SHL|SHL]] 06:58, 29. Apr. 2009 (UTC)

=== Zusammenfassung ===
; Titel: RoarAudio Vortrags-Workshop (hat wer nen Titel? ;)
; Inhalt: Einführung in RoarAudio, Installation, Einrichten und Benutzen
; Zielgruppe: Alle die Musik mögen. Muschel Grundkenntnisse vorteilhaft
; Dauer: ca. 35-45 Minuten Vortrag, 10-20 Minuten Vorführung, N+ Minuten Praxis

== Meta-Vortrag: Vorträge halten ==

Ich könnte einen Metavortrag über das Halten von Vorträgen halten, wenn daran Interesse besteht. Stichpunktmäßige Inhalte: Vorbereitung, Tools, Foliengestaltung, Strukturierung, Auftreten. Meiungen? --[[Benutzer:Mile|Mile]] 20:47, 7. Apr. 2009 (UTC)
: gute Idee, das Thema gefällt mir - hättest Du ein Problem damit, diesen Vortrag auf Freitag zu setzen, und den Samstag für Fachvorträge "frei zu halten"? --[[Benutzer:SHL|SHL]] 12:57, 8. Apr. 2009 (UTC)
: Nachdem ich gestern bei einem Vortrag beinahe eingeschlafen bin ( als Zuhörer ) sind mit Tipps wie ich es selber besser machen kann immer willkommen. --[[Benutzer:Che|che]] 09:45, 9. Apr. 2009 (UTC)
:: Ok, dann bereite ich diesen Vortrag vor. Unten angefügte Zusammenfassung sei dem Review Panel hiermit zur Berücksichtigung bei der Auswahl der Vorträge vorgeschlagen. ;-) --[[Benutzer:Mile|Mile]] 13:09, 9. Apr. 2009 (UTC)
: [X] Dafuer --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 10:49, 2. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: Wie halte ich einen Vortrag
; Inhalt: Der Vortrag diskutiert die Vorbereitung, Erstellung und Durchführung von technischen oder wissenschaftlichen Vorträgen. Geeignete und ungeeignete Präsentationswerkzeuge werden skizziert. Es wird auf Foliengestaltung und die Vorbereitung von Grafiken - und dabei häufig gemachte Fehler - eingegangen. Ebenso werden Tipps für eine sinnvolle Strukturierung und ein angemessenes Auftreten gegeben.
; Zielgruppe: Alle, die technische oder wissenschaftliche Präsentationen halten.
; Dauer: 30-45 Minuten.

== Vortrag über den neuen Tiling-Window-Manager i3 ==

Ich könnte einen Vortrag über meinen Windowmanager [http://i3.zekjur.net/ i3] anbieten. Ich würde sowohl etwas über den Windowmanager an sich, als auch über die Entstehungsgeschichte und was so alles dazugehört erzählen. Interesse, anyone?
: [x] --[[Benutzer:Rabe|rabe]] 06:16, 29. Apr. 2009 (UTC)
: Interesse , aber bitte nicht nur erzählen sondern auch zeigen --[[Benutzer:Che|che]] 08:29, 30. Apr. 2009 (UTC)
:: Natürlich ist eine Demo inbegriffen. Wenn’s noch Fragen gibt, kann ich dir die dann auch direkt beantworten. Feel free :-). [[Benutzer:SECuRE|sECuRE]] 02:24, 1. Mai 2009 (UTC)

; Zielgruppe: Mindestens alle UUGRNler, prinzipiell ist das Thema für jeden interessant, der sich für Computer interessiert.
; Dauer: ca. 30 Minuten

== Informationsspeicherung und deren Möglichkeiten und Probleme ==

Nein, keine VDS sondern Ablage von Daten in Computersystemen. Über RAIDs, [[ZFS]], [[AFS]] und was man so als Heim-Anwender tun kann. --[[Benutzer:SHL|SHL]] 15:57, 30. Apr. 2009 (UTC)
: Gestern bei [[NoName:Chaotische_Viertelstunde]] gehalten. --[[Benutzer:SHL|SHL]] 08:11, 1. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: Informationsspeicherung
; Inhalt: An Hand eines recht einfachen Beispiels erkläre ich die Möglichkeiten und Probleme der modernen Informationsspeicherung sowie verschiedene RAID-Levels und Lösungsansätze.
; Zielgruppe: theoretisch alle, da das Thema sehr nicht-technisch gehalten ist
; Dauer: ca. 30 Minuten.

== Kerberos Security ==

''Dieser Vortrag existiert noch nicht und wird nur gebaut, wenn genug Leute Interesse haben.''

Kerberos im Detail und im täglichen Einsatz. --[[Benutzer:SHL|SHL]] 15:57, 30. Apr. 2009 (UTC)
: Dafür. Eventuell willst du das dann auch im NoName e.V. vortragen im Rahmen der lange geplanten C¼h halten. 02:26, 1. Mai 2009 (UTC)
:: Recycling lebt vom Mitmachen! Das war ja mein Plan ;) --[[Benutzer:SHL|SHL]] 07:20, 1. Mai 2009 (UTC)
:: BTW: siehe [[NoName:Chaotische_Viertelstunde]] --[[Benutzer:SHL|SHL]] 08:11, 1. Mai 2009 (UTC)

: [X] Dafuer --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 10:49, 2. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: Kerberos 5
; Inhalt: Kerberos: wo fängt man an, wie funktioniert das und was macht man damit?
; Zielgruppe: technisch versierte Zuhörer, Grundlagen von Security und Netzwerk-Technik sollte vorhanden sein
; Dauer: ca. 30 Minuten.

== OpenAFS ==

''Dieser Vortrag existiert noch nicht und wird nur gebaut, wenn genug Leute Interesse haben.''

[[OpenAFS]] für redundante Datenhaltung und halb-intelligenten Storage. --[[Benutzer:SHL|SHL]] 15:57, 30. Apr. 2009 (UTC)

=== Zusammenfassung ===
; Titel: OpenAFS
; Inhalt: Was ist OpenAFS, was kann man damit erreichen, wofür kann man es nutzen und wie macht man das alles?
; Zielgruppe: technisch versierte Zuhörer, Grundlagen von Storage und Kerberos sind prima
; Dauer: ca. 30 Minuten.

== Spatial Databases (Räumliche Datenbanken) ==

''Dieser Vortrag existiert noch nicht und wird nur gebaut, wenn genug Leute Interesse haben.''

: [X] Dafuer --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 10:49, 2. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: Spatial Databases
; Inhalt: Es wird zuerst kurz um die Theorie der Räumlichen Datenbanken gehen. Was sind überhaupt räumliche Daten, welche Queries, Indexstrukturen gibt es im Umfeld RDB. Danach werde ich eine kleine Einführung in PostGIS (die räumliche Erweiterung von PostgreSQL) geben. Diese wird allerdings sehr einfach ausfallen. Ich möchte hier gerne mehr auf die Theorie als auf die Praxis eingehen.
; Zielgruppe: Jeder der an Datenbanken interessiert ist und noch nicht mit RDB gearbeitet hat.
; Dauer: ca. 30 - 45 Minuten.

== OpenSolaris - Einführung ==

''Dieser Vortrag existiert noch nicht und wird nur gebaut, wenn genug Leute Interesse haben.'' --[[Benutzer:SHL|SHL]] 13:45, 1. Mai 2009 (UTC)

: [X] Dafuer --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 10:49, 2. Mai 2009 (UTC)
: [X] Dafuer --[[Benutzer:Che|che]] 18:35, 10. Mai 2009 (UTC)

=== Zusammenfassung ===
; Titel: OpenSolaris-Einführung
; Inhalt: Eine Einführung in [[OpenSolaris]] mit einer kurzen Übersicht über die Funktionalität und den aktuellen Stand.
; Zielgruppe: effektiv jeder
; Dauer: ca. 30 Minuten.

OpenSolaris User Group Rhein Neckar/T-Shirts

2009-05-09T21:13:24Z

Che: added:che

== Sun sponsert uns T-Shirts! ==

Jede User Group kann für ihre Mitglieder bei Sun kostenlos ziemlich schicke [[OpenSolaris]] T-Shirts bekommen. Da machen wir natürlich mit!
Die Shirts sind '''vollkommen kostenlos''', es entstehen auch keine Versandkosten oder irgendwelche versteckten Kosten, wir müssen nur wissen was wir haben wollen. Die Shirts sehen in etwa [http://mail.opensolaris.org/pipermail/advocacy-discuss/attachments/20090427/e0a0b8bd/attachment-0001.jpe so] aus.

Wer eins möchte, unabhängig davon welches Betriebssystem im [[grub]] ganz oben steht, bitte hier in die Liste eintragen. Ich kann leider nicht sagen wie groß die Shirts ausfallen, daher vielleicht lieber etwas größer oder kleiner planen und notfalls nicht mitgrillen. ;-)

{| {{prettytable}}
! das Shirt in der Größe...
! ...wer möchte ein solches?
|-
| men's small shirts || [[Benutzer:BERT|Bert]]
|-
| men's medium shirts || bisher niemand
|-
| men's large shirts || [[Benutzer:motte|motte]],[[Benutzer:schwede|schwede]],
|-
| men's extra-large shirts || bisher niemand
|-
| men's extra-large TALL shirts || Gibheer
|-
| men's extra-extra-large shirts || [[Benutzer:SHL|SHL]], [[Benutzer:Che|Che]]
|-
| women's small shirts || bisher niemand
|-
| women's medium shirts || bisher niemand
|-
| women's large shirts || bisher niemand
|-
| women's extra-large shirts || [[Benutzer:Stormwind|Stormwind]]
|-
|}

Damit die T-Shirts rechtzeitig zum [[UUGRN:10 Jahre UUGRN e.V.|10 Jahre UUGRN FIXME]] ankommen, definiere ich als '''deadline''' den 15.05.2009. --[[Benutzer:SHL|SHL]] 14:42, 9. Mai 2009 (UTC)

=== siehe auch ===

* [[OpenSolaris User Group Rhein Neckar]]
* [[OpenSolaris]]
* http://www.opensolaris.org/jive/thread.jspa?threadID=83223&tstart=0

UUGRN Diskussion:10 Jahre UUGRN e.V./Vorträge

2009-04-30T08:29:15Z

Che: Interesse i3

Diskussion:OpenSolaris

2009-04-09T10:00:43Z

Che: Info SPARC

Die Weblinks stammen hauptsächlich aus meiner del.icio.us-Library. Feel free to extend. ;-) --[[Benutzer:SHL|SHL]] 10:52, 23. Mär. 2009 (UTC)

Beim Durchstöbern der Hardwareseiten hab ich fast nur Infos zur Intel Architektur gefunden, fast nichts zur SUN eigenen SPARC. Ist meiner Meinung nach auch ein interessantes Thema, habe aber leider nicht Zeit genug um da weiter zu stöbern. Und war es nicht auch so, daß SUN bei einer der schon etwas älteren Solaris Versionen nicht ganz auf x86 verzichten wollte und bei der nächsten Version dann doch wieder aus dem Hut zauberte ''( Solaris 9 in 2003 )'' ? Kostete damals 20 Dollar für x86 und beliebige Anzahl von Installationen, für SPARC war's kostenlos.
--[[Benutzer:Che|che]] 10:00, 9. Apr. 2009 (UTC)

UUGRN Diskussion:10 Jahre UUGRN e.V./Vorträge

2009-04-09T09:45:31Z

Che: Zustimmung zum Metavortrag

== CAcert Vortrag ==

''wonderer'' wuerde sich dazu bereit erklaeren einen Vortrag ueber CAcert zu halten. Genauer Inhalt koennte man vorher noch rechtzeitig mit ihm ab sprechen. Eine Assurance Veranstaltung im Anschluss ist auch moeglich. Bitte um Rueckmeldung damit ich ihm bescheit sagen kann. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:33, 5. Apr. 2009 (UTC)
: find ich gut --[[Benutzer:SHL|SHL]] 13:28, 6. Apr. 2009 (UTC)

== Kurtz Vortrag ssh_config ==

ich koennte an einen kurzen (15 min) Vortrag ueber ssh_config(5) halten. Denke das Der koennte auch am Fr. Abends wohl laufen. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:40, 5. Apr. 2009 (UTC)

== VortragsWorkshop RoarAudio ==

ich wuerde gerne nochmal was zum thema [[RoarAudio]] machen nach dem das das letzte mal schief gegangen ist. Grade wenn man Publikum von etwas weiter weg anlocken kann sollte die schnitt menge der hoerer klein sein. Wuerde diesmal versuchen ihn kurz zu gestalten und ehr in Richtung workshop ueber gehen zu lassen. --[[Benutzer:Ph3-der-loewe|ph3-der-loewe]] 15:43, 5. Apr. 2009 (UTC)

== Meta-Vortrag: Vorträge halten ==

Ich könnte einen Metavortrag über das Halten von Vorträgen halten, wenn daran Interesse besteht. Stichpunktmäßige Inhalte: Vorbereitung, Tools, Foliengestaltung, Strukturierung, Auftreten. Meiungen? --[[Benutzer:Mile|Mile]] 20:47, 7. Apr. 2009 (UTC)
: gute Idee, das Thema gefällt mir - hättest Du ein Problem damit, diesen Vortrag auf Freitag zu setzen, und den Samstag für Fachvorträge "frei zu halten"? --[[Benutzer:SHL|SHL]] 12:57, 8. Apr. 2009 (UTC)
: Nachdem ich gestern bei einem Vortrag beinahe eingeschlafen bin ( als Zuhörer ) sind mit Tipps wie ich es selber besser machen kann immer willkommen. --[[Benutzer:Che|che]] 09:45, 9. Apr. 2009 (UTC)

UUGRN Diskussion:10 Jahre UUGRN e.V./Pressemeldung

2009-04-07T09:29:32Z

Che: Start

Steht schon fest welche Presse überhaupt Meldungen bekommen soll?

Nur "Linux-Zeitungen" = Fachpresse

oder auch die lokalen Tageszeitungen?

Da müssen wohl verschiedene Inhalte rein, bei der Tagespresse darf ein "Werbeblock" für Linux / Unix nicht fehlen.

-- [[Benutzer:Che|che]] 09:29, 7. Apr. 2009 (UTC)

RoarAudio/Vortrag/Erster Vortrag

2009-02-06T10:35:25Z

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

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm dass im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
{{Vortrags Zeit|10}}

Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio-Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

<s>

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs
</s>

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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 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.
* 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 ====
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.

==== Background Streams ====
Background Streams sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== Meta Daten ====
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 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 ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 28 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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 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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum Zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-

|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

Die wichtigsten Probleme sind:

* 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.
* 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>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>

==== Problem: Lokale Synchronität ====
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 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).
* 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen

==== Lösungsansätze ====
{{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.
* '''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.
* '''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 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.).

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
* Kein Streaming
* Keine Meta Daten
* Schlechte Qualität
* Patente

=== Querverweise ===
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
; [http://www.icecast.org/ Icecast] - Multimedia streaming server
: Software für Webradio und WebTV streaming.
; [http://www.xiph.org/ Xiph.Org Foundation]
: Organisation zur Entwicklung von freien Codecs.
; SIP
: Standard für VoIP - Internet-Telephonie.

=== Vorführung ===
{{Vortrags Zeit|30}}

* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** roarctl
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** <s>xmms</s>
*** <s>mplayer</s>
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Vortrag/Erster Vortrag

2009-02-06T09:51:31Z

Che: /* Clients und Streams */ Typo

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm dass im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
{{Vortrags Zeit|10}}

Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio-Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

<s>

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs
</s>

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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 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.
* 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 ====
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.

==== Background Streams ====
Background Streams sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== Meta Daten ====
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 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 ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 28 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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 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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum Zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-

|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

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.
* 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.
* <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>

==== Problem: Lokale Synchronität ====
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.
* 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).
* 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen

==== Lösungsansätze ====
{{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.
* '''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).
* '''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.
* '''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.
* '''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.).

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
* Kein Streaming
* Keine Meta Daten
* Schlechte Qualität
* Patente

=== Querverweise ===
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
; [http://www.icecast.org/ Icecast] - Multimedia streaming server
: Software für Webradio und WebTV streaming.
; [http://www.xiph.org/ Xiph.Org Foundation]
: Organisation zur Entwicklung von freien Codecs.
; SIP
: Standard für VoIP - Internet-Telephonie.

=== Vorführung ===
{{Vortrags Zeit|30}}

* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** roarctl
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** <s>xmms</s>
*** <s>mplayer</s>
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Vortrag/Erster Vortrag

2009-02-06T09:47:57Z

Che: /* Kompatibilitäts Bibliotheken */ Typo

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm dass im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
{{Vortrags Zeit|10}}

Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio-Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

<s>

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs
</s>

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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 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.
* 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 ====
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.

==== Background Streams ====
Background Streams sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== Meta Daten ====
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 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 ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 28 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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.

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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-

|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

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.
* 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.
* <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>

==== Problem: Lokale Synchronität ====
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.
* 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).
* 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen

==== Lösungsansätze ====
{{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.
* '''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).
* '''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.
* '''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.
* '''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.).

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
* Kein Streaming
* Keine Meta Daten
* Schlechte Qualität
* Patente

=== Querverweise ===
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
; [http://www.icecast.org/ Icecast] - Multimedia streaming server
: Software für Webradio und WebTV streaming.
; [http://www.xiph.org/ Xiph.Org Foundation]
: Organisation zur Entwicklung von freien Codecs.
; SIP
: Standard für VoIP - Internet-Telephonie.

=== Vorführung ===
{{Vortrags Zeit|30}}

* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** roarctl
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** <s>xmms</s>
*** <s>mplayer</s>
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Vortrag/Erster Vortrag

2009-02-06T09:46:38Z

Che: /* Meta Daten */ Typo

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm dass im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
{{Vortrags Zeit|10}}

Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio-Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

<s>

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs
</s>

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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 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.
* 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 ====
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.

==== Background Streams ====
Background Streams sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== Meta Daten ====
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 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 ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 28 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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.

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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-

|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

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.
* 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.
* <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>

==== Problem: Lokale Synchronität ====
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.
* 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).
* 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen

==== Lösungsansätze ====
{{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.
* '''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).
* '''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.
* '''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.
* '''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.).

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
* Kein Streaming
* Keine Meta Daten
* Schlechte Qualität
* Patente

=== Querverweise ===
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
; [http://www.icecast.org/ Icecast] - Multimedia streaming server
: Software für Webradio und WebTV streaming.
; [http://www.xiph.org/ Xiph.Org Foundation]
: Organisation zur Entwicklung von freien Codecs.
; SIP
: Standard für VoIP - Internet-Telephonie.

=== Vorführung ===
{{Vortrags Zeit|30}}

* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** roarctl
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** <s>xmms</s>
*** <s>mplayer</s>
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Vortrag/Erster Vortrag

2009-02-06T09:44:47Z

Che: /* Netzwerk-Transparenz */ Typo

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm dass im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
{{Vortrags Zeit|10}}

Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio-Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

<s>

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs
</s>

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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 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.
* 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 ====
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.

==== Background Streams ====
Background Streams sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== 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.

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.

==== Virtual IO ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 28 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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.

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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-

|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

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.
* 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.
* <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>

==== Problem: Lokale Synchronität ====
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.
* 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).
* 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen

==== Lösungsansätze ====
{{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.
* '''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).
* '''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.
* '''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.
* '''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.).

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
* Kein Streaming
* Keine Meta Daten
* Schlechte Qualität
* Patente

=== Querverweise ===
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
; [http://www.icecast.org/ Icecast] - Multimedia streaming server
: Software für Webradio und WebTV streaming.
; [http://www.xiph.org/ Xiph.Org Foundation]
: Organisation zur Entwicklung von freien Codecs.
; SIP
: Standard für VoIP - Internet-Telephonie.

=== Vorführung ===
{{Vortrags Zeit|30}}

* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** roarctl
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** <s>xmms</s>
*** <s>mplayer</s>
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Vortrag/Erster Vortrag

2009-02-06T09:43:44Z

Che: /* Codecs */ Typo

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm dass im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
{{Vortrags Zeit|10}}

Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio-Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

<s>

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs
</s>

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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 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.
* 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 ====
RoarAudio ist Netzwerk 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.

==== Background Streams ====
Background Streams sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== 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.

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.

==== Virtual IO ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 28 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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.

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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-

|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

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.
* 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.
* <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>

==== Problem: Lokale Synchronität ====
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.
* 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).
* 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen

==== Lösungsansätze ====
{{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.
* '''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).
* '''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.
* '''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.
* '''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.).

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
* Kein Streaming
* Keine Meta Daten
* Schlechte Qualität
* Patente

=== Querverweise ===
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
; [http://www.icecast.org/ Icecast] - Multimedia streaming server
: Software für Webradio und WebTV streaming.
; [http://www.xiph.org/ Xiph.Org Foundation]
: Organisation zur Entwicklung von freien Codecs.
; SIP
: Standard für VoIP - Internet-Telephonie.

=== Vorführung ===
{{Vortrags Zeit|30}}

* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** roarctl
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** <s>xmms</s>
*** <s>mplayer</s>
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Vortrag/Erster Vortrag

2009-02-06T09:42:21Z

Che: /* Im Studio Betrieb */

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm dass im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
{{Vortrags Zeit|10}}

Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio-Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

<s>

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs
</s>

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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.
* 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.

==== 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.

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 sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== 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.

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.

==== Virtual IO ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 28 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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.

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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-

|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

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.
* 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.
* <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>

==== Problem: Lokale Synchronität ====
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.
* 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).
* 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen

==== Lösungsansätze ====
{{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.
* '''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).
* '''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.
* '''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.
* '''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.).

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
* Kein Streaming
* Keine Meta Daten
* Schlechte Qualität
* Patente

=== Querverweise ===
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
; [http://www.icecast.org/ Icecast] - Multimedia streaming server
: Software für Webradio und WebTV streaming.
; [http://www.xiph.org/ Xiph.Org Foundation]
: Organisation zur Entwicklung von freien Codecs.
; SIP
: Standard für VoIP - Internet-Telephonie.

=== Vorführung ===
{{Vortrags Zeit|30}}

* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** roarctl
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** <s>xmms</s>
*** <s>mplayer</s>
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Vortrag/Erster Vortrag

2009-02-06T09:40:35Z

Che: /* Was ist ein Soundserver */

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm dass im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
{{Vortrags Zeit|10}}

Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

<s>

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs
</s>

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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.
* 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.

==== 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.

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 sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== 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.

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.

==== Virtual IO ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 28 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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.

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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-

|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

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.
* 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.
* <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>

==== Problem: Lokale Synchronität ====
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.
* 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).
* 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen

==== Lösungsansätze ====
{{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.
* '''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).
* '''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.
* '''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.
* '''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.).

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
* Kein Streaming
* Keine Meta Daten
* Schlechte Qualität
* Patente

=== Querverweise ===
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
; [http://www.icecast.org/ Icecast] - Multimedia streaming server
: Software für Webradio und WebTV streaming.
; [http://www.xiph.org/ Xiph.Org Foundation]
: Organisation zur Entwicklung von freien Codecs.
; SIP
: Standard für VoIP - Internet-Telephonie.

=== Vorführung ===
{{Vortrags Zeit|30}}

* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** roarctl
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** <s>xmms</s>
*** <s>mplayer</s>
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Vortrag/Erster Vortrag

2009-01-26T22:30:32Z

Che: Typo

<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;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Der Autor ==
[[Benutzer:Ph3-der-loewe|Philipp ''ph3-der-loewe'' Schafft]], Software Entwickler und Projekt Urheber.

== Vortrag ==
=== Was ist RoarAudio? ===
RoarAudio ist ein Soundserver.

==== Was ist ein Soundserver ====
Ein Soundserver ist eine Programm das im Hintergrund Audio Daten mischt und das Ergebnis weiter leitet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar zu der Programme wie Player ihre Daten schicken können um eine simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter Berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten zur Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

=== Projekt Ziele ===
Das Projekt verfolgt im Prinzip das Ziel, eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen, aber dennoch ein Produkt zu liefern das auch für den Heim-Anwender angemessen ist.

==== für Heim-Anwender ====
Heim-Anwender Teilen sich in zwei Gruppen auf:
Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach ''out of the box'' funktionieren.
Die andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

==== Im Studio Betrieb ====
Wie oben schon angedeutet ist RoarAudio aber im Studio Einsatz wesentlich interessanter: in einem klassischen Studio steht meist ein großes analoges Mischpult. Dies ist eine wundervolle Sache solange man primär analoge Eingänge braucht: beispielsweise von einer Band. In heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen digitalen Geräten wie CD Spielern.

Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:
* Analoges Rauschen
* Verzerrungen im Frequenzgang
* Klirren
* Quantisierungsrauchen
* Effekte durch asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber meist sehr teuer.

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

=== Exkurs: Codecs und Container ===
Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, als Datenstrom oder -block repräsentiert werden. Hierzu zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec spezifiziert sein, werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs in eine Datei codiert wurden in oder einen Stream verpackt werden. Hierzu zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

==== Verschiedene Arten von Codecs ====
* Verlustfreie
* Verlustbehaftete
* Musik Codecs
* Sprach Codecs
* Niederlatenz Codecs

=== Was hebt RoarAudio hervor? ===
Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

==== Codecs ====
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.
* 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.

==== 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.

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 sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

==== Virtual IO ====
''(gestrichen)''

==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
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.

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.

===== Welche Schnittstelle für was? =====
{| class="wikitable"
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}

=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert.

==== Clients und Streams ====

Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
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 kann und sich durch attachen wechseln läßt. 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.

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

{| class="wikitable"
! Typ
! Richtung
! Beschreibung
|-
| Play
| zu Server
| Standard Typ: eingehende Audio Daten.
|-
| Monitor
| von Server
| Hier werden die aktuellen gemischten Audio Daten vom Server abgefragt.
|-
| Filter
| bidirektional
| Dieser Stream dient zum zwischenschalten von Filtern im Mixer
|-
| Output
| vom Server
| Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
|-
| Mixing
| keine
| Interne Audio Puffer genutzt zum Mischen der Daten
|-
| Bidir
| bidirektional
| Play und Monitor in einem.
|-
| Record
| vom Server
| Im Moment nicht Unterstützt.
|-
| Meta
| Flag Abhänig
| Im Moment nicht Unterstützt.
|-
| Internal
| keine
| Im Moment nicht Unterstützt.
|-
|}

===== Stream Flags =====
Ein Stream kann desweiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind hier zusammen gefasst:

{| class="wikitable"
! Name
! Beschreibung
|-
| Primary
| Bei Ende des Streams beendet sich roard selbst.
|-
| Output
| Es wird Ein Output Driver für diesen Stream verwendet.
|-
| Source
| Bei diesem Stream handelt es sich um eine Source.
|-
| Sync
| Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
|-
| Meta
| Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von eingehenden Streams mit diesem Flag.
|-
|}

==== Driver ====
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

==== Sources ====
Eine Source ist an sich ein normaler Stream. Der Unterschied besteht darin das roard selbst den Stream beim Starten initialisiert. Neben Test Szenarien ist dies vor allem hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu spiegeln.

==== Codecfilter ====
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.



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

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 sind schnell und welche die sind gut. 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. 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 dem 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.
* 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.
* 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.

==== Problem: Lokale Synchronität ====
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.
* 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).
* Die nächste Schicht, die Sound APIs, erzeugen auf ähnliche Weise weitere Delays. Hier kommt dazu das viele mit relativ großen Puffern arbeiten. 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.
* Unsynchrones clocking

==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen
* QoS

=== Sonstiges ===
...
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32 nicht was den nahe-realtime Betrieb angeht nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandle seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.

Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.

Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.

Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).

Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

==== MP3 ====
...

=== Querverweise ===
* RAUM
* Icecast
* SIP
* Xiph

=== Vorführung ===
* Allgemeiner Betrieb
** roard
** roarvorbis/roarcatplay?
** xmms
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
** libroaresd:
*** xmms
*** mplayer
*** Amarok

== Fragen ==
* ''immer gerne''

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

RoarAudio/Installation und Einrichtung

2009-01-26T21:48:58Z

Che: Typo

'''RoarAudio''' ist ein mächtiger Multi Plattform Soundserver. Im folgenden Artikel sollen Installations- und Konfigurations-Hinweise gegeben werden. Für eine Beschreibung der Software siehe Artikel [[RoarAudio]].

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

== Installation ==
=== Installation aus den Sourcen heraus ===
Als erstes sollte man auf die [http://roaraudio.keep-cool.org Homepage] gehen und sich die aktuellen Sources herunterladen. Von dort kann man sich zum Beispiel mittels [[wget]] die Sourcen herunterladen:
$ wget http://roaraudio.keep-cool.org/dl/roaraudio-0.1beta4.tar.gz

Danach muss das Archiv mittels [[tar]] entpackt werden:
$ tar -xzvf roaraudio-0.1beta4.tar.gz

Dann wechselt man in das neue Roaraudio Verzeichnis und führt 'configure' aus:
$ ./configure

Die Übersetzung kann nun erfolgen:
$ make

Im nächsten Schritt wird das frischgebackene [[Binary]] nun im System installiert.
$ su
# make install
beziehungsweise vereinfacht mittels [[sudo]]:
$ [[sudo]] make install

Aufräumen ...
$ make clean

=== archlinux ===
...
=== OpenBSD ===
...

== Konfigurieren ==

== Benutzen ==
=== Plugins ===
==== libao ====
Nach der erfolgreichen Installation sollte das libao Plugin 'roar' zur Verfuegung stehen.
Um es als Standard Ausgabe zu benutzen muss folgendes in die Datei /etc/libao.conf geschrieben werden:
default_driver=roar

==== XMMS ====
Ist das XMMS Plugin installiert so lässt es sich unter XMMS einfach in den Plugin Einstellungen auswählen: Man drückt Strg+P und kann es dann unter ''Output Plugin'' finden. Nach dem Klicken auf ''OK'' einfach den laufenden Titel neu starten und das Plugin sollte verwendet werden.

Findet XMMS das Plugin nicht sollte überprüft werden ob roard läuft und XMMS muß gegebenfalls nach dem Starten von roard neu gestartet werden da XMMS dazu neigt, Plugins für nicht beim Start laufende Ausgaben zu verstecken.

Da das Plugin noch keinen Optionen Dialog hat muss der Server gegeben falls wie in Abschnitt [[#Server_ohne_Optionen_des_Players_ausw.C3.A4hlen|Server ohne Optionen des Players auswählen]] gezeigt eingestellt werden.



=== Basis Tools ===
RoarAudio kommt mit diversen Basis Tools welche dazu genutzt werden können Dateien abzuspielen, Webradio zu hören und die gemischten Audio Daten wieder weiter zu verwenden.

==== Musik abspielen ====

Audio Dateien (nicht nur RIFF/WAVE) lassen sich am einfachsten mittels ''roarcatplay'' abspielen:
$ roarcatplay foo.wav

Für Ogg/Vorbis Dateien gibt es ein weiteres Programm namens ''roarvorbis'' welches auch Meta Informationen anzeigt:
$ roarvorbis bar.ogg

Zum Abspielen von Musik im Hintergrund ohne einen Player im Vordergrund zu benötigen benutzt man ''roarradio'':
$ roarradio http://www.mein-webradio.org/blubb.ogg

==== Musik speichern und streamen ====
RoarAudio kann Musik nicht nur an Soundcards schicken sondern auch in Dateien oder zu einem [[icecast]] oder ähnlichen Streaming-Server.

Zum Speichern und Auslesen von Musik kann das Programm ''roarmon'' eingesetzt werden:
$ roarmon --codec vorbis output.ogg

''roarmon'' kann auch in Pipes eingesetzt werden:
$ roarmon | myenc -o bla.ext -

Zum Streamen mittels libshout kann ''roarshout'' eingesetzt werden.
$ roarshout myserver.de 8000 hackme /roar.ogg

Die Parameter sind mit denen von [[oggfwd]] kompatibel und lassen sich mittels ''--help'' nachschlagen.

==== Steuerung mittels roarctl ====
===== Server Status =====
Der Server lässt sich mittels folgendem Befehlen beenden:
$ roarctl exit # Sofort beenden
$ roarctl terminate # Beenden sobald alle Clients disconnected sind (Bei vielen Playern: Nach dem aktuellen Titel)

Auserdem kann der Server in den Standby Mode versetzt werden:
$ roarctl standby # oder..
$ roarctl off # In den Standby gehen
$ roarctl resume # oder ...
$ roarctl on # In den normal Modus gehen

Abgefragt werden kann der aktuelle Status mittels des Befehls ''standbymode'':
$ roarctl standbymode

===== Client und Stream Informationen Auslesen =====
Mit dem Befehl ''allinfo'' lassen sich nahe zu alle Informationen über Clients und Streams ausgeben:
$ roarctl allinfo

Es gibt auch spezialisiertere Befehle:
$ roarctl serveroinfo # Informationen über des Servers Mischer
$ roarctl listclients # Informationen über die Clients (Player)
$ roarctl liststreams # Informationen über die Streams

Die Befehle lassen sich mit dem Parameter ''-v'' (verbose - Erweiterte Anzeige) kombinieren.

===== Clients und Streams Manipulieren =====
Es gibt mehrere Manipulation die zur Laufzeit erfolgen können. Eine der wichtigsten ist es einen Client oder Stream zu kicken:

$ roarctl kick client 123
$ roarctl kick stream 123

Weitere Optionen können für Streams verändert werden. Eine weitere wichtige ist die Lautstärke. Sie lässt sich mittels ''volume'' verstellen:

$ roarctl volume 123 mono 50%

Dieser Befehl setzt die Lautstärke auf 50% für den Stream 123. Zu beachten ist hier das ''mono''. Es gibt an das man die Lautstärke für einen Kanal setzen will. Wenn der Stream mehr Kanäle hat, meist 2 für Stereo, so versucht ''roarctl'' sinnvoll fortzusetzen: in diesem Falle wird die Lautstärke für alle Kanäle gesetzt.

Möchte man den Pegel für den rechten und linken Kanal getrennt steuern so kann man das Schlüsselwort ''stereo'' verwenden:

$ roarctl volume 123 stereo 80% 30%

Dies setzt die Lautstärke auf 80% Links und 30% Rechts. Hat man mehr als 2 Kanäle kann man auch die Anzahl der Kanäle explizit angeben. In diesem Falle muss die Anzahl der weiteren Parametern exakt der Kanalanzahl entsprechen, zum Beispiel:

$ roarctl volume 123 4 20% 40% 60% 80%

Anstatt prozentualer Angaben können auch absolute gemacht werden. Die Skala reicht von 0 bis 65535 (inklusive):

$ roarctl volume 123 mono 8192

=== Kompatibilitäts Biblotheken ===

== Tips und Tricks ==
=== Server ohne Optionen des Players auswählen ===
Einige Player haben keine Möglichkeit einen Server einzustellen oder man möchte eine globale Einstellung treffen. Hierzu gibt es zwei Möglichkeiten:

Zum einen lässt sich global ein Server einstellen in dem man ein [[symlink]] mit dem Namen ''/etc/roarserver'' erstellt der auf den Server zeigt. Hier ein paar Beispiele:
$ ln -s /tmp/roarsock /etc/roarserver
$ ln -s remote.host.name /etc/roarserver
$ ln -s mynode:: /etc/roarserver

Die andere Möglichkeit ist es die [[Umgebungsvariable]] ROAR_SERVER zu setzen:
$ ROAR_SERVER=remote.host.name myplayer ...
$ export ROAR_SERVER=remote.host.name # bash
% setenv ROAR_SERVER remote.host.name # csh
$ myplayer ...

== Siehe auch ==
* [[RoarAudio]]

== Weblinks ==
* [http://roaraudio.keep-cool.org/ RoarAudio Homepage]

[[Kategorie:Software]]
[[Kategorie:Sound]]
{{Stub}}

RoarAudio

2009-01-26T20:32:00Z

Che: Typo

'''RoarAudio''' ist ein Sound-Server für alle [[POSIX]] konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er ist als Ersatz für den [[Enlightened Sound Daemon]] (ESD, EsounD) gedacht und bietet zusätzliche Funktionen für den Studio Betrieb.

[[Bild:RoarAudio-Logo-0.0.3.png|thumb|right|RoarAudio Logo]]

Ein Sound-Server mischt Audio Daten, die von verschiedenen Applikationen auf einer Soundcard abgespielt werden sollen. RoarAudio erweitert dieses Konzept indem er auch andere so genannte Output Streams haben kann als Soundcards: unter anderem Dumps in Dateien, Pipes oder Streaming an einen (Web-)Streaming Server. Auch ist es möglich Daten nicht nur von Applikationen zu beziehen sondern die Input Streams auch Daten aus Dateien oder über das Netzwerk beziehen zu lassen. Ebenso ist es möglich Daten über Geräte wie Soundcards und ISDN Adaptern zu beziehen.

Ein weiterer Unterschied zu herkömmlichen Sound-Servern ist, dass RoarAudio auch verschiedene komprimierte [[Codec]]s unterstützt wie [[Vorbis]], [[Speex]], [[CELT]] und andere.

'''RoarAudio''' ist dafür entworfen eine sehr niedrige Latenz aufzuweisen. Sie liegt zwischen < 1ms und 10ms. Auch besteht volle Netzwerk-Transparenz. Dass heißt das Applikationen nicht zwangsweise auf dem selben Rechner laufen müssen wie RoarAudio selbst. Die Applikationen (Clients) können sich auch via IP oder DECnet auf den Server miteinander verbinden.

== Kompatibilität ==
'''RoarAudio''' bringt diverse Plugins sowie Kompatibilitäts-Bibliotheken mit. Zu den wichtigsten zählt die libroaresd, welche es jeder Applikation, die EsounD Unterstützung besitzt, ermöglicht RoarAudio zu nutzen. Da diese Bibliotheken Binär-kompatibel sind ist es nicht nötig die Applikation erneut aus dem Source-Code heraus zu kompilieren. Weitere Plugins sind unter anderem für MPlayer, XMMS und gstreamer (GNOME) verfügbar. An einem Ersatz für aRts (KDE) wird gearbeitet.

== Lizensierung ==
Im Moment ist das Projekt unter der GPLv3 und LGPLv3. Auf Grund diverser Lizenz Probleme unterliegen alle Binär Versionen der GPLv3. Es besteht das Streben die Lizensierung auf eine weniger strikte Lizenz umzustellen.

== Projekt Geschichte ==
Das Projekt hatte am Son den 31 August 2008 sein initialen Release.

== Siehe Auch ==
<splist />

== Weblinks ==
{{Homepage|roaraudio.keep-cool.org/}}

[[Kategorie:Software]]
[[Kategorie:Sound]]
{{Stub}}

Benutzer:Che

2008-10-24T11:30:10Z

Che: Erweiterung Liste Webseiten

Name : Hans Hermann Schafft<br>
Jahrgang : 1954<br>
Mitglied bei der [[UUGRN]]: ca. seit Sommer 2004<br>
<br>
aktive Verbindung mit IT-Technik seit über 25 Jahren<br>
warum [[Linux]] / [[Unix]]? <br>
da kann man sein System noch so bauen wie man es sich vorstellt und nicht wie andere Leute einen vorschreiben wollen.
Ich mag keine Programme die mich bevormunden indem sie andauernd das "korrigieren" was ich eingebe.
Muß mich damit aber auch beruflich arrangieren. <br>
<br>
----
<br>
Webseiten :<br>
im eigenem Jail :<br>
[http://che.uugrn.org che.uugrn.org]<br>
[http://www.wasserstrasse.org www.wasserstrasse.org] ''( Bilder aus meinem Heimatdorf )''<br>
[http://www.kaulfroggy.de www.kaulfroggy.de] ''( wird von meiner Tochter gefüllt )''<br>
auf externem Server :<br>
[http://www.hhschafft.de www.hhschafft.de]<br>

Kontakt :<br>
che''(knödel)''uugrn.org<br>
che''(knödel)''hhschafft.de<br>

''knödel'' oder ''klammeraffe'' :<br>
nenne ich das Ding wie in den alten Zeiten mit dem [[Betriebssystem]]en [[RSX11M]] und [[VMS]]<br>
mit @<dateiname> wird die Kommandoprozedur = Script gestartet

Diskussion:RaumZeitLabor/Netzwerk

2007-09-11T17:49:09Z

Che: Angebot Printserver

Ich habe vor, einen Switch für die FIXME-Treffen als "Leihgabe" zur Verfügung zu stellen. (soll vor Ort verbleiben, außer wenn wir ihm mal selber brauchen würden).
Typ Nortel Baystack 450-24T, 24 Ports a 10/100MB, als IP-Adresse will ich 192.168.0.250 nehmen, SNMP soll Read-Only freigegeben werden , nur 1 VLAN. Weitere Konfigurations-Infos wenn fertig.

Bei Änderungswünschen bitte hier eintragen.

Weiterhin liefere ich noch einen kleinen Stapel Patchkabel und eine Steckdosenleiste mit 9 Anschlüssen. Damit muß dann nicht jeder auch noch einen Haufen Anschlußmaterial mitbringen.

Übergabetermin ist noch offen, sollte aber spätestens beim nächsten FIXME Treffen sein.
--[[Benutzer:Che|che]] 18:36, 8. Sep. 2007 (CEST)

: Hallo Che,
: finde das eine '''Gute Idee™''', so ein Switch kann man immer mal brauchen und letztlich ist es egal, in welchem Keller oder Speicher man ihn aufbewahrt. Wir sollten das Thema '''Toolbox''' nochmal besprechen, irgendwas, was man entweder tragen oder rollen kann. So eine Kiste könnte darüber hinaus im Laufe der Zeit angereichert werden mit folgenden Dingen:
:* 50er Pack Holzwäscheklammern für Peg-DHCP ;)
:* Standardwerkzeug (Schraubendreher, etc)
:* den Switch und Patchkabel
:* Spezialkabel (Crosslink, Doppelverbinder, ...)

:* rückstandsfrei ablösbares Klebeband
:* ggf. kleiner (alter, gebrauchter) LASER-Drucker, Printserver
:* Wechselstrom-Equipment (Schuko-Verlängerungen, Verteiler)
:* Papier und Stifte (Drucker und für Schilder, Beschriftungen)
: --[[Benutzer:Rabe|rabe]] 19:07, 11. Sep. 2007 (CEST)

:: hallo
:: einen Printserver mit Parallelport ( plus 1 Seriellport ), kein USB, kann ich auch noch dazupacken
:: Typ Lantronix EPS1 , spricht IP, Appletalk, LAT und noch was
:: so einen setze ich zuhause auch ein
:: und falls jemand mal einen LWL-Anschluß braucht könnte ich wahrscheinlich auch noch aushelfen,
:: das aber leider nur mit 10MB Ethernet
:: --[[Benutzer:Che|che]] 19:49, 11. Sep. 2007 (CEST)

Diskussion:RaumZeitLabor/Netzwerk

2007-09-08T16:36:26Z

Che: Beistellung Netzwerksequipment

Ich habe vor, einen Switch für die FIXME-Treffen als "Leihgabe" zur Verfügung zu stellen. ( soll vor Ort verbleiben außer wenn wir ihm mal selber brauchen würden )

Typ Nortel Baystack 450-24T , 24 Ports a 10/100MB, als IP-Adresse will ich 192.168.0.250 nehmen, SNMP soll Read-Only freigegeben werden , nur 1 VLAN. Weitere Konfigurations-Infos wenn fertig.

Bei Änderungswünschen bitte hier eintragen

Weiterhin liefere ich noch einen kleinen Stapel Patchkabel und eine Steckdosenleiste mit 9 Anschlüssen. Damit muß dann nicht jeder auch noch einen Haufen Anschlußmaterial mitbringen.

Übergabetermin ist noch offen, sollte aber spätestens beim nächsten FIXME Treffen sein.
--[[Benutzer:Che|che]] 18:36, 8. Sep. 2007 (CEST)

UUGRN:Jails/che

2007-08-26T19:08:44Z

Che:

Verantwortlich für dieses Jail ist: Hans-Hermann Schafft

Das Jail wurde am 22.8.2007 in Betrieb genommen.

== Accounts ==

== Dienste ==

== Planung ==
vorläufig 2 neue Webseiten

alles andere ist noch offen

{{Navigationsleiste Systeme}}
[[Kategorie:Benutzerjail]]

Diskussion:Ausbildungs-Zertifizierungen

2007-07-23T08:38:47Z

Che: Die Seite wurde neu angelegt: Wenn auf der Seite ein Verweis auf diese Diskussionsseite steht sollte die auch mit entsprechendem Inhalt gefüllt sein, z.B. was genauere Angaben was dort reklamiert w...

Wenn auf der Seite ein Verweis auf diese Diskussionsseite steht sollte die auch mit entsprechendem Inhalt gefüllt sein,
z.B. was genauere Angaben was dort reklamiert wird
--[[Benutzer:Che|che]] 10:38, 23. Jul. 2007 (CEST)

Fluxbox

2007-04-22T19:13:09Z

Che: /* Themes */ aktualisiert

== allgemein ==

Fluxbox ist ein [[Windowmanager|Fenstermanager]] , der aus dem älteren [[blackbox]] Version 0.61 abgeleitet wurde.
Gleiches gilt dabei auch für eine Teil des Zubehörs.
Die Konfigurationsmöglichkeiten sind aber vielfältiger

== Eigenschaften ==

Mehrere Desktopoberflächen sind möglich, default ist 4.
Vorhanden ist eine konfigurierbare Toolbar, bei der beispielsweise eingefügt werden können :
Wechsel zum nächsten / vorhergehendem Desktop;
Wechsel zum nächsten / vorhergehendem Fenster;
die Uhrzeit des Rechners;
Die geöffneten Fenster werden in der Toolbar angezeigt und können von dort aus auch direkt angewählt werden.

Beim Verschieben von Fenstern wird die Positionsangabe der Ecke Links oben auf dem Bildschirm angezeigt.
Gleiches gilt beim Verändern der Fenstergröße mit Angabe von Höhe und Breite.

Besonderheit ist, daß mehrere Fenster zusammengefügt werden können, die sich einen gemeinsamen Rahmen teilen.
Die obere Kante des Rahmens ist dann in Tabs unterteilt zur Anwahl der Fenster.

== Zubehör ==

=== Hintergrund ===

....

=== Datei-, Icon- und andere -Manager ===

fbdesk
Desktop Manager

=== Dockables ===

sind möglich, die Positionierung wird in der Init-Datei festgelegt

=== sonstiges ===

fluxter
zeigt in einem kleinen Fenster ein Abbild der Desktopoberflächen mit Lage der offenen Fenster. Diese lassen sich damit einfach verschieben, auch zwischen den Desktops

== Konfiguration ==

Konfigurierbar sind beispielsweise :
* Anzahl und Namen der Desktop-Oberflächen
* Toolbar

=== Konfigurationshilfen ===

....

=== Files ===

Wer von [[Blackbox]] zu Fluxbox wechselt kann seine bisherigen Konfigurationsfiles fast 1:1 übernehmen.

* Userspezifische Konfigurationen
** $HOME/.fluxbox/init : Initialisierungsdatei
** $HOME/.fluxbox/fbdesk.icons : Konfiguration für fbdesk
** die folgenden Dateien liegen defaultmaßig auch im Verzeichnis .fluxbox, können aber in der init-Datei individuell definiert werden
** menu : die Menue-Liste zur Auswahl der Programme
** keys : die Tastaturbelegung
** slitlist : Reihenfolge der Dockables

=== Menus ===

....

=== Themes ===

die Angabe der Themes-Datei steht in $HOME/.fluxbox/init

in Themes werden über Parameterlisten konfiguriert
* Farben , z.B. für Fensterrahmen, Menu , Taskleiste
* Farbverläufe, wenn nicht einfarbig
* Fonts
* Rahmengrößen
in alten Versionen ( bis 0.9.14 , März 2006 ) gibt es das Kommando rootCommand zum Füllen des root-Fensters.
Ab Version 0.9.15 gibt es dafür die Parameter background , background.color , background.colorTo und background.pixmap .
Ältere Themes-Pakete müssen dazu angepaßt werden.

=== sonstiges ===

....

=== Beispiele ===

....

== Weblinks ==

* [http://fluxbox.sourceforge.net/ Homepage]
* [http://themes.freshmeat.net/browse/962/ Sammlung Themes]

[[Kategorie:X11]]

TWM

2007-04-15T18:34:03Z

Che: Anmerkung rein, nicht sichtbar

== allgemein ==

Toms Window Manager oder auch Tab Window Manager, kurz TWM genannt, ist einer der ältesten [[Windowmanager|Fenstermanager]].

Er ist sehr klein gehalten, Toolbars und ähnliches gibt es nicht.
TWM ist Bestandteil der X-Server-Distribution, er wird automatisch mit dem X-Server installiert.

== Eigenschaften ==

Gewöhnungsbedürftig ist die Veränderung der Fenstergröße und das fehlende Exit- oder Quit-Knöpfchen
im Fensterrahmen zum Schließen des Fensters.

Als interessanter Gag kann für das Minimieren und wieder Öffnen der Fenster ein Zoom-Effekt eingestellt werden.

== Zubehör ==

=== Hintergrund ===

Der Hintergrund kann einfarbig über die Konfigurationsdatei eingestellt werden. Für andere Einstellungen müssen
die Tools von anderen [[Windowmanager|Fenstermanager]] genommen werden.

== Konfiguration ==

=== Konfigurationshilfen ===

keine, muß alles per Editor erstellt werden

=== Files ===

Der TWM benutzt nur eine einzige Konfigurationsdatei, die in verschiedenen Verzeichnissen liegen kann.
Genommen wird die zuerst gefundene in der unten aufgelisteten Reihenfolge :

im Home-Verzeichnis des Users : .twmrc

in /usr/X11R6/lib/X11/twm/ : .twmrc

als Muster wird mitgeliefert /usr/X11R6/lib/X11/twm/system.twmrc

Die letztere Datei wird auch genommen, wenn alle anderen fehlen.

=== Menus ===

Das Menu wird durch die linke Maustaste aufgeklappt, Submenus können eingefügt werden.
Icons, Textfarben, Hintergrundfarben können konfiguriert werden für :
* das komplette Menu
* jedes Submenu individuell
* jeden Menupunkt einzeln
* mit fließenden Hintergrundfarben

=== Tastaturbelegungen ===

Tastaturbelegungen sind frei einstellbar.

=== Themes ===

gibt es nicht für den TWM

=== Beispiele ===

Farbgestaltung der Menuleiste

[[Bild:Twm-farbmuster-01.gif|right|Beispiel 1 für Farbgestaltung des Menus]]
[[Bild:Twm-farbmuster-02.gif|right|Beispiel 2 für Farbgestaltung des Menus]]

menu "Demo"
:{
:"-- viele Farben --" ("blue":"pink") f.title
:"Zeile1" ("red":"blue") f.nop
:"Zeile2" f.nop
:"Zeile3" f.menu "Demo-Sub1"
:"Zeile4" f.nop
:"Zeile5" ("white":"black") f.nop
:"Zeile6" f.nop
:"Zeile7" f.menu "Demo-Sub2"
:"Zeile8" f.nop
:"Zeile9" ("yellow":"green") f.nop
:"Zeile10" ("black":"white") f.nop
:}

menu "Demo-Sub1"
:{
:"-- Beispiel 2 --" ("white":"red") f.title
:"Zeile11" ("blue":"rgb:e/e/7") f.nop
:"Zeile12" ("blue":"rgb:e/e/7") f.nop
:"Zeile13" ("blue":"rgb:e/e/7") f.nop
:"Zeile14" ("blue":"rgb:e/e/7") f.nop
:}

menu "Demo-Sub2"
:{
:"-- Beispiel 3 --" ("white":"rgb:6/6/9") f.title
:"Zeile21" f.nop
:"Zeile22" f.nop
:"Zeile23" f.nop
:"Zeile24" f.nop
:"Zeile25" ("white":"rgb:9/9/F") f.nop
:}

== Weblinks ==

[[Kategorie:X11]]

Openbox

2007-04-15T18:33:11Z

Che: Anmerkung rein, nicht sichtbar

== allgemein ==

Openbox ist ein [[Windowmanager|Fenstermanager]] ähnlich dem [[TWM]].

== Eigenschaften und Bedienung ==

Toolbars und ähnliches hat er nicht, aber er kann mehrere Desktops bedienen.
Das Menu wird defaultmäßig durch die rechte Maustaste aufgeklappt, die Anwahl des Menupunktes erfolgt durch die linke Maustaste
Minimierte Fenster verschwinden ganz, sie werden über das Menu wieder hervor geholt.
Ebenso erfolgt auch die Anwahl eines anderen Desktops über das Menu.

== Zubehör ==

Zur Hilfe bei der Konfiguration gibt es das Programm [[obconf]], mit dem man eine Teil der rc.xml bearbeiten kann.

=== Hintergrund ===

Hintergrundbilder und anderes werden durch zusätzliche Tools eingeblendet.

=== Datei-, Icon- und andere -Manager ===

=== Dockables ===

keine

=== sonstiges ===

== Konfiguration ==

Konfiguriert wird er über 2 Konfigurationsdateien im XML-Format:
;Die Dateien liegen normalerweise im Home-Pfad des Users im Unterverzeichnis .config/openbox

=== Konfigurationshilfen ===

Zur Hilfe bei der Konfiguration gibt es das Programm [[obconf]], mit dem man eine Teil der rc.xml bearbeiten kann.

=== Files ===

;rc.xml:hier steht die komplette Konfiguration des eigentlichen Fenstermanagers:
:* Tastaturbelegung
:* Mousekonfiguration
:* Anzahl, Name usw. der Desktops
:* Liste der Menu-Files

;menu.xml:hier steht die Konfiguration des Hauptmenus ''( "root-menü )'' und der Submenus drin.<br>
:Speziell angepaßte Shell-Scripte können hier eingefügt werden, die dynamische Submenus mit beliebigen Funktioen erzeugen
:''( Beispiel Prozeßliste mit Kill-Aufruf )''

Weitere Menu-Files können eingefügt werden.

=== Menus ===

=== Themes ===

=== sonstiges ===

== Weblinks ==
[http://icculus.org/openbox/ Homepage Openbox]<br>
[http://tr.openmonkey.com/pages/obconf/ Homepage Obconf]

[[Kategorie:X11]]

Matchbox

2007-04-15T18:32:04Z

Che: Anmerkung rein, nicht sichtbar

== allgemein ==

Matchbox ist ein [[Windowmanager|Fenstermanager]] für Geräte mit kleinem Display, z.B. einem IPod oder embedded
Systeme. Seine Eigenschaften sind dementsprechend angepaßt.

== Eigenschaften ==

Die Fenster sind immer maximiert und liegen sozusagen immer hintereinander. Dadurch ist immer nur eines zu sehen.
Die Anwahl der Fenster erfolgt unterschiedlich je nachdem welche zusätzlichen Komponenten installiert und
gestartet sind. In der Minimalversion wird links oben mit einem Button eine Auswahlliste geöffnet.

== Zubehör ==

=== Hintergrund ===

--

=== Datei-, Icon- und andere -Manager ===

matchbox-panel

damit wird unten eine Taskleiste eingeblendet. In der Default-Einstellung enthält sie rechts die Uhrzeit und links
einen Startknopf für ein Menu, das damit geöffnet wird. Weitere Funktionen wie Link auf xterm sind einstellbar.
Es können gleichzeitig mehrere Taskleisten gestartet werden. Die Unterscheidung erfolgt durch Angabe von --id <nummer> beim Start.''( Default-Nr ist 1)''. Weitere Startparameter sind möglich, z.B. die Farbe mit -c <farbe> oder die Ausrichtung am Bildschirmrand mit --orientation <south / east / north / west> ''Default ist unten = south''

matchbox-desktop

ein eigenes Fenster, in denen verschiedene Verzeichnisse dargestellt werden. Darin befinden sich die Links zum
Starten der Programme. In einem dieser Verzeichnisse sind die Links auf die zur Zeit offenen Fenster.

=== Dockables ===

--

=== sonstiges ===

--

== Konfiguration ==

so einfach matchbox auch scheint, die Konfiguration ist komplex.

Infos folgen hier noch

=== Konfigurationshilfen ===

--

=== Files ===

*Für Links in der Taskleiste :
** $HOME/.matchbox/mbdock.session
** für Taskleisten mit anderer ID als 1 wird ein.<id-nummer> an den Filenamen angehängt

=== Menus ===

--

=== Themes ===

sind möglich

=== sonstiges ===

--

=== Beispiele ===

--

== Weblinks ==

* [http://projects.o-hand.com/matchbox/ Homepage Matchbox]

{{Stub}}
[[Kategorie:X11]]

ICEWM

2007-04-15T18:30:55Z

Che: Anmerkung rein, nicht sichtbar

== allgemein ==

IceWM ist ein handlicher [[Windowmanager|Fenstermanager]] mit einer Oberfläche ähnlich den großen Desktops .
Er läuft unter ca. 10 verschiedenen Systemen bzw. Hardwarearchitekturen.

== Eigenschaften ==

Vorhanden sind eine Toolbar unten und eine Menu-Leiste, die durch eine Art "Start"-Knopf eingeblendet wird. Dadurch entsteht eine Oberfläche ähnlich Windows 98.

Mehrere Desktopoberflächen sind möglich, default ist 4.

== Zubehör ==

=== Hintergrund ===

Das Hintergrundbild wird in der Datei preference festgelegt, die Anzeige erfolgt durch das Programm icewmbg

=== Datei-, Icon- und andere -Manager ===

keine

=== Dockables ===

diese Funktion ist nicht vorhanden

=== sonstiges ===

== Konfiguration ==

Konfigurierbar sind beispielsweise :
* Anzahl und Namen der Desktop-Oberflächen
* Toolbar ( Taskleiste ) 1- oder 2-zeilig
* in der Toolbar :
** Links auf die diversen Programme
** Anzeigen für Netzwerksbetrieb, CPU-Last, Uhr
* die Fensterrahmen ( Breite, Muster, Farben )
* Icons, Auswahl und Default-Verzeichnis
* Hintergrundfarbe
* Menuleiste

=== Konfigurationshilfen ===

mit einem Tool namens icewmconf können die meisten Konfigurationspunkte über ein Menu bedient werden

=== Files ===

Die Konfiguration erfolgt über verschiedene Textdateien, mindestens vorhanden sind :
{|
| width=80 | preferences
| alle allgemeinen Konfigurationsparameter als Kommentarzeile
|-
|programs
| oberer Teil der Menü-Leiste, enthält direkte Aufrufe von Programmen
|-
| menu
| unterer Teil der Menü-Leiste, enthält Aufrufe von Submenüs
|-
| toolbar
| für Aufrufe von Programmen aus Toolleiste unten
|}

Die Verzeichnisse, in denen die Default-Konfiguration liegen kann, sind unterschiedlich je nach System oder Tool :
* Default-Konfigurationen :
** /usr/local/share/icewm
** /usr/X11R6/lib/X11/icewm/
** /usr/local/lib/Xll/icewm/
* systemweit geänderte Konfigurationen
** /etc/X11/icewm/
** /etc/icewm
* Userspezifische Konfigurationen
** $HOME/.icewm

=== Menus ===

Submenus sind möglich und werden über eigene Dateien konfiguriert. Der Dateiname ist beliebig und muß nicht gleich dem Text im Hauptmenü sein.

=== Themes ===

Verschiedene Themes und Pakete mit Icons für IceWM gibt es genügend freie im Internet,
sie können aber problemlos durch eigenen ersetzt oder modifiziert werden.

Der Fensterrahmen wird durch mehrere kleine Bilddateien zusammengesetzt, die Rahmenbreite ist aber noch konfigurierbar. ''( Vorsicht, Breite nicht auf 0 setzen, sind dann nicht mehr verstellbar )''

Dateiformat für Icons und Fensterrahmen ist [[XPM]]

=== sonstiges ===

=== Beispiele ===

== Weblinks ==

* [http://www.icewm.org/ Homepage IceWM]
* [http://www.sdboyd56.com/icewmconf/ Homepage icewmconf]
* [http://www.themes.org/ Sammlung Themes]

[[Kategorie:X11]]

Fluxbox

2007-04-15T18:29:32Z

Che: Anmerkung rein, nicht sichtbar

== allgemein ==

Fluxbox ist ein [[Windowmanager|Fenstermanager]] , der aus dem älteren [[blackbox]] Version 0.61 abgeleitet wurde.
Gleiches gilt dabei auch für eine Teil des Zubehörs.
Die Konfigurationsmöglichkeiten sind aber vielfältiger

== Eigenschaften ==

Mehrere Desktopoberflächen sind möglich, default ist 4.
Vorhanden ist eine konfigurierbare Toolbar, bei der beispielsweise eingefügt werden können :
Wechsel zum nächsten / vorhergehendem Desktop;
Wechsel zum nächsten / vorhergehendem Fenster;
die Uhrzeit des Rechners;
Die geöffneten Fenster werden in der Toolbar angezeigt und können von dort aus auch direkt angewählt werden.

Beim Verschieben von Fenstern wird die Positionsangabe der Ecke Links oben auf dem Bildschirm angezeigt.
Gleiches gilt beim Verändern der Fenstergröße mit Angabe von Höhe und Breite.

Besonderheit ist, daß mehrere Fenster zusammengefügt werden können, die sich einen gemeinsamen Rahmen teilen.
Die obere Kante des Rahmens ist dann in Tabs unterteilt zur Anwahl der Fenster.

== Zubehör ==

=== Hintergrund ===

....

=== Datei-, Icon- und andere -Manager ===

fbdesk
Desktop Manager

=== Dockables ===

sind möglich, die Positionierung wird in der Init-Datei festgelegt

=== sonstiges ===

fluxter
zeigt in einem kleinen Fenster ein Abbild der Desktopoberflächen mit Lage der offenen Fenster. Diese lassen sich damit einfach verschieben, auch zwischen den Desktops

== Konfiguration ==

Konfigurierbar sind beispielsweise :
* Anzahl und Namen der Desktop-Oberflächen
* Toolbar

=== Konfigurationshilfen ===

....

=== Files ===

Wer von [[Blackbox]] zu Fluxbox wechselt kann seine bisherigen Konfigurationsfiles fast 1:1 übernehmen.

* Userspezifische Konfigurationen
** $HOME/.fluxbox/init : Initialisierungsdatei
** $HOME/.fluxbox/fbdesk.icons : Konfiguration für fbdesk
** die folgenden Dateien liegen defaultmaßig auch im Verzeichnis .fluxbox, können aber in der init-Datei individuell definiert werden
** menu : die Menue-Liste zur Auswahl der Programme
** keys : die Tastaturbelegung
** slitlist : Reihenfolge der Dockables

=== Menus ===

....

=== Themes ===

die Angabe der Themes-Datei steht in $HOME/.fluxbox/init

in Themes werden über Parameterlisten konfiguriert
* Farben , z.B. für Fensterrahmen, Menu , Taskleiste
* Farbverläufe, wenn nicht einfarbig
* Fonts
* Rahmengrößen
hier kann auch ein Kommando zum Füllen des root-Fensters, z.B. mit Farbe oder Bild, aufgerufen werden

=== sonstiges ===

....

=== Beispiele ===

....

== Weblinks ==

* [http://fluxbox.sourceforge.net/ Homepage]
* [http://themes.freshmeat.net/browse/962/ Sammlung Themes]

[[Kategorie:X11]]

Fluxbox

2007-04-13T13:18:29Z

Che: neu erstellt

== allgemein ==

Fluxbox ist ein [[Windowmanager|Fenstermanager]] , der aus dem älteren [[blackbox]] Version 0.61 abgeleitet wurde.
Gleiches gilt dabei auch für eine Teil des Zubehörs.
Die Konfigurationsmöglichkeiten sind aber vielfältiger

== Eigenschaften ==

Mehrere Desktopoberflächen sind möglich, default ist 4.
Vorhanden ist eine konfigurierbare Toolbar, bei der beispielsweise eingefügt werden können :
Wechsel zum nächsten / vorhergehendem Desktop;
Wechsel zum nächsten / vorhergehendem Fenster;
die Uhrzeit des Rechners;
Die geöffneten Fenster werden in der Toolbar angezeigt und können von dort aus auch direkt angewählt werden.

Beim Verschieben von Fenstern wird die Positionsangabe der Ecke Links oben auf dem Bildschirm angezeigt.
Gleiches gilt beim Verändern der Fenstergröße mit Angabe von Höhe und Breite.

Besonderheit ist, daß mehrere Fenster zusammengefügt werden können, die sich einen gemeinsamen Rahmen teilen.
Die obere Kante des Rahmens ist dann in Tabs unterteilt zur Anwahl der Fenster.

== Zubehör ==

=== Hintergrund ===

....

=== Datei-, Icon- und andere -Manager ===

fbdesk
Desktop Manager

=== Dockables ===

sind möglich, die Positionierung wird in der Init-Datei festgelegt

=== sonstiges ===

fluxter
zeigt in einem kleinen Fenster ein Abbild der Desktopoberflächen mit Lage der offenen Fenster. Diese lassen sich damit einfach verschieben, auch zwischen den Desktops

== Konfiguration ==

Konfigurierbar sind beispielsweise :
* Anzahl und Namen der Desktop-Oberflächen
* Toolbar

=== Konfigurationshilfen ===

....

=== Files ===

Wer von [[Blackbox]] zu Fluxbox wechselt kann seine bisherigen Konfigurationsfiles fast 1:1 übernehmen.

* Userspezifische Konfigurationen
** $HOME/.fluxbox/init : Initialisierungsdatei
** $HOME/.fluxbox/fbdesk.icons : Konfiguration für fbdesk
** die folgenden Dateien liegen defaultmaßig auch im Verzeichnis .fluxbox, können aber in der init-Datei individuell definiert werden
** menu : die Menue-Liste zur Auswahl der Programme
** keys : die Tastaturbelegung
** slitlist : Reihenfolge der Dockables

=== Menus ===

....

=== Themes ===

die Angabe der Themes-Datei steht in $HOME/.fluxbox/init

in Themes werden über Parameterlisten konfiguriert
* Farben , z.B. für Fensterrahmen, Menu , Taskleiste
* Farbverläufe, wenn nicht einfarbig
* Fonts
* Rahmengrößen
hier kann auch ein Kommando zum Füllen des root-Fensters, z.B. mit Farbe oder Bild, aufgerufen werden

=== sonstiges ===

....

=== Beispiele ===

....

== Weblinks ==

* [http://fluxbox.sourceforge.net/ Homepage]
* [http://themes.freshmeat.net/browse/962/ Sammlung Themes]

[[Kategorie:X11]]

Xbattbar

2007-04-10T22:29:45Z

Che: interne Links rein

einfache Balkenanzeige für den Ladezustand des Akkus im Notebook.

Der Balken ist am wahlweise rechten, linken, oberen oder unteren Bildrand plazierbar, die Balkenbreite ist in Pixel einstellbar.

Der Balken ist 2-farbig, für den Ladezustand und den Rest bis 100%, unterschiedlich für Betrieb mit und ohne Netzteil. Die Farben sind frei wählbar.

Wenn die Maus über dem Balken steht erscheint in der Mitte des Bildschirms ein Textfeld mit prozentualer Anzeige des Ladezustandes.

Die Informationen werden aus dem APM Modul des Systems ausgelesen.

Die Homepage dieses Tools ist schon etwas älter (Feb. 2000), dort aufgelistete Betriebssysteme sind [[FreeBSD]] 3.x,4.x, [[NetBSD]] 1.3, [[Linux]] 2.2.

funktionierende Binärpakete für NetBSD gibt es aber für Version 2.0 und für die i386 Hardware für 2.1 und 3.0.

== Weblinks ==
[http://iplab.aist-nara.ac.jp/member/suguru/xbattbar.html Homepage von xbattbar]

[ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/sysutils/xbattbar/README.html NetBSD Package Collection]

[[Kategorie:Tool]]
[[Kategorie:X11]]

Ringkernspeicher

2007-04-10T22:23:17Z

Che: Link zu Datenspeicher rein, kleine Erweiterung

Ringkernspeicher waren jahrelang die [[Datenspeicher|Arbeitsspeicher]] der Computer.

Sie bestanden aus einer Matrix von winzigen Eisenringen.
Jeder Ring war ein einzelnes Bit.
Zum Lesen und Schreiben der Daten wurden 3 Drähte durch jeden Ring geführt :
Diese Drähte wurden händisch von Frauen durch die Kerne gefädelt !
Hier konnten die Speicher noch bitweise repariert werden ( und wurden sie auch ! )

Anfang der 1980er Jahre wurden sie durch Einsatz der [[Datenspeicher|Halbleiterspeicher]] ersetzt.

Vorteil der Ringkernspeicher war, das sie auch nach Stromausfall ihre Daten behalten konnten.

[[Kategorie:Hardware ]]

Editor

2007-04-10T22:04:02Z

Che: Kategorie Tool

Ein Editor ist mit das wichtigste Programm auf einem Computer.
Er dient dazu, Textdateien beliebiger Form zu bearbeiten.
Ein Editor muß alle folgenden Funktionen können :
* Erstellen einer neuen Datei
* Öffnen einer vorhandenen Datei
* Anzeigen des Dateiinhaltes
* Ändern von beliebigen Daten in einer Datei
* Löschen von beliebigen Daten in einer Datei
* Schreiben der ( geänderten ) Daten aus einer in diese oder eine andere Datei
und das ganze interaktiv, das heißt durch einen Dialog
* mit Positionierung des Cursors auf die betreffende Stelle
oder
* durch Eingabe in eine spezielle Kommandozeile
und sie müssen alle diese Aufgaben können, nicht nur einen Teil davon.
Andererseits darf ein Editor eine Datei nicht löschen, da sind andere Tools des [[Betriebssystem]]s für zuständig.
Allerdings darf er eine leere Datei erstellen bzw. eine Datei leer machen und so speichern.

Editoren gibt es viele auf der Welt, für jedes [[Betriebssystem]] ein paar spezielle,
in der Linux/Unix-Umgebung z.B.

* [[vi]] der älteste und wohl auch bekannteste mit verschiedenen Abkömmlingen,
* [[emacs]] auch alt, mit graphischer Oberfläche
* wer ist der kleinste : [[pico]] , [[nano]]
* [[Leafpad]]
* [[NEdit]]
* aus der [[KDE]]-Welt : [[KWrite]] und [[KEdit]]
für die besonderen Fälle
* [[HTML-Editoren]] wie [[Bluefish]] und [[Quanta]]
* [[Hex-Editoren]] zum Editieren von Binär-Dateien

[[Kategorie:Software]]
[[Kategorie:Tool]]

Editor

2007-04-10T21:51:27Z

Che: kategorisiert

Datei:Twm-farbmuster-02.gif

2007-04-10T18:03:13Z

Che: Kategorien rein

Beispiel (2), wie man die Menuleiste im twm farblich gestalten kann

[[Kategorie:Screenshot]]
[[Kategorie:X11]]

Datei:Twm-farbmuster-01.gif

2007-04-10T18:02:41Z

Che: Kategorie rein

Beispiel (1), wie man die Menuleiste im twm farblich gestalten kann

[[Kategorie:Screenshot]]
[[Kategorie:X11]]

FreeBSD/Ports/portupgrade

2007-04-09T20:13:18Z

Che: cvsup -> CVSup

Dieser Artikel wird die Toolsammlung aus [[portupgrade]] vorstellen und zeigen, welche Alltagsprobleme der FreeBSD Ports damit gelöst werden können.

== Das Problem ==
Gerade wer seine Ports nicht auf einem festen RELEASE-Stand einfrieren will, sondern immer die aktuellste Software und die letzten Releases von Drittsoftware haben möchte, wird schnell bemerken, dass die FreeBSD Ports aus dem [[HEAD-Branch]] (siehe: [[CVS]] und [[CVSup]]) ein moving target sind, das nur selten bis nie einen konsistenten Zustand aus Abhängigkeiten bestimmter Versionen hat.

Insbesondere wenn zu einem späteren Zeitpunkt Software nachinstalliert werden soll, wenn sich in der Zwischenzeit zahlreichen Abhängigkeiten leicht verändert haben, z.B. neuere Versionsnummern verfügbar sind als die der bereits installierten Ports, kommt man um die portupgrade-Tools kaum herum.

Portupgrade "erkennt" diese Probleme und führt on-the-fly Korrekturen bei den registrierten Abhängigkeiten durch, erkennt bei Installation oder Update einzelner Ports vorab die korrekte Reihenfolge der Abhängigkeiten und sorgt dafür, dass die Ports Infrastruktur nicht in zyklische Abhängigkeiten oder konkurrierende Versionsabhängigkeiten laufen.

== Die Tools ==
=== [[portupgrade]] ===

=== [[portinstall]] ===

=== [[portsdb]] ===

=== [[pkgdb]] ===

=== [[portsclean]] ===

...

{{Stub}}
[[Kategorie:FreeBSD]]

FreeBSD/Ports/update

2007-04-09T20:12:14Z

Che: cvsup -> CVSup, csv -> CVS

Dieser Artikel soll kurz die Möglichkeiten und Beispielkonfigurationen für das Updates der Ports-Infrastruktur (nicht die Software selbst) zusammentragen und einen Überblick verschaffen, was man als best-practise einsetzen kann.

== Mechanismen ==
=== [[CVSup]] ===

=== [[portsnap]] ===

=== [[CVS]] ===

=== [[ctm]] ===

{{Stub}}
[[Kategorie:FreeBSD]]

Real Virtuality/Netzwerk

2007-04-09T20:07:26Z

Che: cvsup -> CVSup

Wie zu jeder Veranstaltung von UUGRN steht jedem Teilnehmer WLAN oder mindestens ein [[100BaseT]] [[Ports (Netzwerk)|Netzwerkport]] mit DHCP zur Verfügung.
Statische IPs auf Anfrage vor Ort.

== Koordinaten ==
{| class="wikitable"
| v4-Netz || 192.168.0.0/24
|-
| DHCP || 192.168.0.30 - 192.168.0.254
|-
| v4-Gateway || 192.168.0.1
|-
| Proxy (freiwillig) || 192.168.0.9:3128
|-
| DNS || 192.168.0.9 und 192.168.0.1
|-
| WLAN SSID || UUGRNPARTY
|-
| WEP-Schlüssel || Bitte Aushang beachten
|}

== Internet ==
Wir werden wieder einen Internetzugang haben. Dieser soll '''nicht''' dazu dienen massiv Downloads zu betreiben.

=== IPv6 ===
Es wird wieder eine IPv6-Connection geben. IPv6-fähige Geräte einfach auf "Auto-Konfiguration" stellen.

== Server ==
Unter '''192.168.0.9''' bzw. '''ftp.party.uugrn.org''' werden wir einen FTP-Server bereitstellen.
Dieser wird mit relevanten Mirrors versorgt sein. Bitte Wünsche an [[Benutzer:Rabe|Raphael]].

Der gleiche Server hält auch das '''CVS-Repository von FreeBSD'''' ('''[[CVSup]]''') vor,
ebenso wie relevante '''distfiles''' und ggf. '''packages'''

[[Kategorie:Veranstaltung]]

Spring Party 06/Netzwerk

2007-04-09T20:06:25Z

Che: cvsup -> CVSup

Wie jedes Jahr steht jedem Teilnemer mindestens ein [[100BaseT]] [[Ports (Netzwerk)|Netzwerkport]] zur Verfügung.
Andere Netzwerktypen wie [[10Base2]] (BNC) können unter Umständen ebenfalls bereitgestellt werden.
Dazu bitte [[Benutzer:Ph3-der-loewe|Ph3-der-loewe]] kontaktieren.
Auch wird es wieder [[WLAN]] geben. Die Zuweisung der [[IP]]s geschiet mittels [[DHCP]].
Ist dies aus irgendeinem Grunde nicht moeglich (z.B. koennen einige kleine Geraete wie [[Printserver]] oder aehnliches kein [[DHCP]])
so bitte vor Ort an [[Benutzer:Rabe|Rabe]] wenden.

= Koordinaten =
{| class="wikitable"
| v4-Netz || 192.168.0.0/24
|-
| DHCP || 192.168.0.30 - 192.168.0.254
|-
| v4-Gateway || 192.168.0.1
|-
| Proxy (freiwillig) || 192.168.0.9:3128
|-
| DNS || 192.168.0.9 und 192.168.0.1
|-
| WLAN SSID || UUGRNPARTY
|-
| WEP-Schlüssel || Bitte Aushang beachten
|}

= Internet =
Wir werden wieder einen Internetzugang haben. Dieser soll '''nicht''' dazu dienen massiv Downloads zu betreiben.

== IPv6 ==
Es wird wieder eine IPv6-Connection geben. IPv6-fähige Geräte einfach auf "Auto-Konfiguration" stellen.

= Server =
Unter '''192.168.0.9'' bzw. '''ftp.party.uugrn.org''' werden wir einen FTP-Server bereitstellen.
Dieser wird mit relevanten Mirrors versorgt sein. Bitte Wünsche an [[Benutzer:Rabe|Raphael]].

Der gleiche Server hält auch das '''CVS-Repository von FreeBSD'''' ('''[[CVSup]]''') vor,
ebenso wie relevante '''distfiles''' und ggf. '''packages'''

Musik kann via '''esound''' an den Server geschickt werden (Jeder nur ein Kreuz!)

= !100BaseT =
* [[10Base2|10Base2 (BNC)]] ist nun als verfuegbar geklaert.
* 1000Base* koennen wir dieses mal leider nicht anbieten.

[[Kategorie:Veranstaltung]]

Tipps und Tricks

2007-04-09T19:09:16Z

Che: Link auf vermeidbare Fehler rein

Unterhalb dieser Seite können Artikel verlinkt werden, die Problemlösungen beschreiben.

Eine Strukturierung dieser Sammlung wird es im Laufe der Zeit geben.

== [[Betriebssystem]] ==
=== [[:Kategorie:BSD|BSD]] ===
* [[BSD:Firefox mit Flash-Plugin]]
* [[FreeBSD Console]]

=== [[:Kategorie:Linux|Linux]] ===

== [[:Kategorie:Software|Software]] ==

=== Drucker ===
* [[LPD mit gimp-print]]

=== [[:Kategorie:Tool|Tools]] ===
[[Gzip]], [[tar]], [[bzip2]], [[wget]], [[xbattbar]], ...

=== [[:Kategorie:IRC|IRC]] ===
* [[Irssi installieren und einrichten]]

=== [[:Kategorie:Anwendungsbeispiel|Anwendungsbeispiele]] ===
* [[tar]]
* [[Smarty_Template_Engine]]

=== Multimedia ===
* [[Audio aus Video extrahieren mit MPlayer]]

== [[:Kategorie:Hardware|Hardware]] ==

== Vermeidbare Fehler ==
* [[Vermeidbare_Fehler|Hier]] ein paar Tipps, was man nicht machen sollte als Administrator

== [[:Kategorie:Verein|UUGRN]] ==
* [[UUGRN:Backup|Backup]] und [[UUGRN:Backup#Data_Recovery|Datenrücksicherung]] (Admins)
* [[UUGRN:Webspace|Webspace]] benutzen (Mitglieder/User)
* [[UUGRN:Shell|Shell]] benutzen (Mitglieder/User)

== [[:Kategorie:Wiki|Wiki]] ==
* [http://meta.wikimedia.org/wiki/Hilfe:Handbuch MediaWiki Handbuch]

[[Kategorie:Verein]]
[[Kategorie:Portal]]

Matchbox

2007-04-09T18:39:07Z

Che: /* Files */ mbdock.session eingefügt

== allgemein ==

Matchbox ist ein [[Windowmanager|Fenstermanager]] für Geräte mit kleinem Display, z.B. einem IPod oder embedded
Systeme. Seine Eigenschaften sind dementsprechend angepaßt.

== Eigenschaften ==

Die Fenster sind immer maximiert und liegen sozusagen immer hintereinander. Dadurch ist immer nur eines zu sehen.
Die Anwahl der Fenster erfolgt unterschiedlich je nachdem welche zusätzlichen Komponenten installiert und
gestartet sind. In der Minimalversion wird links oben mit einem Button eine Auswahlliste geöffnet.

== Zubehör ==

=== Hintergrund ===

--

=== Datei-, Icon- und andere -Manager ===

matchbox-panel

damit wird unten eine Taskleiste eingeblendet. In der Default-Einstellung enthält sie rechts die Uhrzeit und links
einen Startknopf für ein Menu, das damit geöffnet wird. Weitere Funktionen wie Link auf xterm sind einstellbar.
Es können gleichzeitig mehrere Taskleisten gestartet werden. Die Unterscheidung erfolgt durch Angabe von --id <nummer> beim Start.''( Default-Nr ist 1)''. Weitere Startparameter sind möglich, z.B. die Farbe mit -c <farbe> oder die Ausrichtung am Bildschirmrand mit --orientation <south / east / north / west> ''Default ist unten = south''

matchbox-desktop

ein eigenes Fenster, in denen verschiedene Verzeichnisse dargestellt werden. Darin befinden sich die Links zum
Starten der Programme. In einem dieser Verzeichnisse sind die Links auf die zur Zeit offenen Fenster.

=== Dockables ===

--

=== sonstiges ===

--

== Konfiguration ==

so einfach matchbox auch scheint, die Konfiguration ist komplex.

Infos folgen hier noch

=== Konfigurationshilfen ===

--

=== Files ===

*Für Links in der Taskleiste :
** $HOME/.matchbox/mbdock.session
** für Taskleisten mit anderer ID als 1 wird ein.<id-nummer> an den Filenamen angehängt

=== Menus ===

--

=== Themes ===

sind möglich

=== sonstiges ===

--

=== Beispiele ===

--

== Weblinks ==

* [http://projects.o-hand.com/matchbox/ Homepage Matchbox]

{{Stub}}
[[Kategorie:X11]]

Matchbox

2007-04-09T18:31:35Z

Che: /* Datei-, Icon- und andere -Manager */ Startparameter

== allgemein ==

Matchbox ist ein [[Windowmanager|Fenstermanager]] für Geräte mit kleinem Display, z.B. einem IPod oder embedded
Systeme. Seine Eigenschaften sind dementsprechend angepaßt.

== Eigenschaften ==

Die Fenster sind immer maximiert und liegen sozusagen immer hintereinander. Dadurch ist immer nur eines zu sehen.
Die Anwahl der Fenster erfolgt unterschiedlich je nachdem welche zusätzlichen Komponenten installiert und
gestartet sind. In der Minimalversion wird links oben mit einem Button eine Auswahlliste geöffnet.

== Zubehör ==

=== Hintergrund ===

--

=== Datei-, Icon- und andere -Manager ===

matchbox-panel

damit wird unten eine Taskleiste eingeblendet. In der Default-Einstellung enthält sie rechts die Uhrzeit und links
einen Startknopf für ein Menu, das damit geöffnet wird. Weitere Funktionen wie Link auf xterm sind einstellbar.
Es können gleichzeitig mehrere Taskleisten gestartet werden. Die Unterscheidung erfolgt durch Angabe von --id <nummer> beim Start.''( Default-Nr ist 1)''. Weitere Startparameter sind möglich, z.B. die Farbe mit -c <farbe> oder die Ausrichtung am Bildschirmrand mit --orientation <south / east / north / west> ''Default ist unten = south''

matchbox-desktop

ein eigenes Fenster, in denen verschiedene Verzeichnisse dargestellt werden. Darin befinden sich die Links zum
Starten der Programme. In einem dieser Verzeichnisse sind die Links auf die zur Zeit offenen Fenster.

=== Dockables ===

--

=== sonstiges ===

--

== Konfiguration ==

so einfach matchbox auch scheint, die Konfiguration ist komplex.

Infos folgen hier noch

=== Konfigurationshilfen ===

--

=== Files ===

--

=== Menus ===

--

=== Themes ===

sind möglich

=== sonstiges ===

--

=== Beispiele ===

--

== Weblinks ==

* [http://projects.o-hand.com/matchbox/ Homepage Matchbox]

{{Stub}}
[[Kategorie:X11]]

Matchbox

2007-04-03T23:42:58Z

Che: Korrektur Stub

== allgemein ==

Matchbox ist ein [[Windowmanager|Fenstermanager]] für Geräte mit kleinem Display, z.B. einem IPod oder embedded
Systeme. Seine Eigenschaften sind dementsprechend angepaßt.

== Eigenschaften ==

Die Fenster sind immer maximiert und liegen sozusagen immer hintereinander. Dadurch ist immer nur eines zu sehen.
Die Anwahl der Fenster erfolgt unterschiedlich je nachdem welche zusätzlichen Komponenten installiert und
gestartet sind. In der Minimalversion wird links oben mit einem Button eine Auswahlliste geöffnet.

== Zubehör ==

=== Hintergrund ===

--

=== Datei-, Icon- und andere -Manager ===

matchbox-panel

damit wird unten eine Taskleiste eingeblendet. In der Default-Einstellung enthält sie rechts die Uhrzeit und links
einen Startknopf für ein Menu, das damit geöffnet wird. Weitere Funktionen wie Link auf xterm sind einstellbar.

matchbox-desktop

ein eigenes Fenster, in denen verschiedene Verzeichnisse dargestellt werden. Darin befinden sich die Links zum
Starten der Programme. In einem dieser Verzeichnisse sind die Links auf die zur Zeit offenen Fenster.

=== Dockables ===

--

=== sonstiges ===

--

== Konfiguration ==

so einfach matchbox auch scheint, die Konfiguration ist komplex.

Infos folgen hier noch

=== Konfigurationshilfen ===

--

=== Files ===

--

=== Menus ===

--

=== Themes ===

sind möglich

=== sonstiges ===

--

=== Beispiele ===

--

== Weblinks ==

* [http://projects.o-hand.com/matchbox/ Homepage Matchbox]

{{Stub}}
[[Kategorie:X11]]

Matchbox

2007-04-03T23:38:34Z

Che: neu erstellt

== allgemein ==

Matchbox ist ein [[Windowmanager|Fenstermanager]] für Geräte mit kleinem Display, z.B. einem IPod oder embedded
Systeme. Seine Eigenschaften sind dementsprechend angepaßt.

== Eigenschaften ==

Die Fenster sind immer maximiert und liegen sozusagen immer hintereinander. Dadurch ist immer nur eines zu sehen.
Die Anwahl der Fenster erfolgt unterschiedlich je nachdem welche zusätzlichen Komponenten installiert und
gestartet sind. In der Minimalversion wird links oben mit einem Button eine Auswahlliste geöffnet.

== Zubehör ==

=== Hintergrund ===

--

=== Datei-, Icon- und andere -Manager ===

matchbox-panel

damit wird unten eine Taskleiste eingeblendet. In der Default-Einstellung enthält sie rechts die Uhrzeit und links
einen Startknopf für ein Menu, das damit geöffnet wird. Weitere Funktionen wie Link auf xterm sind einstellbar.

matchbox-desktop

ein eigenes Fenster, in denen verschiedene Verzeichnisse dargestellt werden. Darin befinden sich die Links zum
Starten der Programme. In einem dieser Verzeichnisse sind die Links auf die zur Zeit offenen Fenster.

=== Dockables ===

--

=== sonstiges ===

--

== Konfiguration ==

so einfach matchbox auch scheint, die Konfiguration ist komplex.

Infos folgen hier noch

=== Konfigurationshilfen ===

--

=== Files ===

--

=== Menus ===

--

=== Themes ===

sind möglich

=== sonstiges ===

--

=== Beispiele ===

--

== Weblinks ==

* [http://projects.o-hand.com/matchbox/ Homepage Matchbox]

[[Kategorie:X11]]
[[Kategorie:Stub]]

Windowmanager

2007-04-03T23:35:13Z

Che: Matchbox rein

Windowmanager , Fenstermanager, WMs sind ein graphisches Hilfsmittel bei der Bedienung des [[X11]]-Servers bzw. dem Aufruf der Programme, die den X11-Server benötigen. Sie arbeiten über ein eigenes Fenster, in das die Aufrufe der anderen Programme integriert sind.
Taskleisten, Hintergrundbilder usw. sind nicht Bestandteil der WMs, sie werden über zusätzliche Programme eingefügt.

Die Auswahl eines WMs ist groß, es gibt über 100 davon. Manche sind von anderen abgeleitet worden.

Für die Optik eines WMs gibt es "[[Themes]]", das sind Pakete mit Bildern, Konfigurationsdaten und anderen möglichen Komponenten, zusammengestellt und veröffentlicht von Benutzern der einzelnen WMs. Es kann sich aber auch jeder frei sein eigenes Theme zusammenstellen oder andere nach eigenen Wünschen verändern.

bekannte Windowmanager sind z.B. :
* [[Afterstep]]
* [[Blackbox]]
* [[Enlightenment]]
* [[Fluxbox]]
* [[FVWM2]]
* [[ICEWM]]
* [[Matchbox]] , für Systeme mit kleinem Display
* [[Openbox]]
* [[Sawfish]]
* [[TWM]] , sehr schlank, ist im Paket des X-Servers mit drin
* [[Window Maker]]

== Siehe auch ==
* [[Desktop-Umgebung]]

== Weblinks ==

* [http://www.themes.org Themes] zum Aussuchen

[[Kategorie:X11|!Windowmanager]]

Windowmanager

2007-03-29T21:22:47Z

Che: Link auf Fluxbox rein

Windowmanager , Fenstermanager, WMs sind ein graphisches Hilfsmittel bei der Bedienung des [[X11]]-Servers bzw. dem Aufruf der Programme, die den X11-Server benötigen. Sie arbeiten über ein eigenes Fenster, in das die Aufrufe der anderen Programme integriert sind.
Taskleisten, Hintergrundbilder usw. sind nicht Bestandteil der WMs, sie werden über zusätzliche Programme eingefügt.

Die Auswahl eines WMs ist groß, es gibt über 100 davon. Manche sind von anderen abgeleitet worden.

Für die Optik eines WMs gibt es "[[Themes]]", das sind Pakete mit Bildern, Konfigurationsdaten und anderen möglichen Komponenten, zusammengestellt und veröffentlicht von Benutzern der einzelnen WMs. Es kann sich aber auch jeder frei sein eigenes Theme zusammenstellen oder andere nach eigenen Wünschen verändern.

bekannte Windowmanager sind z.B. :
* [[Afterstep]]
* [[Blackbox]]
* [[Enlightenment]]
* [[Fluxbox]]
* [[FVWM2]]
* [[ICEWM]]
* [[Openbox]]
* [[Sawfish]]
* [[TWM]], sehr schlank, ist im Paket des X-Servers mit drin
* [[Window Maker]]

== Siehe auch ==
* [[Desktop-Umgebung]]

== Weblinks ==

* [http://www.themes.org Themes] zum Aussuchen

[[Kategorie:X11|!Windowmanager]]

Openbox

2007-03-29T21:21:21Z

Che: neue Struktur rein, Texte daran angepaßt

== allgemein ==

Openbox ist ein [[Windowmanager|Fenstermanager]] ähnlich dem [[TWM]].

== Eigenschaften und Bedienung ==

Toolbars und ähnliches hat er nicht, aber er kann mehrere Desktops bedienen.
Das Menu wird defaultmäßig durch die rechte Maustaste aufgeklappt, die Anwahl des Menupunktes erfolgt durch die linke Maustaste
Minimierte Fenster verschwinden ganz, sie werden über das Menu wieder hervor geholt.
Ebenso erfolgt auch die Anwahl eines anderen Desktops über das Menu.

== Zubehör ==

Zur Hilfe bei der Konfiguration gibt es das Programm [[obconf]], mit dem man eine Teil der rc.xml bearbeiten kann.

=== Hintergrund ===

Hintergrundbilder und anderes werden durch zusätzliche Tools eingeblendet.

=== Datei-, Icon- und andere -Manager ===

=== Dockables ===

keine

=== sonstiges ===

== Konfiguration ==

Konfiguriert wird er über 2 Konfigurationsdateien im XML-Format:
;Die Dateien liegen normalerweise im Home-Pfad des Users im Unterverzeichnis .config/openbox

=== Konfigurationshilfen ===

Zur Hilfe bei der Konfiguration gibt es das Programm [[obconf]], mit dem man eine Teil der rc.xml bearbeiten kann.

=== Files ===

;rc.xml:hier steht die komplette Konfiguration des eigentlichen Fenstermanagers:
:* Tastaturbelegung
:* Mousekonfiguration
:* Anzahl, Name usw. der Desktops
:* Liste der Menu-Files

;menu.xml:hier steht die Konfiguration des Hauptmenus ''( "root-menü )'' und der Submenus drin.<br>
:Speziell angepaßte Shell-Scripte können hier eingefügt werden, die dynamische Submenus mit beliebigen Funktioen erzeugen
:''( Beispiel Prozeßliste mit Kill-Aufruf )''

Weitere Menu-Files können eingefügt werden.

=== Menus ===

=== Themes ===

=== sonstiges ===

== Weblinks ==
[http://icculus.org/openbox/ Homepage Openbox]<br>
[http://tr.openmonkey.com/pages/obconf/ Homepage Obconf]

[[Kategorie:X11]]

ICEWM

2007-03-29T21:14:42Z

Che: neu strukturiert, Texte dazu angepaßt

== allgemein ==

IceWM ist ein handlicher [[Windowmanager|Fenstermanager]] mit einer Oberfläche ähnlich den großen Desktops .
Er läuft unter ca. 10 verschiedenen Systemen bzw. Hardwarearchitekturen.

== Eigenschaften ==

Vorhanden sind eine Toolbar unten und eine Menu-Leiste, die durch eine Art "Start"-Knopf eingeblendet wird. Dadurch entsteht eine Oberfläche ähnlich Windows 98.

Mehrere Desktopoberflächen sind möglich, default ist 4.

== Zubehör ==

=== Hintergrund ===

Das Hintergrundbild wird in der Datei preference festgelegt, die Anzeige erfolgt durch das Programm icewmbg

=== Datei-, Icon- und andere -Manager ===

keine

=== Dockables ===

diese Funktion ist nicht vorhanden

=== sonstiges ===

== Konfiguration ==

Konfigurierbar sind beispielsweise :
* Anzahl und Namen der Desktop-Oberflächen
* Toolbar ( Taskleiste ) 1- oder 2-zeilig
* in der Toolbar :
** Links auf die diversen Programme
** Anzeigen für Netzwerksbetrieb, CPU-Last, Uhr
* die Fensterrahmen ( Breite, Muster, Farben )
* Icons, Auswahl und Default-Verzeichnis
* Hintergrundfarbe
* Menuleiste

=== Konfigurationshilfen ===

mit einem Tool namens icewmconf können die meisten Konfigurationspunkte über ein Menu bedient werden

=== Files ===

Die Konfiguration erfolgt über verschiedene Textdateien, mindestens vorhanden sind :
{|
| width=80 | preferences
| alle allgemeinen Konfigurationsparameter als Kommentarzeile
|-
|programs
| oberer Teil der Menü-Leiste, enthält direkte Aufrufe von Programmen
|-
| menu
| unterer Teil der Menü-Leiste, enthält Aufrufe von Submenüs
|-
| toolbar
| für Aufrufe von Programmen aus Toolleiste unten
|}

Die Verzeichnisse, in denen die Default-Konfiguration liegen kann, sind unterschiedlich je nach System oder Tool :
* Default-Konfigurationen :
** /usr/local/share/icewm
** /usr/X11R6/lib/X11/icewm/
** /usr/local/lib/Xll/icewm/
* systemweit geänderte Konfigurationen
** /etc/X11/icewm/
** /etc/icewm
* Userspezifische Konfigurationen
** $HOME/.icewm

=== Menus ===

Submenus sind möglich und werden über eigene Dateien konfiguriert. Der Dateiname ist beliebig und muß nicht gleich dem Text im Hauptmenü sein.

=== Themes ===

Verschiedene Themes und Pakete mit Icons für IceWM gibt es genügend freie im Internet,
sie können aber problemlos durch eigenen ersetzt oder modifiziert werden.

Der Fensterrahmen wird durch mehrere kleine Bilddateien zusammengesetzt, die Rahmenbreite ist aber noch konfigurierbar. ''( Vorsicht, Breite nicht auf 0 setzen, sind dann nicht mehr verstellbar )''

Dateiformat für Icons und Fensterrahmen ist [[XPM]]

=== sonstiges ===

=== Beispiele ===

== Weblinks ==

* [http://www.icewm.org/ Homepage IceWM]
* [http://www.sdboyd56.com/icewmconf/ Homepage icewmconf]
* [http://www.themes.org/ Sammlung Themes]

[[Kategorie:X11]]

TWM

2007-03-29T20:11:21Z

Che: Struktur rein, etwas mehr Infotext, Beispielkonfiguration und Bilder für Farbgestaltung rein

== allgemein ==

Toms Window Manager oder auch Tab Window Manager, kurz TWM genannt, ist einer der ältesten [[Windowmanager|Fenstermanager]].

Er ist sehr klein gehalten, Toolbars und ähnliches gibt es nicht.
TWM ist Bestandteil der X-Server-Distribution, er wird automatisch mit dem X-Server installiert.

== Eigenschaften ==

Gewöhnungsbedürftig ist die Veränderung der Fenstergröße und das fehlende Exit- oder Quit-Knöpfchen
im Fensterrahmen zum Schließen des Fensters.

Als interessanter Gag kann für das Minimieren und wieder Öffnen der Fenster ein Zoom-Effekt eingestellt werden.

== Zubehör ==

=== Hintergrund ===

Der Hintergrund kann einfarbig über die Konfigurationsdatei eingestellt werden. Für andere Einstellungen müssen
die Tools von anderen [[Windowmanager|Fenstermanager]] genommen werden.

== Konfiguration ==

=== Konfigurationshilfen ===

keine, muß alles per Editor erstellt werden

=== Files ===

Der TWM benutzt nur eine einzige Konfigurationsdatei, die in verschiedenen Verzeichnissen liegen kann.
Genommen wird die zuerst gefundene in der unten aufgelisteten Reihenfolge :

im Home-Verzeichnis des Users : .twmrc

in /usr/X11R6/lib/X11/twm/ : .twmrc

als Muster wird mitgeliefert /usr/X11R6/lib/X11/twm/system.twmrc

Die letztere Datei wird auch genommen, wenn alle anderen fehlen.

=== Menus ===

Das Menu wird durch die linke Maustaste aufgeklappt, Submenus können eingefügt werden.
Icons, Textfarben, Hintergrundfarben können konfiguriert werden für :
* das komplette Menu
* jedes Submenu individuell
* jeden Menupunkt einzeln
* mit fließenden Hintergrundfarben

=== Tastaturbelegungen ===

Tastaturbelegungen sind frei einstellbar.

=== Themes ===

gibt es nicht für den TWM

=== Beispiele ===

Farbgestaltung der Menuleiste

[[Bild:Twm-farbmuster-01.gif|right|Beispiel 1 für Farbgestaltung des Menus]]
[[Bild:Twm-farbmuster-02.gif|right|Beispiel 2 für Farbgestaltung des Menus]]

menu "Demo"
:{
:"-- viele Farben --" ("blue":"pink") f.title
:"Zeile1" ("red":"blue") f.nop
:"Zeile2" f.nop
:"Zeile3" f.menu "Demo-Sub1"
:"Zeile4" f.nop
:"Zeile5" ("white":"black") f.nop
:"Zeile6" f.nop
:"Zeile7" f.menu "Demo-Sub2"
:"Zeile8" f.nop
:"Zeile9" ("yellow":"green") f.nop
:"Zeile10" ("black":"white") f.nop
:}

menu "Demo-Sub1"
:{
:"-- Beispiel 2 --" ("white":"red") f.title
:"Zeile11" ("blue":"rgb:e/e/7") f.nop
:"Zeile12" ("blue":"rgb:e/e/7") f.nop
:"Zeile13" ("blue":"rgb:e/e/7") f.nop
:"Zeile14" ("blue":"rgb:e/e/7") f.nop
:}

menu "Demo-Sub2"
:{
:"-- Beispiel 3 --" ("white":"rgb:6/6/9") f.title
:"Zeile21" f.nop
:"Zeile22" f.nop
:"Zeile23" f.nop
:"Zeile24" f.nop
:"Zeile25" ("white":"rgb:9/9/F") f.nop
:}

== Weblinks ==

[[Kategorie:X11]]