HI Leute, ich stehe vor einem Problem, dass ich auf einem uC dynamisch einen Audio-Datenstream via UDP Pakete aus einem IP Netzwerk bekomme. Prinzipiell weiß ich die sample-rate (48 kHz). Leider kann man nie davon ausgehen, dass die 48 kHz input-datenstrom genau 48 kHz sind, sondern vlt 48,008 etc.. Die Audio-PLL auf dem uC ist auch nicht in der Lage exakt 48 kHz zu reproduzieren. Meine Idee war es jetzt, einfach mitzuzählen wie viel Datenpakete reinkommen, anhand dessen die "input-sample-rate" berechne und dann dynamisch die Audio-PLL anpasse. Ich frage mich nur, was ich mache, wenn ein UDP Paket mal nicht ankommt und wie ich dynamisch die korrekten PLL Einstellungen zurückrechnen kann. Bin ich mit meinem Ansatz auf dem Holzweg oder habt Ihr Ideen wie man so etwas lösen kann? Danke!
Bzw. welche Ansätze hat hier ein normaler Windows-PC, wenn man parallel mehrere Audio-Sourcen auf dem Windows-System am laufen hat (z.B. Webradio) die alle leicht unterschiedliche Samplerates haben, das ganze synchron auf den Audio-Ausgang rauszubekommen?
Engineer schrieb: > Meine Idee war es jetzt, einfach mitzuzählen wie viel Datenpakete > reinkommen, anhand dessen die "input-sample-rate" berechne und dann > dynamisch die Audio-PLL anpasse. Muss man so machen, wenn Quelle und Senke asynchron sind und nicht extern über Wordclock oder PTP versorgt werden. Kniffelig sind halt nur die Regelparameter der PLL, damit die nicht wilde Sprünge macht, hin- und hereiert oder bei Fehlern völlig austickt und trotzdem schnell eine ungefähre Schätzung der Zielfrequenz schafft. Hilft ja nichts, wenn man sich da erstmal eine halbe Stunde was zusammenmitteln muss. > Ich frage mich nur, was ich mache, wenn ein UDP Paket mal nicht ankommt > und wie ich dynamisch die korrekten PLL Einstellungen zurückrechnen > kann. Aus dem Grund haben andere AoIP-Protokolle (zB. das RTP von Ravenna/AES67) einen Sequenzzähler bzw. Timestamp. Dann weiss man, was man verpasst hat. > Bzw. welche Ansätze hat hier ein normaler Windows-PC, wenn man parallel > mehrere Audio-Sourcen auf dem Windows-System am laufen hat (z.B. > Webradio) die alle leicht unterschiedliche Samplerates haben, das > ganze synchron auf den Audio-Ausgang rauszubekommen? So synchron muss es da nicht wirklich sein. Man sollte nur langfristig Buffer-Under/Overflows vermeiden. Ganz simpel kann man da ab und zu Samples auslassen/verdoppeln (ist halt hörbar) oder man macht ein Resampling mit einer aufgrund der Bufferfüllstandsänderung geschätzten Samplerate. Das wäre das DSP-Äquivalent der Sampleraten-PLL (mit all ihren Herausforderungen), kostet halt Rechenpower.
Oder eine Buffer Lösung und wenn ein Sample fehlt ist ein "Plop" sowie so unvermeidbar... In der Regel sind ja auch im Paket mehrere Samples für einen Kanal enthalten und der Buffer ist ja schon vorhanden. Dein Zählen dient ja vornehmlich auch dazu zu vermeiden das der Buffer leer wird oder überläuft.
Engineer schrieb: > Bzw. welche Ansätze hat hier ein normaler Windows-PC, wenn man parallel > mehrere Audio-Sourcen auf dem Windows-System am laufen hat (z.B. > Webradio) die alle leicht unterschiedliche Samplerates haben, das ganze > synchron auf den Audio-Ausgang rauszubekommen? Das Problem ist auf Windows-Systemen das gleiche. Die müssen Senderate und Abspielrate auch aufeinander abstimmen. Zu diesem Zweck gibt es in der Windows-Audiotreiber-Architektur einen Rückkanal. Die Lowlevel-Hardware-Treiber, welche den Audio DAC befüllen, nutzen diesen Rückkanal und ändern die Datenrate jeweils minimal, sodass der DAC Sendebuffer immer ausreichend Samples enthält. Ich würde es in deinem Fall so ähnlich machen. Der UDP-Empfänger könnte zunächst seinen Ringspeicher halb befüllen, dann den Audio DAC mit 48kHz starten und den Ringspeicher Füllstand im Blick behalten und dann entspr. mehr oder weniger Datenrate anfordern. Datenverlust: Wenn die Datenpakete Sequenznummern haben, könntest du Datenverlust erkennen und notfalls das gleiche Sample nochmal abspielen - je nachdem wie lang so ein Sample ist. Oder du generierst dir ein Dummy-Sample, welches vom Endwert des letzten Samples zum Anfangswert des nächsten Samples rampt, um ein Plop zu vermeiden. Aber da gibt es vermutlich beliebig viele Strategien...
Oder: Falls dein Audio Stream ausreichend oft Pausen (Stille) enthält, könntest du dieses Wissen nutzen, und die PLL einfach frei laufen zu lassen und in den Ruhe Pausen enweder Daten wegwerfen oder stille UDP Pakete duplizieren.
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.