Ich versuche einen Snapcast Client mit meinem ESP32-A1S Audio Dev Kit zu
bauen. Und stoße dabei auf ein Problem bei dem ich nicht mehr weiter komme.
Der Snapcast Server zerteilt den Audio Daten Strom vom Audioplayer in 20ms Stücke und sendet diese per tcp an den Client.
Das sind 3840 Bytes bei 48KHz Sample Frequenz und 16Bit Auflösung.
4Bytes für Rechts Links * 48000/50 = 3840Bytes (1 Sekunde / 20ms = 50).
Mein Problem ist das so ca. jedes 10te Datenpacket nicht vollständig von meinem
Client empfangen wird. Bzw. recv() nicht 3840 als gelesene Bytes zurück gibt.
Ich dachte immer das TCP/IP eine Empfangsbestätigung hat und damit gewährleistet
das Datenpackete vollständig ankommen ?
log_socket_error(tag,sock,errno,"Error occurred during receiving");
13
return-1;
14
}
15
16
returnlen;
17
}
ich habe die komplette c Datei mit Header im Anhang.
Ich Nutze zur zeit pcm Audio, da ich dort immer eine konstante Anzahl von Bytes gesendet bekomme und somit einfacher zu debugen ist. Später will ich auf flac oder opus als Decoder umsteigen.
Ethernet arbeitet mit Paketen bis zu 1497 Bytes (oder so ähnlich). TCP garantiert nur, dass die Bytes in der richtigen Reihenfolge ankommen, nicht aber dass dein Programm ein gesendetes Paket in einem recv() erhält.
Bei non blocking receive brauchst du eine Schleife die recv solange
aufruft bis alle Bytes angekommen sind.
Ich meine, solch eine Schleife braucht man immer, nicht nur bei non-blocking receive: "The receive calls normally return any data available, up to the requested amount, rather than waiting for receipt of the full amount requested."
Ich dachte immer das TCP/IP eine Empfangsbestätigung hat und damit
gewährleistet das Datenpackete vollständig ankommen ?
TCP ist ein Streaming Protokoll, nicht Paket-Orieniert. Es ist nur sicher gestellt, dass keine Bytes verloren gehen. Aber sie können den Empfänger in beliebiger Stückelung erreichen.
Wenn du Pakete mit fester Größe brauchst, musst du UDP nehmen. Das garantiert allerdings keine Lückenlose Übertragung, es wiederholt im Fehlerfall nicht automatisch.
Wenn man sich sein eigenes Protokoll entwickelt, weil man /beide Enden/ der Übertragung in der Hand hat, /dann/ kann UDP einem einiges an Nervkram abnehmen.
