Ich versuche, einen Speex Voip Client und Server zu erstellen. Ich habe die Grundlagen und funktioniert auf dem lokalen Rechner über UDP. Ich benutze JSpeex für die Portabilität. Ich suche nach Tipps zur Erstellung des Clients und Servers. Was sind deine Gedanken?
Die JSpeex-Bibliothek kann nur 320 Bytes pro Aufruf codieren, so dass die an den Server gesendeten Pakete winzig sind (in meinem Fall ~ 244 Bytes). Wäre es besser, wenn der Client wartet, bis etwa 1 oder 2 KB codierte Daten vor dem Senden bereit sind, oder der Server die Pakete puffern lässt?
Außerdem wäre jede Hilfe zur Pufferung der Daten sinnvoll.
Einige von dem, was ich habe, funktioniert auf dem lokalen Rechner.
Kunde:
Server:
Ich arbeite an einem ähnlichen Projekt. Nach allem, was ich gelesen habe, und persönlicher Erfahrung ist es die beste Option, mit kleinen Datenmengen zu arbeiten und sie so schnell wie möglich zu senden. Sie möchten, dass Jitter-Pufferung auf der Seite des Empfängers durchgeführt wird.
Es ist typisch für eine VoIP-Anwendung, 50-100 Pakete pro Sekunde zu senden. Für eine uLaw-Codierung bei 8000 Hz würde dies zu einer Paketgröße von 80 bis 160 Bytes führen. Der Grund dafür ist, dass einige Pakete unweigerlich fallen gelassen werden und Sie möchten, dass der Einfluss auf den Empfänger so gering wie möglich ist. Bei 10ms oder 20ms Audiodaten pro Paket kann also ein verlorenes Paket zu einem kleinen Schluckauf führen, aber nicht annähernd so schlimm wie der Verlust von 2k Audiodaten (~ 250ms).
Außerdem müssen Sie bei einer großen Paketgröße alle Daten beim Absender sammeln, bevor Sie sie senden. Bei einer typischen Netzwerklatenz von 50 ms mit 20 ms Audiodaten pro Paket wird der Empfänger nicht hören, was der Sender für mindestens 70 ms sagt. Stellen Sie sich vor, was passiert, wenn 250ms Audio gleichzeitig gesendet werden. Zwischen Sender sprechendem und Empfänger, der dieses Audio spielt, werden 270 ms verstreichen.
Die Benutzer scheinen hier und da den Verlust von Paketen zu verzeihen, was zu einer unterdurchschnittlichen Audioqualität führt, weil die Audioqualität der meisten Telefone nicht besonders gut ist. Die Benutzer sind jedoch auch an eine sehr niedrige Latenzzeit bei modernen Telefonschaltungen gewöhnt, so dass die Einführung einer Umlaufverzögerung von sogar 250 ms extrem frustrierend sein kann.
Nun, was die Pufferung angeht, habe ich eine gute Strategie gefunden, eine Queue zu verwenden (Whoops mit .NET hier :)), und dann diese in eine Klasse einzubinden, die die gewünschte minimale und maximale Anzahl von Paketen verfolgt die Warteschlange Verwenden Sie strenge Sperren, da Sie höchstwahrscheinlich von mehreren Threads darauf zugreifen werden. Wenn die Warteschlange "untergeht" und null Pakete enthält (Puffer-Unterlauf), setzen Sie ein Flag und geben Sie null zurück, bis die Paketanzahl Ihr gewünschtes Minimum erreicht. Ihr Consumer muss überprüfen, ob null zurückgegeben wird, und nichts in den Ausgabepuffer einreihen. Alternativ könnte der Benutzer das letzte Paket verfolgen und es wiederholt in die Warteschlange stellen, was zu Audio-Schleifen führen kann. In einigen Fällen klingt dies jedoch besser als Stille. Sie müssen dies tun, bis der Produzent genug Pakete in die Warteschlange legt, um das Minimum zu erreichen. Dies führt zu einer längeren Ruhezeit für den Benutzer, die jedoch im Allgemeinen besser akzeptiert wird als kurze, häufige Perioden der Stille (Funkstille). Wenn Sie einen Burst von Paketen erhalten und der Producer die Warteschlange füllt (das gewünschte Maximum erreicht), können Sie entweder die neuen Pakete ignorieren oder genug Pakete aus dem Anfang der Warteschlange löschen, um zum Minimum zurückzukehren.
>Das Auswählen dieser Min / Max-Werte ist jedoch schwierig. Sie versuchen, fließendes Audio (keine Unterschreitungen) mit minimaler Latenz zwischen Sender und Empfänger auszugleichen. VoIP macht Spaß, aber es kann frustrierend sein! Viel Glück!