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

Florian K. OP #7383807
Lesenswert?
• ▲
▼

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 Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Sebastian W. #7383829
Lesenswert?
• ▲
▼

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 Beitrag melden
Wastl #7383842
Lesenswert?
• ▲
▼

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 Beitrag melden
Stefan F. Gast #7384027
Lesenswert?
• ▲
▼

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 Beitrag melden
Beitrag #7384061 wurde von einem Moderator gelöscht.
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren