wifi vs ethernet streaming

No siis tietysti se virtalähde on sähköverkon kautta kiinni. Luulisi, että esimerkiksi ledilamppu tai jääkaappi toisi sähköverkkoon huomattavasti enemmän häiriöitä kuin kytkimen virtalähde. Ja jos virtalähteen häiriöt verkkovirrassa pelottaa, niin eikös se sitten kannata kytkeä se meluisa kytkimen virtalähde johonkin muuhun töpseliin kuin siihen niiden herkkien hifilaitteiden viereen?
Hyvinkin mahdollista että ledilamput ja jääkaappi aiheuttavat häiriöitä sähköverkkoon. Ilman jääkaappia on vaan hankalampi elää tänä päivänä joten pidettäköön sitä vakiona joka ei muutu. Onhan mm. SMPS vs Linear PSU aiheesta keskusteluja netti pullollaan, myös mm. ASR:ssä. Olen pohtinut josko tilaisi eBaystä jonkun lineaarisen PSU:n testiin, mutta itsellä olisi tarve sekä 5V että 12V lähdöille samasta laatikosta, tehoakin pitäisi olla sen verran että QNAP NAS pyörii sen kanssa. Kyllähän tuollaisia ratkaisuja löytyy, mutten ole vielä lähtenyt testailemaan. Päädyin siirtämään NAS:n kokonaan eri huoneeseen enkä huomannut mitään eroa äänenlaadussa verrattuna siihen että NAS oli laitetasolla ja suoraan Chordin kytkimessä kiinni.
 
Sain äsken aikaan sellaisen häiriön tuon noden kanssa ,että luulin että se taival oli siinä :unsure: Nappasin Diana Krallin levyn soimaa qubuzzissa, niin ääni särisi ja ritisi verkkopiuhan valon tahtiin ---oli siis piuhalla kiinni verkkokytkimessä. Otin piuhan irti ja wifillä yhteys ja ongelma hävisi..... En tiedä on tämä samaa vikaa mitä on ajoittain esiintynyt Qubuzzilla hires tavaralla , toinen genelec vilkuttaa punaista lediä ajoittain--kertoo ilmeisesti signaali ongelmasta?. Oli aiemmin tänään tuota vilkutusta ja kokeilin myös deezerin kautta samaa biisiä ,niin ei vilkuta. En myöskään ole huomannut ,että tv:n äänillä tuota olisi.
Annan nyt olla wifillä ja seuraan tilannetta.
Qubuz ja cd laatu niin ei ole ollut vilkutusta
 
Sain äsken aikaan sellaisen häiriön tuon noden kanssa ,että luulin että se taival oli siinä :unsure: Nappasin Diana Krallin levyn soimaa qubuzzissa, niin ääni särisi ja ritisi verkkopiuhan valon tahtiin ---oli siis piuhalla kiinni verkkokytkimessä. Otin piuhan irti ja wifillä yhteys ja ongelma hävisi..... En tiedä on tämä samaa vikaa mitä on ajoittain esiintynyt Qubuzzilla hires tavaralla , toinen genelec vilkuttaa punaista lediä ajoittain--kertoo ilmeisesti signaali ongelmasta?. Oli aiemmin tänään tuota vilkutusta ja kokeilin myös deezerin kautta samaa biisiä ,niin ei vilkuta. En myöskään ole huomannut ,että tv:n äänillä tuota olisi.
Annan nyt olla wifillä ja seuraan tilannetta.
Qubuz ja cd laatu niin ei ole ollut vilkutusta

Voipi olla johdossa vikaa vai oletko kokeillut muulla kaapelilla?
 
En ole kokeillut ja tuo verkkokytkin epäilyttää? On alta 20€ ja useamman vuoden vanha
 
Nad C658 on ollut minulla sekä ethernet-kaapelilla että wifissä DNA:n valokuitu plus-modeemissa, 400 Mbit/s.
Olen kokeillut kokeillut kumpaakin liityntävaihtoehtoa sekä 2,4 Ghz:n että 5 Ghz:n wifi-vaihtoehtoja. Äänenlaadussa ei eroja. Eroja on kuitenkin siinä, kuinka nopeasti ja sujuvasti esim. Tidal Connect kytkeytyy ja toimii. Wifillä toiminnot jotenkin sulavampia streemer sovelluksien käytössä. Joten Wifi nyt käytössä.
 
Aika jännä. Jos toimii wlanilla paremmin, niin semmoistahan se sitten kannattaa käyttää. Ihan mielenkiinnosta, ,minkälaista viivettä wifi ja genelec tarjoavat? Siis ei korvinkuultavaa, vaan lukeeko jossain millisekunnit?
 
Aika jännä. Jos toimii wlanilla paremmin, niin semmoistahan se sitten kannattaa käyttää. Ihan mielenkiinnosta, ,minkälaista viivettä wifi ja genelec tarjoavat? Siis ei korvinkuultavaa, vaan lukeeko jossain millisekunnit?
Soitettavien kappaleiden keskeytys/toisen käynnistäminen toimii ripeämmin wifissä. Myös kun vaihdan Tidalin Apple Musiciin, löytyy Nadi nopeammin wifissä. Tuntuma on tämä.
 
Aika jännä. Jos toimii wlanilla paremmin, niin semmoistahan se sitten kannattaa käyttää. Ihan mielenkiinnosta, ,minkälaista viivettä wifi ja genelec tarjoavat? Siis ei korvinkuultavaa, vaan lukeeko jossain millisekunnit?
Yleisesti ottaen Wifin latenssit ovat alle 5ms ja eetterin alle 1ms, siis jos puhutaan rautatasosta. Sitten siellä voi olla vaikka kuinka paljon softaa välissä, jonka tuottama latenssi on sitten eri asia. Tuohon vaikuttaa niin monet eri asiat, että pelkästään vetämällä johtopäätöksiä Wifi vs Ethernet arvioidaan aika epärelevantteja asioita.

Käytännössä rautatason latenssierot on niin pieniä, että niitä ei ihmisaistein havaita. Jotta saa jotain kontekstia, niin käyttöliittymäsuunnittelussa alle 200ms latensseja pidetään käytännössä välittöminä ja esimerkiksi pikajuoksioiden varaslähdöt tuomitaan, siten että jos juoksija irtoaa lähtötelineistä alle 100ms päästä lähtölaukauksesta, on kyseessä varaslähtö.

Toki siis jompi kumpi voi olla ihan mitattavasti nopeampi, mutta yleisiä johtopäätöksiä wifin ja ethernetin välille on aika turha vetää. Ne pätevät ainostaan samaan rauta- ja softakomboon, jossa on mukana laitteiden lisäksi myös käytetty verkko.
 
Noden tapauksessa tuolla viiveellä ei ole mitään käytännön merkitystä puskurimuistin vuoksi. Mutta mahdolliset häiriöt mietityttää
 
Niin, siis paljonko se tarjoaa viivettä puskurimuisteineen. Wlan tuppaa lisäämään jonkin verran jitteriä äänen lähetykseen jota vastaan sitten taistellaan bufferoinnilla. Bufferointi taas sitten lisätään jälleen viivettä toistoon. Wlan toisto voi sitten vaihdella onko kyseessä nykyaikainen wlan 6 kytkin, vai joku vanha wlan 3 räähkä. En sano, että haittaa siitä puskuroinnista olisi, mutta ihan mielenkiinnosta vaan kyselin, että minkälaisen viiveen on genelec/node siihen laittanut...jos se jossain lukee. varmaan jotain 10-50ms se on...?
 
Niin, siis paljonko se tarjoaa viivettä puskurimuisteineen. Wlan tuppaa lisäämään jonkin verran jitteriä äänen lähetykseen jota vastaan sitten taistellaan bufferoinnilla. Bufferointi taas sitten lisätään jälleen viivettä toistoon. Wlan toisto voi sitten vaihdella onko kyseessä nykyaikainen wlan 6 kytkin, vai joku vanha wlan 3 räähkä. En sano, että haittaa siitä puskuroinnista olisi, mutta ihan mielenkiinnosta vaan kyselin, että minkälaisen viiveen on genelec/node siihen laittanut...jos se jossain lukee. varmaan jotain 10-50ms se on...?
En kyllä ihan heti keksi millä mekanismilla jitter olisi mitenkään relevanttia UDP:llä tai TCP:llä. Jos se data jonkun kytkimen kautta menee, niin se pilkotaan kuitenkin joko TCP- tai UDP-paketeiksi, jossa kello pitää koota joka tapauksessa uudestaan vastaanottavassa päässä. Näin ollen oman ymmärryksen mukaan jitteriä voi syntyä ainoastaan vastaanottavassa päässä kun data kootaan uudestaan nippuun, jolloin softa on jo autuaan tietämätön siitä, onko data tullut eetteriä vai WLANia pitkin. Vai onko tässä nyt jotain mitä en hoksaa? Tuo 10-50ms puskuri kuulostaa omaan korvaan todella lyhyeltä, koska käytännössä 10ms puskurilla yhden paketin hukkuminen matkalle aiheuttaisi todennäköisesti jo framen korruptoitumisen ainakin wlanilla. Vai siis puhutaanko tässä jostain kustomratkaisusta, jossa muodostetaan erillinen verkko kahden laitteen välille? Tuossa tapauksessa nuo aiemmin heittämäni latenssit ovat röyhkeästi yläkanttiin, koska TCP/IP-arkkitehtuuria ei tarvitse pyöritellä siinä välissä.
 
Mikäs väliä tuolla mahdollisella viiveellä on pelkän äänen kuuntelun kannalta, pääasia että kuuluu ilman pätkimistä ja rätinää
 
Tuo 10-50ms puskuri kuulostaa omaan korvaan todella lyhyeltä, koska käytännössä ...
Sen enempää aiheeseen kantaa ottamatta, tuossa ei kyllä puhuttu 10-50ms puskurista vaan puskuroinnin aiheuttamasta viiveestä jolla ei ole mitään tekemistä puskurin koon kanssa. Tai saattaisi olla jos data kulkisi verkossa samaa nopeutta kuin mitä sitä toistetaan, mutta tämä on aika harvoin asian laita.
 
Sen enempää aiheeseen kantaa ottamatta, tuossa ei kyllä puhuttu 10-50ms puskurista vaan puskuroinnin aiheuttamasta viiveestä jolla ei ole mitään tekemistä puskurin koon kanssa. Tai saattaisi olla jos data kulkisi verkossa samaa nopeutta kuin mitä sitä toistetaan, mutta tämä on aika harvoin asian laita.
Ah Ok. Itselle puskuri kun on käytännössä aina kiinteän kokoinen, enkä kyllä keksi miksi varsinainen puskurointi aiheuttaisi mitään viivettä paitsi siis sen puskurin koon verran. Varsinaiseen puskuriin kirjoittamiseen ja sieltä lukemiseen kuluva aika kun lasketaan nanosekunneissa. Siis jos nyt puhutaan ihan normaaleista datapuskureista. Tässä tosin taitaa ongelmana olla, että en nyt taida olla ihan kartalla mistä me edes puhutaan ja yritän nyt soveltaa normaaleja bittitason oppeja, johonkin spesifiin hifi-implementaatioon, jossa vaan käytetään samoja termejä. Kyselen siis koska aihe kiinnostaa. Noissa on viimeisen viiden vuoden aikana kuitenkin tapahtunut aika paljon asioita ja on aina mukava päivittää ymmärrystään laitteiden toiminnasta.
 
Mikäs väliä tuolla mahdollisella viiveellä on pelkän äänen kuuntelun kannalta, pääasia että kuuluu ilman pätkimistä ja rätinää
No tämä on tietysti totta. Tämä on lähinnä tätä insinöörionaniointia, jossa poraudutaan laitteiden sielunelämään Käyttäjän kannaltahan tuolla ei ole mitään merkitystä.
 
Tekevisioni on LG Oled C8. Kun katson Netflix sovelluksen Tarkasta verkko-kohdasta verkon nopeuden tv:n ollessa Ethernet-kaapelilla kytkettynä on nopeus 94 Mbit/s. Wifiin kytkettynä 260 Mbit/s. Juuri testasin.
Jotenkin tuntuu, että näissä koti-tason laitteissa Ethernet-liitäntään ei ole laitettu paukkuja. Valmistajat olettavat, että wifi on se juttu jolla verkkoon liitytään? Vai voiko kyse olla DNA Valokuitu plus modeemini ethernet-asetuksista?
 
Viimeksi muokattu:
Tekevisioni on LG Oled C8. Kun katson Netflix sovelluksen Tarkasta verkko-kohdasta verkon nopeuden tv:n ollessa Ethernet-kaapelilla kytkettynä on nopeus 94 Mbit/s. Wifiin kytkettynä 260 Mbit/s. Juuri testasin.
Nopeus mihin? Kuulostaa ihan siltä että sulla olisi 100Mbps kytkin jossain välissä.
 
Mulla on sony tv 2015 vm ja sen nopeus langalla on tuo 100Mbps... Kytkimen valoista päätellen ja ps4 :lla palaa nopeampi ledi
 
En kyllä ihan heti keksi millä mekanismilla jitter olisi mitenkään relevanttia UDP:llä tai TCP:llä. Jos se data jonkun kytkimen kautta menee, niin se pilkotaan kuitenkin joko TCP- tai UDP-paketeiksi, jossa kello pitää koota joka tapauksessa uudestaan vastaanottavassa päässä. Näin ollen oman ymmärryksen mukaan jitteriä voi syntyä ainoastaan vastaanottavassa päässä kun data kootaan uudestaan nippuun, jolloin softa on jo autuaan tietämätön siitä, onko data tullut eetteriä vai WLANia pitkin. Vai onko tässä nyt jotain mitä en hoksaa? Tuo 10-50ms puskuri kuulostaa omaan korvaan todella lyhyeltä, koska käytännössä 10ms puskurilla yhden paketin hukkuminen matkalle aiheuttaisi todennäköisesti jo framen korruptoitumisen ainakin wlanilla. Vai siis puhutaanko tässä jostain kustomratkaisusta, jossa muodostetaan erillinen verkko kahden laitteen välille? Tuossa tapauksessa nuo aiemmin heittämäni latenssit ovat röyhkeästi yläkanttiin, koska TCP/IP-arkkitehtuuria ei tarvitse pyöritellä siinä välissä.

Jitteriä on langattomassa verkossa enemmän kuin langallisesssa, mutta sillä ei ole juurikaan vaikutusmekanismia DA-muuntimen jitteriin, koska siinä on se bufferointi välissä, mistä itsekin tuossa oletettavasti kerrot. Jitter on yleistermi jota satuin nyt vaan käyttämään tässä kontekstissa. Korkeammasta lähetystavan jitteristä johtuen yleensä pitää bufferia vähän lisätä, että se pakettien vastaanoton pieni ajallinen epävarmuus hukkuu siihen bufferiin. Tämä asia vaan kiinnostaa mua, että millaisella bufferilla (latenssilla) asiat toimii wlanin yli. Ei teoriassa, vaan käytännössä.

Kyse on siis siitä, että olisi vaan mukava tietää, että minkälaisilla buffereilla wlanin yli noi kaupalliset tuotteet dataansa puskevat live-stream käytössä. Kyse ei ole mistään, että onko joku asia nyt huono tai hyvä tai tarpeeksi lyhyt tai pitkä. Tällä asialla on vaan mulle merkitystä, kun teen tuota omaakin AoIP systeemiä ja siksi kysyin.
 
Viimeksi muokattu:
Back
Ylös