Ich mache ein Projekt, bei dem ich einen MP3-Audiostream, den ich von einem Webserver empfange, mit einem pic32 über Ethernet dekodieren muss. Mein Zweifel ist:
Was ist, wenn der Server mehr Daten sendet, als das Bild verarbeiten kann? Ich meine, kann ich die Menge der Pakete kontrollieren, die der Server mir sendet? Denn wenn nur ein Gerät mit dem Internet verbunden ist, sendet der Server alle MP3-Songs ohne Wartezeit und der Bildspeicher reicht nicht aus.
Wie kann ich dieses Problem lösen?
Wenn Sie ein geeignetes Streaming-Protokoll wie RTSP verwenden, sendet der Server die Pakete mit der richtigen Rate.
UDP bietet keine Flusskontrolle. Wenn Sie dies benötigen, sollten Sie TCP-Verkehr verwenden ODER ein höheres Protokoll müsste die Flusskontrolle implementieren, aber einfaches HTTP bietet auch keine Flusskontrolle. Da die meisten dieser Datenströme entweder in Echtzeit oder auf TCP basieren, bezweifle ich, dass eines der höheren Protokolle eine Flusskontrolle implementiert hat. Meine Vermutung ist, dass Sie auf TCP umstellen müssen.
Wenn Sie den Server kontrollieren können, lassen Sie ihn die Daten mit der richtigen langfristigen Durchschnittsrate senden. Dann muss sich der PIC nur noch mit der Burstiness befassen. Mit einem ausreichend großen Puffer sollte alles funktionieren.
Die beiden Uhren werden jedoch zwangsläufig etwas daneben liegen. Der langfristige Durchschnitt von jedem sollte so gut sein wie sein Kristall. Um pessimistisch zu sein, gehen Sie von 50 ppm Kristallen an beiden Enden aus, planen Sie also eine langfristige Fehlanpassung von bis zu 100 ppm. Dies kann auf verschiedene Arten behandelt werden. Sie könnten einfach das letzte Sample bei Buffer Underrun replizieren und ein Sample bei Overrun überspringen, da theoretisch jedes ein relativ seltenes Ereignis sein wird. Oder Sie können die Wiedergabegeschwindigkeit basierend auf der Datenmenge im Puffer leicht ändern. Audio-Reinsten wird das nicht gefallen, aber es ist nicht anders als das Wackeln von Tonbandgeräten von vor langer Zeit. Unterhalb eines gewissen Niveaus ist alles noch gut genug. Wenn dieser Klang die Stimme ist, kann man mit viel mehr davonkommen, als wenn ein professioneller Musiker Musik hört.
In jedem Fall, nein, Sie möchten kein TCP verwenden. Das fügt dem PIC-Ende so viel Overhead hinzu, dass Sie möglicherweise überhaupt nicht in der Lage sind, den Audiostream zu verarbeiten. Eine zuverlässige Zustellung ist hier nicht erforderlich. Wenn es einen Fehler gibt, stört die Ausgabe, aber dann möchten Sie weitermachen und so schnell wie möglich normal weitermachen. TCP ist dafür nicht gut geeignet.
Benutzer207421
Jippie
Benutzer207421