Hallo, für ein Uniprojekt möchte ich einen einfachen Prototypen für ein Audio over IP Streaming-System entwickeln. Der Fokus soll dabei auf der Synchronisierung liegen. Zu diesem Zweck bin ich auf der Suche nach einem Board (Reference, Evaluation, Development), dass IEEE1588/PTP unterstützt und auf dem die Network Clock einen Audio PLL steuert, der wiederum die Audio Clock steuert. Ziel ist sample-synchrone Wiedergabe auf zwei oder mehr Empfängern. Ich weiß, dass es mit Dante, Ravenna und AVB schon Standards bzw. kommerzielle Lösungen gibt. In diesem Projekt sollen vor allem die Grundlagen der Taktsynchronisierung und -rückgewinnung ausgeleuchtet werden. Ich habe schon überlegt, ob man das Ganze mit einem FPGA (z. B. Zynq-7000) lösen kann, da ich aber weder VHDL noch Verilog beherrsche, ist das wohl keine realistische Lösung. Kann mir jemand ein Board mit entsprechender Ausstattung empfehlen? Danke Jan
:
Verschoben durch Moderator
schau Dir mal den Beaglebone Black an. Dessen Ethernetschnittstelle ist IEEE1588-kompatibel und da gibt es auch einen Linuxtreiber der das unterstützt. Außerdem kannst Du den Onboard-Quarz auslöten und da extern einen Takt einspeisen. Über ein paar Widerstände kannst Du das einstellen. Darüber könntest Du Deine PLL anbinden. Der I2S-Output ist recht flexibel konfigurierbar. Es gibt glaube ich auch noch für Audio einen separaten Takt den Du zusätzlcih einspeisen kannst. Das hab ich aber grad nicht im Detail im Kopf. Lies Dir also mal das SRM des Beaglebone Black durch und danach das Datasheet und Reference Manual des Prozessors bei TI.
Auch wenn du weißt, > dass es mit Dante, Ravenna und AVB schon Standards bzw. > kommerzielle Lösungen gibt ... möchte ich hier AVB empfehlen. Das ist zwar nicht mehr wirklich aktuell, aber es gibt hier von XMOS eine Open Source Implementierung. Da sparst du dir einiges an Arbeit und kannst selber im Rahmen deines Projektes experimentieren. Von XMOS gibt es da ein modulares Entwicklungskit "SliceKit". Für Audio over IP bräuchtest du ein Core Board, Netzwerkboard und vermutlich auch ein (analoges) Audioboard. Ich weiß, die sind nicht billig, aber ich finde die super, u.a. die wirklich umfangreiche Beispielsoftware. Eventuell schreibt man denen als Student/Uni auch einfach mal eine Mail und fragt ob die einem helfen, die sind echt hilfsbereit. Schau mal hier: https://www.xmos.com/support/boards?product=15826 https://www.xmos.com/support/boards?product=15830 https://www.xmos.com/support/boards?product=15827 Grüße, Ludwig
Bzgl. Open Source findet sich auch bei Linux was. http://jackaudio.org/faq/netjack.html das ließe sich evtl. mit einem Banana oder Raspi bewerkstelligen. Aber vielleicht habe ich auch einfach nicht gut genug verstanden, was du willst. Gerhard
Hi, wir sind an einem ähnlichen Projekt interessiert im Zusammenhang mit unserer Mehrkanalaudiolösung für den Beaglebone (Thread hier: Beitrag "Linuxbasiertes Mehrkanal-Audiosystem mit niedriger Latenz" ) Der Beaglebone sollte eigentlich für AVB nutzbar sein, wir haben PTP zumindest schon einmal eingeschaltet bekommen. Falls Interesse besteht könnten wir auch zusammenarbeiten. VG, Robert
Robert schrieb: > Hi, wir sind an einem ähnlichen Projekt interessiert Gibts doch schon - Squeezebox
>auf dem die Network Clock einen Audio PLL steuert
Nanu? Wer macht denn heutzutage noch so etwas? Die heute üblichen Chips
haben doch genug Gigaherz, können nebenbei Audio ohne Jitter ausgeben.
Willst du eine Linuxplatine nehmen und alles in Software machen, oder
willst es mit der minimalen Hardware realisieren?
Jan D. schrieb: > Ziel ist sample-synchrone Wiedergabe auf zwei oder mehr > Empfängern. Aus meiner Sicht gibt es Latzenzen im Netzwerk und auf dem abspielenden Gerät. Sample-synchron würde aber einen gemeinsamen Takt erfordern. Wie wird das denn vom Grundsatz her gemacht?
Wenn man das mal einfach beschreibt -> die PTP gibt die gemeinsame Zeit vor. Diese Zeit wird genommen um die Präsentation Zeit zu berechnen das ist die Zeit einfach ausgedrückt wann das Sample zur Verarbeitung beim Empfänger verfügbar sein muss. Diese ergibt sich aus der Sampling Frequenz und ein paar Nebeneffekten. Diese Zeit liegt natürlich in der Zukunft :). Durch die gemeinsame Zeit kann der Empfänger berechnen wann er das Sample verarbeiten muss. Die Kunst ist es die Uhren synchron zuhalten und dafür zu sorgen das die Samples auch rechtzeitig da sind wenn sie benötigt werden. Die PTP ist nicht alles, AVB basiert auf Layer 2 (MAC Ebene) da beginnt schon die Schwierigkeit bei Linux basierten System. Egal ob Dante,AVB etc.. alle verwenden die PTP um die Uhren zu synchronisieren. Das nächste Problem sind die Normen der IEEE, um zu verstehen wie es funktioniert musst du diese käuflich erwerben. Bei AVB hängt so viel hinten dran das mehre hundert Dollar drauf gehen für Papier. Ohne diese Grundlagen wird es auch schwer den Xmos AVB Core zu verstehen. Hinzu kommt noch die Eigenarten der Xmos MCUs die einiges an Besonderheiten mit sich bringen
:
Bearbeitet durch User
Robert schrieb: > Hi, wir sind an einem ähnlichen Projekt interessiert im > Zusammenhang mit > unserer Mehrkanalaudiolösung für den Beaglebone (Thread hier: > Beitrag "Linuxbasiertes Mehrkanal-Audiosystem mit niedriger Latenz" ) > > Der Beaglebone sollte eigentlich für AVB nutzbar sein, wir haben PTP > zumindest schon einmal eingeschaltet bekommen. > > Falls Interesse besteht könnten wir auch zusammenarbeiten. > > VG, Robert Hallo Robert, Bei diesem Projekt geht es um meine Bachelorarbeit. Ich habe das Thema jetzt so gewählt, dass ich es mit einem beliebigen Board umsetzen kann. Nur PTP Hardware Timestamping muss unterstützt werden. Die Bachelorarbeit von Henrik Langer habe ich schon in meiner Materialsammlung. Ich habe sie bisher nur überflogen, aber das ist sehr interessant. Ich bin aber auch unabhängig von der Bachelorarbeit an dem Thema interessiert. Wir können gerne über eine Zusammenarbeit reden. Was genau wollt ihr denn machen? Viele Grüße, Jan
Arne schrieb: > Nimm dir bspw. einen Raspi und eine dazu passende Soundkarte Raspberry Pi kommt leider nicht in Frage, da Pis kein PTP Hardware Timestamping unterstützen und sich deshalb nicht genau genug synchronisieren lassen. Außerdem müsste man noch klären, in wie weit sich der Audio-Takt synchronisieren lässt.
Walter schrieb: > Robert schrieb: >> Hi, wir sind an einem ähnlichen Projekt interessiert > > Gibts doch schon - Squeezebox Ich habe Squeezebox noch nicht ausprobiert. Ich frage mich, wie synchron die Wiedergabe läuft. Ziel meiner ursprünglichen Idee ist sample-synchrone Wiedergabe.
Noch einer schrieb: >>auf dem die Network Clock einen Audio PLL steuert > > Nanu? Wer macht denn heutzutage noch so etwas? Die heute üblichen Chips > haben doch genug Gigaherz, können nebenbei Audio ohne Jitter ausgeben. > > Willst du eine Linuxplatine nehmen und alles in Software machen, oder > willst es mit der minimalen Hardware realisieren? Es geht darum die Sample-Clock auf mehreren Quellen und Senken zu synchronisieren. Ursprünglich war meine (naive) Idee das in Software auf Basis eines Eval-Boards, Pis oder BBs zu machen, aber so ganz trivial ist es nach meinem aktuellen Verständnis leider nicht. Die Nodes per PTP zu synchronisieren ist einfach, aber davon dann den Takt für das Audio zu generieren ist für mich kompliziert.
Ahnungslos schrieb: > Jan D. schrieb: >> Ziel ist sample-synchrone Wiedergabe auf zwei oder mehr >> Empfängern. > > Aus meiner Sicht gibt es Latzenzen im Netzwerk und auf dem > abspielenden Gerät. Sample-synchron würde aber einen gemeinsamen > Takt erfordern. > > Wie wird das denn vom Grundsatz her gemacht? Genau, der gemeinsame Audio-Takt ist was ich erreichen wollte. Das geht m. E. nicht ohne spezielle Hardware bzw. Modifikation von Standard-Hardware. Im Grundsatz wird PTP verwendet um eine gemeinsame Clock auf allen Quellen und Senken zu erzeugen. Davon ausgehend wird nach meinem aktuellen Verständnis eine "Media Clock" gewonnen, mit dem der Audio Codec getaktet wird. Eine Software-basierte Lösung ist auch möglich, allerdings braucht man dann Sample-Rate-Conversion.
Marco H. schrieb: > Wenn man das mal einfach beschreibt -> die PTP gibt die gemeinsame > Zeit > vor. Super Erklärung, danke :)
Jan D. schrieb: > Genau, der gemeinsame Audio-Takt ist was ich erreichen wollte. Das geht > m. E. nicht ohne spezielle Hardware bzw. Modifikation von > Standard-Hardware. Wie lang sind denn deine Samples? Wenn ein sample bspw. 2ms lang ist, könnte man hin und wieder eine unterschlagen oder ein Dummy Sample einfügen, um wieder synchron zu werden.
Arne schrieb: > Jan D. schrieb: >> Genau, der gemeinsame Audio-Takt ist was ich erreichen wollte. Das geht >> m. E. nicht ohne spezielle Hardware bzw. Modifikation von >> Standard-Hardware. > > Wie lang sind denn deine Samples? Wenn ein sample bspw. 2ms lang ist, > könnte man hin und wieder eine unterschlagen oder ein Dummy Sample > einfügen, > um wieder synchron zu werden. Hallo Arne, die Pakete wären je nach Konfiguration unterschiedlich groß, aber ~2ms ist realistisch. Bei 48000Hz und 128 Frames pro Packet wären es 2,67ms. Deine Idee wäre eine einfache Lösung, aber je nach Audioinhalt wird das mehr oder weniger stark durch Knackser hörbar sein. Ein besseres Ergebnis würde man mit adaptivem Resampling erreichen, aber dazu müsste ich die tatsächlichen Sample-Frequenzen auf Quelle und Senke ermitteln. Ich habe schon versucht das anhand der Frequenz zu ermitteln, mit der ALSA nach neuen Audiodaten fragt. Da habe ich aber soviel Jitter drin, dass es nicht brauchbar ist. Viele Grüße Jan
:
Bearbeitet durch User
Ist Alsa auf der Sendeseite? Wenn ja, dann dürfte die Anpassung der Audio-Frequenz auf der Alsa-Seite sowieso nicht helfen, weil dann ja alle Empfänger dei Freuqenzänderung mitbekommen. I.d.R. würde doch aber jeder Empfänger seine eigene Drift haben. Könnte man das nicht auch über den Sample-Puffer regeln? Also wenn bspw. der Sender mit fester Frequenz sendet und jeder Empfänger die Aufgabe hat, seinen Sample-Puffer auf 50% Füllstand zu halten, hat man doch somit "indirekt" einen Audio-Clock - oder? Thema Knacken bei Weglassen oder Einfügen: Einfüge-Samples könnte man so rechnen, dass sie einen Spannungsanstieg - oder abfall vom letzten zum nächsten Samplewert darstellen - kein Knacken. Beim Weglassen müsste man einen Teil weglassen, der am Anfang und am Ende einen ähnlichen Samplewert hat. Im Normalfall ist das bei einem IP Frame mit PCM-kodiertem 44kHz Stereo Audio nicht hörbar. Gibt es bei dir Gründe, es aufwändiger zu machen?
Arne schrieb: > Ist Alsa auf der Sendeseite? > Wenn ja, dann dürfte die Anpassung der Audio-Frequenz auf der Alsa-Seite > sowieso nicht helfen, weil dann ja alle Empfänger dei Freuqenzänderung > mitbekommen. I.d.R. würde doch aber jeder Empfänger seine eigene Drift > haben. ALSA ist auf Sende- und Empfängerseite. Ich bin nicht sicher, ob dich richtig verstanden habe. Den Drift gilt es zu kompensieren. Ich stelle es mir so vor: Der PTP-Master gibt die Clock vor und von dieser Clock wird eine "externe" Abtastrate abgeleitet. Jeder Node muss dann kontinuierlich die "interne" Abtastrate des Audio Codecs bzw. der Soundkarte relativ zur PTP Clock ermitteln. Der Sender konvertiert die Abtastrate vor dem Senden von der internen auf die externe Abtastrate und die Empfänger konvertieren nach dem Empfangen von der externen auf die interne Abtastrate. > Könnte man das nicht auch über den Sample-Puffer regeln? > Also wenn bspw. der Sender mit fester Frequenz sendet und jeder > Empfänger die Aufgabe hat, seinen Sample-Puffer auf 50% Füllstand zu > halten, hat man doch somit "indirekt" einen Audio-Clock - oder? Das hört sich interessant an. Ich habe auch schon überlegt mich am Buffer zu orientieren. Aber wann wird der Sample-Buffer angeglichen? Im Moment laufen im Empfänger zwei Threads: ein Thread empfängt Pakete und befüllt den Buffer, der andere liest aus dem Buffer und gibt die Audiodaten an ALSA. Der Füllstand des Buffers schwankt also um 50%, aber an welcher Stelle kann ich sicher sagen, ob Samples rein oder raus müssen? > Thema Knacken bei Weglassen oder Einfügen: > Einfüge-Samples könnte man so rechnen, dass sie einen Spannungsanstieg - > oder abfall vom letzten zum nächsten Samplewert darstellen - kein > Knacken. > Beim Weglassen müsste man einen Teil weglassen, der am Anfang und am > Ende einen ähnlichen Samplewert hat. > Im Normalfall ist das bei einem IP Frame mit PCM-kodiertem 44kHz Stereo > Audio nicht hörbar. Gibt es bei dir Gründe, es aufwändiger zu machen? Das wäre im Prinzip ein einfaches Resampling. Für professionelle Audioanwendungen ist das immer noch nicht gut genug und in die Richtung ging die ursprüngliche Idee. Sample-synchrone Wiedergabe ohne Resampling. Davon bin ich aber inzwischen weg und von daher ist dein Vorschlag interessant.
Jan D. schrieb: > Aber wann wird der Sample-Buffer angeglichen? Soll das per UDP laufen? Multicast? Wenn der Sender eine Übertragung startet, könnte er den ersten Frame markieren. Wenn ein neuer Empfänger zu einer laufenden Übertragung hinzukommt, müsste wieder ein "erster Frame" geschickt werden. > Der Füllstand des Buffers schwankt also um 50%, aber > an welcher Stelle kann ich sicher sagen, ob Samples rein oder raus > müssen? keine Ahnung. Wie stark schwankt der Buffer? Das Problem ist bei dir vielleicht, dass der Netzwerkstack und Alsa zeitlich gesehen ein Eigenleben führen. Ich hatte es damals auf Empfängerseite mit einem Mikrocontroller gemacht. Da hat das Prinzip "Buffer auf 50% halten" gut funktioniert. Aber wenn du auf Sende- und Empfängerseite Alsa nutzt, bist du zu weit von der Hardware weg, um die "Buffer auf 50% halten" Variante funktioniert. Da wäre ClockGenerierung via PTP wohl schon richtig. Dann müsstest du (glaube ich) nur den Alsa Buffer des Empfängers beobachten: Wenn der Füllstand steigt, muss der Alsa Sender langsamer machen und vice versa.
Arne schrieb: > Da wäre ClockGenerierung via PTP wohl schon richtig. Warum willst Du per PTP eine Clock generieren? PTP bietet doch die Möglichkeit die Systemclock des Players auszumessen und dann bei Bedarf (langsam) an die des Masters anzupassen. Wenn die I2S-Clock des Players an der Systemclock hängt, wird die damit automatisch auch mit angepasst, so daß Du hinterher im Schnitt keine Abweichung mehr hast. Dann wäre auch kein Resampling mehr nötig. Oder übersehe ich da etwas?
Gerd E. schrieb: > Arne schrieb: >> Da wäre ClockGenerierung via PTP wohl schon richtig. > > Warum willst Du per PTP eine Clock generieren? Ich vermute, weil die I2S-Clock nicht immer die SYSCLK ist? Konzeptionell ist es in z. B. AVB so, dass ein Audio PLL von der PTP Clock eine Referenz-Frequenz bekommt und damit den Takt für den Audio Codec erzeugt. https://www.cirrus.com/jp/pubs/appNote/AN408REVA.pdf Ich vermute, dass es mit Dante und Ravenna ähnlich funktioniert. Wenn die "Slave Clock" die SYSCLK ist ... > PTP bietet doch die Möglichkeit die Systemclock des Players auszumessen > und dann bei Bedarf (langsam) an die des Masters anzupassen. Wenn die > I2S-Clock des Players an der Systemclock hängt, wird die damit > automatisch auch mit angepasst, so daß Du hinterher im Schnitt keine > Abweichung mehr hast. Im Paket LinuxPTP gibt es ein Programm phc2sys. Laut Man-Page: phc2sys is a program which synchronizes two clocks in the system. Typically, it is used to synchronize the system clock to a PTP hardware clock (PHC), which itself is synchronized by the ptp4l(8) program. Ich bin nicht ganz sicher, was hier mit "system clock" gemeint ist, aber ich vermute stark, dass es sich um die Linux Clock handelt und nicht um die SYSCLK auf der Hardware-Ebene. Oder liege ich da falsch? Ich hoffe es ja. > Dann wäre auch kein Resampling mehr nötig. Das wär klasse.
Jan D. schrieb: > Ich bin nicht ganz sicher, was hier mit "system clock" gemeint ist, aber > ich vermute stark, dass es sich um die Linux Clock handelt und nicht um > die SYSCLK auf der Hardware-Ebene. ja, da hast Du vermutlich Recht. Dann geht das so nicht. Ich hatte mir mal überlegt aus nem Beaglebone Black ne PTP und NTP-Masterclock zu bauen, in dem ich den Quarz des BBB auslöte und stattdessen das Signal von einem OCXO einspeise. Mit einem Counter das Signal des OCXO gleichzeitig mit einem GPS vergleichen und dann den OCXO per DAC tunen. Sowas ähnliches könntest Du auch machen, nur halt statt dem GPS die PTP-Zeit nehmen. Und ein echter OCXO muss es für Audio vermutlich auch nicht sein, ein günstiger VCTCXO dürfte es auch tun.
Moin, Gerd E. schrieb: > Ich hatte mir mal überlegt aus nem Beaglebone Black ne PTP und > NTP-Masterclock zu bauen, in dem ich den Quarz des BBB auslöte und > stattdessen das Signal von einem OCXO einspeise. Solche Ueberlegungen hab' ich auch schon angestellt - aber mit voltage control statt "al forno". Unangenehm dabei ist aber, dass an den Takten solcher SoCs immer ein ganzer Haufen PLLs haengt z.b. fuer so Sachen wie: SDRAM-Clock, PCIe-Clock, USB-Clock, ... In entsprechenden Datenblaettern steht auch bestenfalls was ueber die Toleranzen der Quarze/Oszillatoren aber ueblicherweise steht da nix ueber maximal zulaessige Frequenzaenderungsgeschwindigkeiten- und Bereiche. Bei Audio hat man noch den Vorteil, dass es relativ langsam ist; d.h. mit resampling auf eine - aus Sicht des SoCs - leicht daneben liegende Abtastfrequenz (z.b. 48.0001kHz) ist da noch per SW machbar. Bei Video sieht's schon anders aus... Samples weglassen oder verdoppeln um Samplerates "anzupassen" ist immer eine Shiceidee. Nicht machen. Gruss WK
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.