Hallo Forum, derzeit suche ich eine Möglichkeit, ein paar Audiosignale zu mischen und diese dann über das Audio-System meiner Wohnung auszugeben. Die einfachste Variante, nämlich das ganze mit ein paar OpAmps analog zu lösen, habe ich schon in Lochraster verewigt, klingt sogar ganz brauchbar (Dolby 9.2 brauche ich eh nicht, mir reicht Stereo völlig). Nun dachte ich mir, da ich noch ein paar Raspberrys herum liegen habe, wieso das ganze nicht digitalisieren! In Sachen DSP bin ich aber totaler Neuling, ich kenne mich nur entweder ganz analog oder ganz digital aus, drum bin ich hier^^ Also, meine Idee ist, über einen audio-tauglichen ADC die Signale irgendwie^^ in den Raspberry zu bekommen und die einzelnen Streams dann in gewissen Kombinationen per WLAN zur Verfügung zu stellen, die dann in den einzelnen Räumen an die dortigen Boxen geleitet werden. Also beispielsweise die Musik vom Mediaserver in alle Räume, den Ton vom TV/Videostream nur in die Räume, wo auch tv-taugliche Displays sind, diese und jene Kombi vielleicht noch je nach dem. Ist jetzt auch nicht so wichtig fürs erste. Was mir aufgefallen ist, ist, dass audio-taugliche ADCs offenbar sündteuer sind. Da ich das ganze ja selbst stricken will und auch nicht der SMD-Layouter vor dem Herrn bin, ist mir nun der PCM4222 von TI ins Auge gefallen, den es auch noch für gerade noch erschwingliches Geld auf einem Eval-Board mitsamt benötigter Hardware drumrum gibt. Der hat aber nur 2 Kanäle (also Stereo), dafür kann er mit satten 192kHz und 24 Bits abtasten. Meine Idee ist nun, da einen Analog-Switch der Sorte ADG609 von Analog Devices vorzuschalten. Damit könnte ich 4 Stereo-Kanäle mit satten 48kHz samplen und die Daten dann vom 4222 (auf welchem Weg auch immer) an den Raspberry leiten, der die Samples dann wieder den passenden Streams zuordnet. Mir gefällt halt die Idee, im Raspberry auf die Audio-Signale reagieren zu können, als würde wer an den Reglern sitzen. Da zum Beispiel mein Telefon daheim eh schon mit meinem Heimserver verbunden ist (Raspberry mit GSM-Modul) und mich auch anrufen kann, wenn ich nicht da bin, fände ich es super, wenn der Mixer das Musik-Signal von selber runterregelt, wenn ein Anruf eingeht, und mir mein Heimserver dann in vernünftiger Lautstärke mitteilen kann, wer mich da gerade anruft. Theoretisch. Denke ich mir so. Jetzt kommt ihr. Ist das totaler Blödsinn, oder ist es machbar, aber es gibt viel einfachere Lösungen? Oder kommt statt einigermaßen (!) erträglicher Qualität nur böses Knurren aus den Boxen? Nochmals, ich brauche keine Monster-Qualität wie im Kino. Trotzdem soll Musik natürlich nicht klingen wie ein kaputter Stream aus Kapputkistan. Und eh klar, wenn ihr sagt, ja, das geht schon so, kommen noch 1000 Nachfragen, insbesondere zu dem Thema, wie ihr die digitalisierten Daten vom 4222 zum Raspberry schaffen würdet. Danke vorab und schönes WE euch allen noch!
Ordentliche ADC und DAC wirst du blos mit I2S-Interface bekommen. Da ist selbst bei "richtigen" DSP die Anzahl der Ports begrenzt. Fuer einen Mixer der "viele" Kanaele bedienen soll, bleibt da nur ein FPGA. Gluecklicherweise ist die zu leistende Arithmetik beim Mixen ja recht einfach. Aber mit "Inselaffentechnik" wirst das nix. Der kann vielliecht dem FPGA mit den Koeffizienten auf die Spruenge helfen. Aber ein Softcore im FPGA kann das eigentlich auch und sogar einfacher.
Ich hatte mal ein Audio-Projekt mit dem STM32F4 gemacht. Der hat zumindest schonmal zwei bidirektionale I2S Kanäle drinnen. Damit hatte ich 4*in und 4*out realisiert. Auch von der Rechenleistung ging bei 168 MHz schonmal so viel, dass man gut 40 IIR Filter rechnen konnte (mit 16 Bit fixed point und 44,1 kHz) Ansonsten habe ich schon größere Designs gesehen, die irgendwelche Sharks von Analog-Devices drinnen haben. Schau dir mal ein Teardown vom Behringer X32 an, da sind mehrere Analog Devices DSPs drinnen, die untereinander verbunden sind. Damit wurden 32 Kanäle am Eingang und glaube 16 am Ausgang realisiert. Ansonsten wie oben schon geschrieben ist der FPGA das Mittel zur Wahl. Habe auch schonmal ein Audio-Design auf einem FPGA mit I2S und DSP gemacht. VHDL-IIR-Filtermodule findet man im Netz. I2S Protokoll kriegt man sehr schnell auch selber implementiert. FIFOs krieg man fertig. Man muss dann nur wissen, wie man mit fixed-point richtig umgeht in VHDL. Ich hatte nur das Problem damals, dass ich für jeden Filter den ich gebraucht habe, ein neues IIR-Filtermodul instanziiert habe. Damit wird der FPGA recht schnell voll und dabei braucht das Ding dann grad mal 5-6 CLK-Zyklen um ein Sample durchzurechnen. Damit wurde der FPGA sehr schnell sehr voll. Habe auf einem Artix7-35 grad mal 8 IIR-Module reinbekommen glaube ich. Wenn man da per Logik aber ein pipelining macht und verschiedene Audioströme durch das gleiche Modul jagt geht da bestimmt schon sehr sehr viel auf einem (selbst kleinen) FPGA
Carsten P. schrieb: > Theoretisch. Denke ich mir so. Das haben sich auch einige andere schon gedacht. :-) Erstens: Du willst acht Audiokanäle (vier Stereo-Pärchen á 48 kHz) in einen Raspberry bekommen Das sind ~768 KB pro Sekunde an Daten, wenn ich mich nicht verrechnet habe. Wie du das mit deinem DAC machen kannst, weiß ich nicht, ich würde vermutlich einfach ein paar günstige USB-Audiokarten nehmen und die per Hub zusammenschalten. Einerseits skaliert das besser, solange die Rechenleistung reicht, andererseits brauchst du die Samples nicht mehr in Software auseinanderpopeln, weil sie über getrennte Interfaces reinlaufen und der Kernel das für dich macht. Zweitens: Du willst auf Ereignisse reagieren und die Lautstärken anpassen können. Pulseaudio kann sowas. Du definierst, welche Audiostreams du hast (das können ALSA-Geräte sein, also USB-Audio oder so, aber Anwendungen können da auch einspeisen). Wann du welche Lautstärken haben willst, kannst du dann für jeden Ausgabe- und Eingabestream separat festlegen. Drittens: Du willst das Ergebnis mischen und ausgeben. Macht Pulseaudio auch für dich, mit ALSA. Vermutlich kannst du die Daten auch in eine eigene Anwendung kippen und damit einen besseren DAC zu Fuß ansteuern, als ihn der Raspberry enthält. Dein Problem zerfällt also größtenteils von "Software schreiben" zu "vorhandene Software so konfigurieren, dass sie tut, was ich will". Als Dankeschön bekommst du gebrauchbare Algorithmen, kannst mit Effekten arbeiten und so weiter. Da der Raspberry nicht die beste Soundkarte hat, brauchst du auch keinen supertollen Audio-Input (deswegen die USB-Idee). Kannst ja mal konkreter werden, wie du dir das vorstellst.
> ~768 KB pro Sekunde an Daten > ein paar günstige USB-Audiokarten Ja, die koennen m.W. nur USB-FS und kein USB-HS. Ich glaub das wird nix. Dann noch ein wenig Netzwerktraffic und der Bus ist Voll :-).
Ein Einwurf von mir dazu:
Ist die Wiedergabe an verschiedenen Orten problemlos synchronisierbar,
oder wird es hoerbaren Zeitversatz geben ("Bluetooth-Problem")?
Ich finde es immer wieder nett, wenn Enthusiasten versuchen, etwas, was es im Markt schon gibt, billiger und besser zu bauen. Es hat seinen Grund, warum die ADCs im Audiobereich so teuer sind, OBWOHL sie eine hohe Verbreitung haben, im Gegensatz zu mach anderen ADCs. Suche dir mal einen ADC, der bis 100kHz sampelt und noch 24Bit kann. Kostet mal gleich das doppelte.
./. schrieb: > Dann noch ein wenig Netzwerktraffic und der Bus ist Voll :-). Mischen kann man ja schon analog, aber halt digital gesteuert.
> Mischen kann man ja schon analog, aber halt digital gesteuert.
Ja, wenn einen das Rauschen nicht stoert koennte ich aus meiner
S.B.Z.-Kiste einige A273 hervorzaubern.
Denen reicht eine Steuerspannung...
Dein PCM4222 hat übrigens 123dB dynamic range ^= 21 bit. Wenn die Specs etwas schlechter sein dürfen, gibt es deutlich günstigere z.B. PCM1862, Cirrus Logic, AK5522VN und AK5552VN (letzterer kann sogar mit 768kHz samplen).
S. R. schrieb: > Pulseaudio kann sowas. Du definierst, welche Audiostreams du hast (das > können ALSA-Geräte sein, also USB-Audio oder so, aber Anwendungen können > da auch einspeisen). Wann du welche Lautstärken haben willst, kannst du > dann für jeden Ausgabe- und Eingabestream separat festlegen. 7 Jahre Entwicklungszeit um einen ALSA-Wrapper zu haben? Das geht gleich in ALSA, ganz ohne Krampf. Lautstärkeanpassung bleibt aber ein Software-Problem und wird die Rechenzeit so oder so knapp.
./. schrieb: >> ein paar günstige USB-Audiokarten > Ja, die koennen m.W. nur USB-FS und kein USB-HS. Wo ist das Problem? Ein Hub mit USB-HS (braucht man für 4 USB-Geräte an einen Raspberry sowieso) spricht nur HS mit dem Host. Boris O. schrieb: > 7 Jahre Entwicklungszeit um einen ALSA-Wrapper zu haben? Ich wollte ja noch "(mögen die Entwickler in der Hölle schmoren)" dazuschreiben, habe mir das aber verkniffen. So ziemlich alle Distributionen nutzen Pulseaudio, also kann man auch dessen Flexibilität nutzen. Wenn man ALSA direkt nutzen will, landet man sowieso in libpulse, falls Pulseaudio läuft. > Das geht gleich in ALSA, ganz ohne Krampf. Kann man Sockets als Ein-/Ausgaben für getrennte ALSA-Kanäle benutzen und dynamisch Kanäle hinzufügen und entfernen? Bisher habe ich "jede Anwendung hat ihre eigene Lautstärke" nur bei Pulseaudio gesehen, nicht bei reinem ALSA. Das kann aber auch eine Konfigurationssache sein. > Lautstärkeanpassung bleibt aber ein > Software-Problem und wird die Rechenzeit so oder so knapp. Hmm, sollte eigentlich nicht. Die typischen Amiga-Module haben vier Stimmen, und obwohl jeder Kanal noch ein paar Effekte und seine eigene Lautstärke hat, schafft das auch ein 486er mit >44 kHz zu mischen und über den Parallelport (Speech Thing) abzuspielen. Ein Raspberry Pi hat deutlich mehr CPU-Leistung und Bandbreite, um das auch hinzukriegen - trotz USB. Zumal man ein paar ms puffern darf, die Ausgabe also nicht ganz so zeitkritisch ist. Es geht ja hier nicht um absolutes HiFi jenseits der Hörgrenze mit Goldkabeln. ;-)
:
Bearbeitet durch User
Carsten P. schrieb: > meine Idee ist, über einen audio-tauglichen ADC die Signale irgendwie^^ > in den Raspberry zu bekommen und die einzelnen Streams dann in gewissen > Kombinationen per WLAN zur Verfügung zu stellen, Da bist du nicht der erste: https://audac.eu/products/c/solution-boxes/audio-over-ip https://www.macfixit.com.au/stereo-mini-35mm-audio-extender-over-ethernet-cable/
Mach schrieb: > Ist die Wiedergabe an verschiedenen Orten problemlos synchronisierbar, > oder wird es hoerbaren Zeitversatz geben Eine Möglichkeit ist die Laufzeitbestimmung zu jeder Senke und dann das Abspielen mit einer zur jeweiligen Laufzeit jeder einzelnen Senke passenden Verzögerung, insgesamt also an die langsamste Senke angepasst. Ein entsprechendes Verfahren verwendet Apple im AirPlay-Protokoll, und das ist gut genug, daß damit auch Stereophonie über separate Senken möglich ist.
MaWin schrieb: > Da bist du nicht der erste: > > https://audac.eu/products/c/solution-boxes/audio-over-ip Zu Zeiten der Einführung von ISDN gab es so was um Tonaufnahmen zu Studios übers Telefon zu verschicken. War vor 20 Jahren.
Mach schrieb: > ./. schrieb: > Dann noch ein wenig Netzwerktraffic und der Bus ist Voll :-). > > Mischen kann man ja schon analog, aber halt digital gesteuert. Ohne Hub mit Multi Transaction translator wird das trotzdem von der Bandbreite sehr eng. Dummerweise gibt kein ein Hersteller an, ob sein Hub das besitzt. Ich denke die Latenz wird bei USB das schwierigere Problem sein.
S. R. schrieb: > So ziemlich alle Distributionen nutzen Pulseaudio, also kann man auch > dessen Flexibilität nutzen. Wenn man ALSA direkt nutzen will, landet man > sowieso in libpulse, falls Pulseaudio läuft. Nur weil sich alle Hosen anziehen, muss das nicht die beste aller Ideen sein. > >> Das geht gleich in ALSA, ganz ohne Krampf. > > Kann man Sockets als Ein-/Ausgaben für getrennte ALSA-Kanäle benutzen > und dynamisch Kanäle hinzufügen und entfernen? Bisher habe ich "jede > Anwendung hat ihre eigene Lautstärke" nur bei Pulseaudio gesehen, nicht > bei reinem ALSA. Das kann aber auch eine Konfigurationssache sein. Mir ist nicht ganz klar, was du mit »Socket« meinst, aber wenn es irgendeine Art von file handle wird, der irgendeine Audio-Beschreibung mitliefert, geht es einfach über 'ne Pipe. So ganz erschließt sich mir davon aber der Zweck nicht. ALSA braucht ja nur ein dmix-Plugin und mischt in Echtzeit selbst. Es bleibt aber dabei: irgendetwas mit LADSPA und Co rumzukonfigurieren braucht Rechenzeit. Mit einer Mehrkanal-Audio-Karte ist das etwas ganz anderes, die hat aber einen Hardware-Mixer.
Dass ich hier so eine Debatte lostrete, hab ich nicht geahnt ^^ Mit Alsa und PulseAudio hab ich mich schon ein wenig beschäftigt, ich mag nur diese monolithische Struktur nicht. Und oh ja, aus der Sicht meines eigentlichen Berufs als Software-Architekt IST das monolithisch. "Folgst du nicht MEINEN Ideen, hast DU halt Pech gehabt!". Und war da nicht was, dass Debian einen Teil vom dem Audio-Zeug mal eben aus dem Repository geworfen hat? Der Code, den habe ich mir inzwischen mal angeschaut, ist aber auch nur dann "schön", wenn man einen sehr eigenen Begriff von Schönheit oder auch nur Eleganz und Verständlichkeit hat. Dieses Stückchen Software ist freilich brauchbar und gut zu haben, aber es leidet doch einmal mehr am üblichen Problem. Wie gesagt: "Think the way I do, or get lost!" Trotzdem ist der Ansatz mit ein paar USB-Eingängen ganz sympathisch. Von der Performance her möchte ich aber nicht vom Raspberry-Ansatz abrücken. Und auch nicht von der Flexibilität. Linux, und nicht nur Linux, könnte einen all-purpose-Signal Router vertragen, in den man reingrätschen kann und dann mit den Signalen veranstalten, was man will, ob nun Audio, Video oder nur Mausklicks. Aber das ist ein eine andere Geschichte ^^
Hat der Raspberry nicht I2S auf dem Pinheader? Vielleicht kann man einen CS42448 da anschließen. Da SMD scheinbar ein Problem ist, der PCM1808 und ADAU1701 gibts auf Boards mit einfach zu erreichenden Pins.
S. R. schrieb: >> Das geht gleich in ALSA, ganz ohne Krampf. > > Kann man Sockets als Ein-/Ausgaben für getrennte ALSA-Kanäle benutzen > und dynamisch Kanäle hinzufügen und entfernen? Und kann man dynamisch die einzelnen Anwendungen den verschiedenen Ein-/Ausgängen zuordnen? > Ein Raspberry Pi hat deutlich mehr CPU-Leistung und Bandbreite, um das > auch hinzukriegen - trotz USB. Zumal man ein paar ms puffern darf, die > Ausgabe also nicht ganz so zeitkritisch ist. Das hätte ich jetzt anders gesehen. Ein Mischer sollte ja eigentlich keine erkennbare Latenz haben. Wenn man z.B. einen Film anschaut, soll das Audiosignal ja lippensynchron bleiben. Und ganz besonders anspruchsvoll wird's mit den Latenzen bei dieser Anforderung: Carsten P. schrieb: > Also, meine Idee ist, über einen audio-tauglichen ADC die Signale > irgendwie^^ in den Raspberry zu bekommen und die einzelnen Streams dann > in gewissen Kombinationen per WLAN zur Verfügung zu stellen, die dann in > den einzelnen Räumen an die dortigen Boxen geleitet werden.
Vielleicht muss ich trotz all der wirklich guten Tipps gerade zu FPGAs und fertigen Bausteinen nochmal reingrätschen hier... Ich mag aus softwareseitiger Sicht grundsätzlich keine monolithischen Lösungen. Ein Chip, egal, wie er aussieht, der mir die 4 Stereo-Kanäle zusammenrührt und daraus 1 Stereo-Ausgangs-Signal auch mit 92kHz und 32Bits zaubert, ist mir latte, weil er nicht meine Anforderungen erfüllt. Meine Anforderung ist (ob sich das mit dem Raspberry realisieren lässt oder nicht, dazu würden mich Aussagen dann tatsächlich interessieren): "Chips, samplet mir diese 4 Kanäle, und liefert mir die Daten so, dass ich was damit anfangen kann!" Wer good old WIN32 Programmierung kennt, weiß, wie ätzend es ist, sich auf Tastatur- und Maus-Ereignisse "draufzuschalten", geschweige denn, sie zu modifizieren. Und genausowenig möchte ich einen Chip, der mir die Eingänge zusammenmixt, und dessen Ausgangsdaten ich dann nachträglich auseinander dröseln muss. Wenn der ein Raspberry das nicht leisten kann, was mich möchte, belästige ich halt ein paar CUDAs auf meinem Heimserver damit. Dann müsste ich aber wohl in die USB-Datenstreams von den von anderen erwähnten Geräten grätschen? oO PS: Das Stichwort "Lippensynchronizität" war ein gutes. Streicht mal die Sache mit dem TV-Ton aus der Wunschliste. Mit Audio-Signalen und -Formaten kenne ich mich noch halbwegs aus, bei Video-Codecs bin ich nicht mehr dabei^^
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Ein entsprechendes Verfahren verwendet Apple im AirPlay-Protokoll, und > das ist gut genug, daß damit auch Stereophonie über separate Senken > möglich ist. Schon mal gemessen? Was ich bei den BT- und anderen wireless Systemen so sehe, ist das ein bischen weg von Triple AAA rating, bzw bedarf entsprechender Signalaufbereitung und damit Kosten. Die billigen Brüllwürfel, die allerorten Verwendung finden, kann man getrost abhaken.
Rolf M. schrieb: > Ein Mischer sollte ja eigentlich keine erkennbare Latenz haben. Hat er aber trotzdem, weil man Audio immer in größeren Puffern verarbeitet. Ein Audioplayer dekodiert z.B. gerne mehrere Sekunden und kippt die am Stück in das Audiosystem, um danach eine Weile Ruhe zu haben - das spart Energie. Relativ konstante Latenzen kann man meist ausgleichen. > Wenn man z.B. einen Film anschaut, soll > das Audiosignal ja lippensynchron bleiben. Das heißt nur, dass Audio und Video zueinander synchron sind und nicht, dass sie zum Eingangssignal synchron sind. So ziemlich alle Mediaplayer nehmen die Audio-Timestamps als Grundlage, um zu entscheiden, wann welcher Videoframe wie lange angezeigt werden soll. Schneidet man gnadenlos Audiosamples raus, ruckelt das Video. Schiebt man zusätzliche Bilder rein, werden sie nicht angezeigt. Das kann man ausnutzen.
S. R. schrieb: > So ziemlich alle Mediaplayer nehmen die Audio-Timestamps als Grundlage, > um zu entscheiden, wann welcher Videoframe wie lange angezeigt werden > soll. Woher kommt diese Info? Rolf M. schrieb: > Das hätte ich jetzt anders gesehen. Ein Mischer sollte ja eigentlich > keine erkennbare Latenz haben. Wenn man z.B. einen Film anschaut, soll > das Audiosignal ja lippensynchron bleiben. Und ganz besonders > anspruchsvoll wird's mit den Latenzen bei dieser Anforderung: Das kann man doch am Player einstellen. Videoverarbeitung ist doch aufwändiger und erzeugt mehr Verzögerung. Deshalb wird das Audio immer mit verzögert.
S. R. schrieb: > Rolf M. schrieb: >> Ein Mischer sollte ja eigentlich keine erkennbare Latenz haben. > > Hat er aber trotzdem, weil man Audio immer in größeren Puffern > verarbeitet. Ein Audioplayer dekodiert z.B. gerne mehrere Sekunden und > kippt die am Stück in das Audiosystem, um danach eine Weile Ruhe zu > haben - das spart Energie. Vielleicht hab ich ja was falsch verstanden, aber hier ging es soweit ich sehen kann nicht um einen Media-Player, der das Audio-Signal irgendwie zusammenmischt und ausgibt, sondern um ein separates Gerät, das analoge Audiosignale entgegennimmt, intelligent zusammenmischt und an mehrere Ziele passend verteilt wieder ausgibt. Normalerweise würde ich nicht davon ausgehen, dass so ein Gerät eine große Latenz hat, die man ausgleichen müsste. >> Wenn man z.B. einen Film anschaut, soll >> das Audiosignal ja lippensynchron bleiben. > > Das heißt nur, dass Audio und Video zueinander synchron sind und > nicht, dass sie zum Eingangssignal synchron sind. Ja, aber ein Video-Signal noch zusätzlich aufzunehmen und passend zum Audiosignal verzögert wieder auszugeben, dürfte ziemlich viel Aufwand sein. Audiomann schrieb: > S. R. schrieb: >> So ziemlich alle Mediaplayer nehmen die Audio-Timestamps als Grundlage, >> um zu entscheiden, wann welcher Videoframe wie lange angezeigt werden >> soll. > > Woher kommt diese Info? Das würde mich auch interessieren, denn ich kenne das eher so, dass sie das Bild mit dem Bildschirm synchronisieren und dann den Ton ggf. etwas strecken oder stauchen, um den Ton ans Bild anzupassen. Denn die Bildwiederholfrequenz vom Fernseher kann der Player in der Regel nicht dynamisch verändern, und das Auslassen oder Duplizieren von einzelnen Bildern erzeugt unschöne Ruckler.
Zur Uridee: Das mit dem PCM4222 und Multiplexer wird nicht funktionieren: Der PCM4222 ist ein Sigma-Delta Wanddler (1Bit / massives oversampling) dem digitale Filter folgen, um die 24Bit am Augang zu rechnen. Wenn Du das im im Zeitmultiplex fütterst hast du mindestens heftiges Übersprechen wenn nicht eine sogar eine miserable Qualität.
Audiomann schrieb: >> So ziemlich alle Mediaplayer nehmen die Audio-Timestamps als Grundlage, >> um zu entscheiden, wann welcher Videoframe wie lange angezeigt werden >> soll. > > Woher kommt diese Info? Von der Arbeit. Da spielen wir nämlich u.a. mit den Timestamps von Multimediadateien rum, und da fällt sowas auf. Der Hintergrund ist, dass falsch abgespielte oder vergessene Audiosamples ein deutlich hörbares Knacksen im Lautsprecher produzieren, ein fehlendes Bild nur einen kaum wahrnehmbaren Ruckler. Außerdem ist die Audio-Samplerate konstant (bis auf ein bisschen Drift). Framedrops können sowohl bei der Aufnahme, als auch bei der Wiedergabe entstehen. Rolf M. schrieb: > Das würde mich auch interessieren, denn ich kenne das eher so, dass sie > das Bild mit dem Bildschirm synchronisieren und dann den Ton ggf. etwas > strecken oder stauchen, um den Ton ans Bild anzupassen. Das gibt es auch, ist aber eher selten, weil der Player dazu das Audiosignal filtern (bzw. direkt resamplen) muss, um Knackser zu vermeiden. Dazu kommt dann oft noch ein Resampling im Ausgabegerät, was die Qualität weiter verringert. Probiert das mal aus, indem ihr ein dickes Video nehmt, den Player auf niedrige Priorität stellt und dann die CPU stark belastet. Es sollte zu Framedrops kommen, während der Ton eher normal weiterläuft. > Denn die Bildwiederholfrequenz vom Fernseher kann der Player > in der Regel nicht dynamisch verändern, und das Auslassen oder > Duplizieren von einzelnen Bildern erzeugt unschöne Ruckler. Die Bildwiederholfrequenz ist in der Regel deutlich höher als die Framerate, also muss man Bilder nie wegschmeißen, wenn das System schnell genug ist. Es jittert halt ein bisschen, bei 30 fps Video und 60 Hz Wiederholrate sind das +- 16 ms. Das fällt nicht auf. Rolf M. schrieb: > Normalerweise würde ich nicht davon ausgehen, dass so > ein Gerät eine große Latenz hat, die man ausgleichen müsste. Erstmal gehe ich davon aus, das jedes digitale, signalverarbeitende System eine gewisse Latenz hat. :-) In meiner Vorstellung ging es um ein Raspberry, wo mehrere Audioquellen angeschlossen sind, die zusammengemischt und weiterverteilt werden sollen, und zwar sowohl analog als auch digital (WLAN, Ethernet). Letzteres macht schon deutliche Latenz, da kommt es auf den Mischer nicht mehr an. Andererseits, solange man nicht den gleichen Stream mehrfach hört (z.B. das gleiche Radiosignal an drei Zimmer per WLAN verteilt) oder bidirektionale Echtzeitkommunikation macht, muss da sowieso nichts ausgleichen. Selbst eine drittel Sekunde ist für eine Gegensprechanlage noch akzeptabel.
S. R. schrieb: > Andererseits, solange man nicht den gleichen Stream mehrfach hört (z.B. > das gleiche Radiosignal an drei Zimmer per WLAN verteilt) Das hier habe ich so verstanden, dass genau das getan werden soll: Carsten P. schrieb: > Also, meine Idee ist, über einen audio-tauglichen ADC die Signale > irgendwie^^ in den Raspberry zu bekommen und die einzelnen Streams dann > in gewissen Kombinationen per WLAN zur Verfügung zu stellen, die dann in > den einzelnen Räumen an die dortigen Boxen geleitet werden.
Rolf M. schrieb: > Das hier habe ich so verstanden, dass genau das getan werden soll: Ich wollte damit ausdrücken, dass man bei unterschiedlichen Streams nichts ausgleichen muss. Wenn es um gleiche Streams geht, muss man den Rest betrachten. Aber: Das Stichwort hier ist "WLAN". Das allein wesentlich macht mehr Latenz als der Mischer, selbst wenn er suboptimal implementiert ist. Dazu kommt dann noch die Signallaufzeit zwischen z.B. Küche und Wohnzimmer. Wenn man mit der zwangsweise entstehenden Latenz nicht leben kann, dann muss man sie irgendwie ausgleichen. Die Eigenlatenz des Mischers ist - weil konstant - dabei aber auch egal.
Die "Latenzen" zwischen z.B. Wohnzimmer und Küche ergäben sich ja schon durch die Schallgeschwindigkeit, das heißt, wenn ich im Wohnzimmer bin und der Stream in der Küche laut genug und total synchron ist zum Stream im Wohnzimmer, würde sowohl mein Hören als auch das einer Person in der Küche entsprechend gestört. Ich höre aber nicht auf Konzertlautstärke, und vielleicht hat hier ja "Feng Shui" mal wirklich Sinn, das ja dazu rät, dass man Zimmertüren geschlossen halten sollte ;-) Also, Latenzen bis zu einer Sekunde oder würden mich nicht stören. Ihr seid doch auch sicher mal vom Fernseher aufgestanden und dann ins Bett und habt die Sendung weiter geschaut auf dem Handy/Tablet. Da sind Latenzen von einer halben Minute eher der Normalfall. Und wie gesagt, Video-Streams habe ich ja schon von meiner Wunschliste gestrichen^^
:
Bearbeitet durch User
Sag ich ja. :-) Nimm einfach ein Raspberry Pi, klemme ein paar USB-Audiodinger per USB-Hub an und befasse dich mit PulseAudio (oder ALSA). Damit wirst du einen Großteil deiner Anforderungen recht gut erschlagen bekommen, und den Rest kannst du da dann mit einbeziehen. Die Audioqualität hängt dann hauptsächlich von den USB-Teilen ab, die es von billig bis großartig gibt. Mit so einem Ansatz kannst du erstmal günstig testen, produktiv gute Ergebnisse bekommen und vor allem in der Zukunft wunderbar skalieren. Ich wäre für deine Erfahrungen sehr dankbar. :-D
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.