Ilmiö sinänsä on sama ja myös tavat mitigoida ongelmia ovat samoja. Jos ymmärrät jitterin yhdessä ympäristössä niin ymmärrät sen ehkä myös toisessa.
On streamipalveluille järkevää viilata ainakin omat clientit fiksuiksi pakettien bufferoinnin kannalta ja varmasti clientit menevät parempaan suuntaan jatkuvasti. Itse streamereissä clienttit on toteutettu sen vendorin omalla ratkaisulla ja ne eivät välttämättä ole samalla tasolla kuin streamipalveluie omat clientit. Olisi loistavaa kuulla kauanko mikäkin streameri jatkaa soittoa sen jälkeen, kun yhdet katkeaa. On toki kiinni myös yhteysnopeuksista jne. Ehkä samalla avautuisi, onko valmistajien ja palveluiden välillä eroja, toimiiko esim node paremmin tidalin kuin spotifyn kanssa.
No Dacin kellon jitteriä, ei kyllä mitenkään pystytä mitigoimaan puskurilla. Jos deltasigma-muunnoksessa on jitteristä aiheutuva aikavirhe, niin sitä ei kyllä pelasta mikään. Digimaailmassa on monenlaista huojuntaa, mutta kaikki huojunta ei suinkaan ole ongelmallista tai verrannollista toisen tyyppiseen huojuntaan.
Toisaalta, esimerkiksi TCP/UDP-liikenne on lähtökohtaisesti OS:n tarjoama palvelu. Tietysti joukossa on aina niitä valmistajia, jotka kuvittelevat tietävänsä paremmin, mutta yleensä noissakin käytetään TCP:n tai UDP:n osalta ihan valmiita ohjelmistokomponentteja. Toki on aina mahdollista, että valmistaja saa päähänsä koodata kaiken pitkästä puusta, mutta tuollaisia kötöstyksiä välttäisin ihan vaan jo valmiiksi, koska jos joku softan kehittäjä on niin idiootti, että kuvittelee tekevänsä geneerisiä kirjastoja paremman ratkaisun samalla kun koodaa loppukäyttiksen, niin tuo kertoo kyllä varsin paljon myös koodaajan osaamisesta.
Harva tuntuu ymmärtävän, että 99% valmiisiin standardeihin perustuvista laitteista perustuvat joko piirivalmistajan, käyttöjärjestelmätoimittajan (esim. linux) tai standardikirjaston tuottamiin toteutuksiin. En esimerkiksi muista milloin viimeksi olisi tullut ohjelmistopuolella vastaaan tilanne, että joku olisi ihan vartavasten lähtenyt kirjoittamaan TCP/IP protokollaa nollista. Siinä ei oikeen ole mitään järkeä. Mitä taas tulee puskurointeihin, niin nuo taas ovat aika usein ihan olennainen osa OS:n audio interface palveluita. Esimerkiksi linux-maailmassa tutulla ALSA:lla homma tapahtuu muistaakseni yhdellä ainoalla komennolla. Se koodaako tuon clientin palvelun tuottanut firma vai ei ( yleensä ei, koska palvelutuottajien core-kompetenssiin ei kuulu client-OS-kohtainen osaaminen, jolloin työ teetetään alihankkijalla ), ei ole mitään väliä.
Koodaaminen ei ole mitään salatiedettä, jossa yhdellä osapuolella olisi jotain mystismaagista osaamista omasta palvelustaan. Itsekin olen ollut joko toteuttamassa tai johtamassa lukuisia ohjelmistoprojekteja, joissa palveluntarjoja on ostanut alihankintana ohjelmiston, joka käyttää palveluita, eikä kertaakaan palveluntarjoajalta ole tullut mitään "sisäpiiritietoa". Palveluntarjoajan agendalla on, että palvelun käyttö olisi mahdollisimman helppoa, joka tarkoittaa että dokumentaatio on yleensä helkkarin tarkkaan tehty. Jos ei ole, niin sitten jää herkästi valmistajilta tuki uupumaan. Yleensä homma itseasiassa menee niin päin, että me alihankkijana olemme antaneet suosituksia ja ohjeistuksia sen osalta, miten palveluntarjoajan kannattaa omaa ohjelmistokomponenttiaan muuttaa, jotta siihen olisi mahdollisimman helppoa ja suoraviivaista tuottaa palvelua käyttävää ohjelmisto. Ja monesti palveluntarjoaja on kiittänyt palautteesta ja korjannut omaa päätään noudattamaan annettua ohjeistusta.