wifi vs ethernet streaming

Soiko paremmin kun johto irti? Ehtiikö tekemään pikaisen vertailun 20 sekunnilla? Omassa katkeaa niin nopeasti että en pysty harmikseni tätä testiä toistamaan.
Pitäis pyytää vaimoa nappaamaan johdon, että voisi itse pysyä spotissa. -En kehtaa pyytää apua ja akustointitaulu neuvottelutkin ovat vielä kesken :)

(Edit: Niin ja tosiaan itse tykkään optisesta kaapelista DACciin, joka ainakin katkaisee pörinät jos sellaisia on tullakseen ethernettiä pitkin striimerille. Toki pitää luottaa sitten siihen, että valo vilkkuu striimerissä varmasti samalla lailla oli pörinöitä tahi ei siellä striimerin sisällä. ...Aina pitää olla jokin murehtimisen aihe, se pitää tämän hifistelyn kiinnostavana.)
 
Viimeksi muokattu:
Niin oliko meillä siis käytännön ongelmaa tämän lähiverkon ja pakettijitterin kanssa alun perinkään... Vai vain teoreettisiä mahdollisuuksia, jotka satunnaisesti voi sitten kuulua pienenä pätkäisynä/häiriönä äänessä.
 
Pakettien hukkumisessa. Jos telkkari tulee myös verkkoa pitkin eikä antennissa, niin joskus näkyy mosaiikkia. samalla tavalla se sitten jotenkin pätkii jotenkin audiosignaalissa. joku verkon kuormitusjuttu se on eikä liity wlaniin muuten, paitsi wlan tietenkin kuormittaa samaa kuituliitäntää. jos teen etätöitä läppärilla ja etenkin jos lataan fileitä. telkkari suoraan ethetnet boxin perässä mutta läppäri wlanilla. toisaalta ei ole tidaalin käyttöä häirinnyt, vaikka käytän sitä yleensä puhelimella tai tabletilla ja sitä. liitäntä on telian kuitu 100M mikä huusholliin tulee.
 
Niin oliko meillä siis käytännön ongelmaa tämän lähiverkon ja pakettijitterin kanssa alun perinkään... Vai vain teoreettisiä mahdollisuuksia, jotka satunnaisesti voi sitten kuulua pienenä pätkäisynä/häiriönä äänessä.
Hämmentyisin erittäin paljon jos olisi. Verkossa tai laitteistossa voi toki olla elektroniikan puolella suojausongelmaa, mutta pakettien jitterin kanssa ei tuolloinkaan asialla pitäisi olla tekemistä.
 
Pakettien hukkumisessa. Jos telkkari tulee myös verkkoa pitkin eikä antennissa, niin joskus näkyy mosaiikkia. samalla tavalla se sitten jotenkin pätkii jotenkin audiosignaalissa. joku verkon kuormitusjuttu se on eikä liity wlaniin muuten, paitsi wlan tietenkin kuormittaa samaa kuituliitäntää. jos teen etätöitä läppärilla ja etenkin jos lataan fileitä. telkkari suoraan ethetnet boxin perässä mutta läppäri wlanilla. toisaalta ei ole tidaalin käyttöä häirinnyt, vaikka käytän sitä yleensä puhelimella tai tabletilla ja sitä. liitäntä on telian kuitu 100M mikä huusholliin tulee.
jos puhumme samasta asiasta, niin tuo mosaiikki on ymmärtääkseni pääosin yhden ainoan bitin siirtovirhe. MPEG:n pakkausformaatti on ihan hemmetin tarkka siitä, että data siirtyy bitperfektinä internetistä toistimeen. Yhden bitin virhe näkyy MPEG:ssä sekuntikaupalla korruptoituneena blokkina, jos blokissa ei havaita mitään muutosta.

Jos taas viittaat viittaat resoluution alenemiseen, niin mosaiikki johtuu siitä, että soitin vaihtaa automaagisesti pienemmän bittivirran alempiresoluutioiseen striimiin, jotta toisto voi jatkua ilman pätkimistä. Tällöin ongelma on, että striimin puskuri uhkaa loppua, siirtokaistan loppuessa kesken, jolloin systeemi yrittää parjätä olemassa olevalla bandwithillä.
 
Eetterin pakettijitterillä ja esimerkiksi DACin kellohuojunnasta aiheutuvall jitterillä ei oikeastaan ole mitään tekemistä toistensa kanssa, eikä näitä ilmiöitä pitäisi lainkaan rinnastaa toisiinsa. Esimerkiksi TCP:nä siirrettävä data kootaan käytännössä aina erilliseen puskuriin ja jos puskuri hyytyy, ääni loppuu. Ethernetin pakettijitteri on olennaista lähinnä esimerkiksi nettipelaajille, joilla yli 50ms jitterarvot saattavat aiheuttaa kanssapelaajien hahmojen nykimistä yms. koska paketteja tulkitaan reaaliaikaisesti. Yleensä kaikkea netin yli siirrettäviä striimejä bufferoidaan jolloin jitteri ei käytännössä vaikuta mitenkään, paitsi jos se on ihan tähtitieteellinen, niin silloin ääni pätkii. Näissäkin tapauksissa fiksusti koodattu soitin lisää bufferin kokoa ( esim youtube tai netflix ) ja pyrkii näin estämään nuo lieveilmiöt. Spottari tuntuu luottavan siihen, että se pyrkii hakemaan koko biisin soittimelle niin nopeasti kuin pystyy joten se käytännössä bufferoi koko kappaleen ja yleensä myös alun seuraavasta biisistä.
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.
 
Puskuriaika vertailu Node 2 (100M liittymä, ethernet johdoilla kaikki kiinni); johto irroitettu n. 1-2 sek musan kuulumisesta

Tidal (CD taso 16/44.1) 34.19 sek
Tidal (Master MQA) 21.58 sek
Neil Young Archives palvelu (24/192) 14.76 sek
NAS (24/192 flac) 04.48 sek
NAS (16/44.1 flac) 22.15 sek
Linn Radio (44.1) n. 3 sek
Yle Radio 1 (48 khz) n. 15 sek

(edit: pari nettiradiota lisätty)
 
Viimeksi muokattu:
^^ Slave kellolla toimivat halppis dacit eivät ainakaan käsittele S/PDIF:n kautta saapuvan signaalin jitter ongelmia "mitenkään". Miten tämä sitten pitäisi ymmärtää yhdistää Ethernetin pakettiliikenteeseen jotenkin samana ilmiönä.
 
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.
 
Niin oliko meillä siis käytännön ongelmaa tämän lähiverkon ja pakettijitterin kanssa alun perinkään... Vai vain teoreettisiä mahdollisuuksia, jotka satunnaisesti voi sitten kuulua pienenä pätkäisynä/häiriönä äänessä.
Olen sitä mieltä, että jos verkko toimii niinkuin kuuluu, (ei hukkaile paketteja) niin ongelmaa ei ole kummassakaan. eikä eroja. ei ainakaan mun korviin. ja sama tuleeko data ensin kuitua ja sähköistä ethernettiä pitkin ns telian palvelureitittimeen ja siitä wlaniin tai piuhaa pitkin, vai suoraan esim 4g yhteyttä tukevaan värkkiin. ja siitä taas ethernetin yli tai wlanin yli joka systeemi toistaiseksi mökillä. ihan sama jos bitit kulkee pääsääntöisesti oikein. en huomaa eroja, tidal pääosin käytössä. daccien jitteritoteutuksissa taatusti on eroja mutten niihin ole perehtynyt, eikä huvitakkaan. saan töissä jittereistä ja erilaisista kellotustoteutuksista tietoliikennelaitteissa tarpeekseni...
 
Saako tosta tuon virranannon pois päältä? (poe toiminto) Eikös siinä ole toimintasavun vaara :unsure:
Ei saa, mutta en ole kokenut tuota ongelmaksi.
Siis kyllä tuo katkaisee datayhteyden, jos vastaanottopään laite on sammutettu.
 
Viimeksi muokattu:
Mulla on tuo yo. TP linkin kytkin käytössä. Vertailin sitä oikein raskassarjalaiseen mutta en saanut aikaan kuultavia eroja ( https://diabolusinhifi.com/2021/01/25/onko-ethernetkytkimilla-aanenlaadun-suhteen-valia/ )

Mulla Bluesound node 2i:n bufferi taisi olla jotain minuutin luokkaa. Anthem AVM60 hieman vähemmän.

Kyllä noilla puskureilla ehtii lähettää paketteja uusiksi jos tarvitsee, ja järjestellä jonoja.

Olen myös hieman pohtinut asioita:


 
^Tuossa muistaakseni oli myös sitä kokeilua, että jos striimerin puskurimuisti on riittävä, niin kannattaa kokeilla irrotella ja kytkeä takaisin kiinni ethernet johtoa laulun soidessa (tai pyytää kaveria). Oman Node 2:sen puskuriaikoja omassa setissä kokeilinkin vuoden vaihteessa tuonne hieman ylemmäksi. 30 sek luokkaa itselläni. Edestakaisin nyppimällä johtoa, ei havaitse mitään eroa missään.
 
^Tuossa muistaakseni oli myös sitä kokeilua, että jos striimerin puskurimuisti on riittävä, niin kannattaa kokeilla irrotella ja kytkeä takaisin kiinni ethernet johtoa laulun soidessa (tai pyytää kaveria). Oman Node 2:sen puskuriaikoja omassa setissä kokeilinkin vuoden vaihteessa tuonne hieman ylemmäksi. 30 sek luokkaa itselläni. Edestakaisin nyppimällä johtoa, ei havaitse mitään eroa missään.
Tämä kertoo vaan tilanteesta missä ongelma olisi jonkinlainen maalenkki tai muu sähköisestä kytkennästä johtuva häiriö. Kun data on jo puskurissa, niin se paha paha internetjitterärrimörri on jo aikaa sitten hiipinyt datastriimiin etsimään ne musikaalisuusbitit ja hakannut niiltä RFI-lekallaan noiden musikaalisuusbittien kanttiaallon kulmat pyöreiksi :eek:
 
Back
Ylös