Ha simán helyi hálón (akár drótos wifin, akár drótnélküli kábelen) nyitsz egy TCP streamet és random teszed bele a két oldalán adatot, akkor az tapasztalat szerint nem fog leszakadni órákig vagy napokig se. Előfordul, de ritka mint a fehér holló, ha nem szar a hálózatod.
A késleltetésben van egy kis ingadozás. Real time lejátszás esetén egy túl nagy késleltetésből pattanás lehet, ez tény. Ezért kell nagyobb puffert beállítani, mint amennyi ingadozás jó eséllyel előfordulhat. Ha egy házibulin egyszer pattan a hang, akkor nem lenne egy rossz szavam se, de nálam percenként több jön (és függ az egyéb wifi terheléstől, az érezhető), az már durva.
Van még egy nagyobb baj is! A két oldalnak nem egyformán jár az órája! A két hangkártya kvarcja vezérli a hangminták tempóját, ez azért elég pontos, és egy rövid lejátszásnál talán nem okoz galibát. De ha hosszú ideig él a kapocsolat, akkor abból baj lehet. Ha belegondolsz, akkor egészen kis szisztematikus tempó eltérés esetén is a vételi oldal puffere lerövidül, vagy túlcsordul. Sokat gondolkodtam ezen a problémán, szerintem csak úgy lehet jól megoldani, hogy a vételi oldal újramintavételez, és egy kicsit lassabban, vagy kicsit gyorsabban játssza le a mintákat úgy, hogy a usert még ne zavarja a tempó ingadozása, de a pufferét fix hosszon tartsa.
A vicc az, hogy ezt a problémát egy másik projektben egyszer már leprogramoztam és meg lehet csinálni jóra (ssh felett is működött egész megbízhtóan), csak végig kell gondolni és kezelni kell ezt a két issuet. Nem tudom még, hogy mit csinál a pulse odabenn, de az, hogy nincs bufferméret paramétere, az baljóslatú.