ESP32 esp-idf tcp client empängt Daten Packet nicht immer vollständig

OP #7383807

Hallo,

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 ?

meine Socket Read Funktion

1
 
static int _snapcast_stream_socket_receive(const char *tag, const int sock, char * data, size_t max_len){

2
 
    int len = recv(sock, data, max_len, 0);

3
 
   // ESP_LOGI(tag, "[sock=%d]: MAX_LEN: %d", sock, max_len);

4
 
    if (len < 0) {

5
 
        if (errno == EINPROGRESS || errno == EAGAIN || errno == EWOULDBLOCK) {

6
 
            return 0;   // Not an error

7
 
        }

8
 
        if (errno == ENOTCONN) {

9
 
            ESP_LOGW(tag, "[sock=%d]: Connection closed", sock);

10
 
            return -2;  // Socket has been disconnected

11
 
        }

12
 
        log_socket_error(tag, sock, errno, "Error occurred during receiving");

13
 
        return -1;

14
 
    }

15
 


16
 
    return len;

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.

Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke

Kommen die Daten später im nächsten Paket an?

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.

Antwort Zitieren Bearbeiten Löschen Melden Danke

J. S. schrieb:

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."

LG, Sebastian

Antwort Zitieren Bearbeiten Löschen Melden Danke

Florian K. schrieb:

Ich dachte immer das TCP/IP eine Empfangsbestätigung hat und damit gewährleistet das Datenpackete vollständig ankommen ?

Bei einem Audio Stream braucht man TCP eigentlich nicht. Es geht ja nicht um absolut fehlerfreie bzw. vollständige Datenübertragung.

Versuche mal dein Glück mit UDP, dort bekommst du die Datenmenge als Paket übertragen die du dir wünschst, bis zur maximal möglichen (MTU).

Antwort Zitieren Bearbeiten Löschen Melden Danke

Ich Nutze zur zeit pcm Audio, ... und somit einfacher zu debugen ist.

Stimmt nicht :-)

Hättest du von Anfang an ein komprimiertes Format genommen, müsstet du in einer Schleife Bytes holen, bis du ein dekodierbares Paket zusammen hast.

Und das Problem wäre erst gar nicht entstanden.

Antwort Zitieren Bearbeiten Löschen Melden Danke
Gast

Florian K. schrieb:

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.

Antwort Zitieren Bearbeiten Löschen Melden Danke
Beitrag #7384061 wurde von einem Moderator gelöscht.
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 3 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.