Best egna ute på landet, ikkje anbefalt i bynære strøk (ref: https://www.bt.no/btmeninger/debatt/i/pqnm1/-Norge_-den-siste-kommuniststat)
Gjer også grunnlag for å kreve inn kringkastingsavgift.
http://www.ebay.com/itm/FM-transmitter-Digital-Radio-Station-0-5W-PLL-Stereo-for-wireless-audio-mp3-DVD-/181860101100

Én mottaker og høyttalere, Sonos, bluetooth e.l.

Nettradio har vel fort samme problem som dab med hw forsinkelse? 

Har nettradio samme forsinkelsesproblem? Det visste jeg ikke....
Jo, én mottaker og flere høyttalere burde funke, men problemet med de (f.eks. Sonos) ikke har en "skikkelig" sentral, med bra DAB, forsterker, innganger for platespiller, CD, samt utganger for AUX.

Trur eg..... Er det noen som kjenner noen som er bra?

Jet har Sonos. Set synkroniserer gods nok til at de unlike høyttalerene kan fungere sammen i 5.1 surroundlyd. Dvs perfekt sync

Hvis du har minijack inn på eksisterende anlegg/radio og strøm i nærheten kan vel også Chromecast audio (https://www.prisjakt.no/product.php?p=3341552) spille synkronisert på flere enheter?

Du kan jo sjekke med importørene for de forskjellige merkene, om det er forskjell i delay for produktene innen et merke. Ikke sikkert de bruker samme chip i en batteridrevet radio og en på 230v, men det er jo mulig de har standardisert latency likevel. Mulig keal kan bidra her?

Jeg har ikke noen konkrete opplysninger om spesifikke merker, dessverre. Det er en stund siden jeg plukket opp produktark på radiobrikker, men da var forsinkelsen aldri nevnt i de tekniske data. Jeg tviler på at det har kommet inn i dagens produktark - det er ikke noe som mange bekymerer seg om.

NÅr det gjelder produktene innen et merke: Stort sett bruker produsentene samme brikke (evt. et par ulike) i samtlige radioer de tilbyr. Forskjellen mellom modeller ligger i alt som er "utenpå" - forsterker, høyttaler, antenne osv. Iblant "kan" brikka en del ting som du bare får aktivert på de dyreste radiomodellene. Men selve radiomottaket og signalbehandlingen er oftest helt identisk på tvers av en drøss modeller.

Det som er helt sikkert: For DAB ligger all variasjon i forsinkelse i mottakeren. Signalet kommer fram til antenna eksakt synkronisert - det er helt nødvendig for at flere sendere skal kunne sende på samme frekvens; hver data-bit må starte eksakt samtidig, med mikrosekund-presisijon, fra alle sendere. Fordi to sendere har ulik avstand til en gitt mottaker, kan det hende at signal fra to sendere kommer fram ørlite ut av takt, så på begynneslen av biten har du bare en "1"-verdi fra den ene senderen, så kommer signalet fra den andre senderen og legger sin "1" bit på toppen. Mottakeren avleser biten litt ut i bit-perioden, når signalene fra alle senderne har nådd fram til radioens antenne, men her snakker vi om millisekunder og kortere forsinkelser.

For digitale prosessorer er strømforbruket svært avhenigig av hvilken klokkefrekvens prosessoren kjører. Jeg leste en omtale av en bærbar radio som på nettstrøm kjørte på høy klokkefrekvens, men på batteri satte ned frekvensen for å trekke mindre strøm, og det førte til at dekodingen gikk tregere, og lyden ble mer forsinket. Tror dessverre ikke jeg har bevart linken til den artikkelen.

Det ble overnfor spurt om nettradio: Der blir forholdet litt annet: Du har en varierende forsinkelse i nettet, avhengig av hvor mye kø det er på svitsjene, og hvilken vei datapakkene tar (i prinsipp kan hver eneste lille pakke velge sin egen rute gjennom nettet, f.eks. for å unngå steder med trafikkork). Pakkene kan komme fram hulter til bulter, særlig om de har gått ulike veier gjennom nettet.

Mottakeren - radio-appen - må ta høyde for en maksimum forsinkelse den vil handtere, og foreløpig legge mottatte pakker til side. Etterhvert som flere pakker kommer ramlende inn blir de plassert på rett sted i rekkefølgen, og hvis det fortsatt er hull i rekka når det begynner å bli kritisk (dvs. lyden skal snart spilles av), kan det blir nødvendig å be senderen sende en manglende pakke på nytt. (For de som er teknisk orienterte: Dette er det TCP-nivået som tar seg av, som brukes av radio-appen, det er ikke appen selv som gjør det.)

De fleste enkle radio-apper gir opp venting på manglende pakker etter en stund, og sender ut lyden, med hull der det eventuelt mangler pakker. Når det kommer nye pakker, blir de behandlet og sendt videre med omlag samme forsinkelse som før bruddet.

NRKs radio-app er noe mer fancy: Når den mister forbindelsen så den ikke har noe lyd å spille av, må det bli stille. Men den stopper også klokka: Når signalet kommer tilbake etter to minutters brudd, har du ikke mistet to minutter radiosending; lyden fortsetter fra der den slapp, men ligger nå to minutter etter direktesending. Appen ber likevel om å få tilsendt alt med det samme, helt fram til direktesending (å sende over to minutter lyd går vesentlig raskere enn å spille den av), så den har liggende to minutter med lyd klart ved neste brudd; du merker ikke at du da får lyd som allerede ligger i mobilen din. Hvis det andre bruddet er på 2:30, da vil du oppleve det som en 30 sek "utsettelse", så nå ligger du 2:30 bak direktesending, og kan tåle brudd opp til 2:30 uten å merke det. Hver gang du opplever et brudd på x sekunder, betyr det at det reelle bruddet var x sekunder lengre enn det lengste til nå. Appen kan handtere brudd på opptil en time, dersom de utsettelsene du har opplevd summerer seg opp til en time. Men da hører du også programmet en time forsinket!

Det er bare en liten hake ved det: Når du skifter kanal eller stenger appen, da tømmes denne bufferen. Så hvis du har hatt masse brudd på veien opp til hytta, men den siste halvtimen har du hatt perfekt mottak, så kan det hende den siste halvtimen har vært fullstendig uten signal, ren avspilling fra bufferen. Neste dag er nettradioen fullstendig død. Så selv om NRKs radio-app gjør underverker når signalet kommer og går, blir du lurt til å tro at signalforholdene er langt bedre enn de reelt er.

Og du må ikke finne på å stille klokka di etter radioprogrammene du hører via NRK-appen, særlig ikke hvis du har hatt den kjørende i lengre tid, med mange små brudd.

«...og det førte til at dekodingen gikk tregere, og lyden ble mer forsinket.

Hvis dekodingen går tregere, så vil bufferet med ikke-dekodet lyd vokse over alle grenser.

Nå vel... det krever kanskje litt større buffer. Prosessoren må jo uansett være i stand til å dekode datastrømmen i sann tid. På full hastighet (med høyt strømforbruk) har prosessoren mer kraft enn nødvendig, så den kunne f.eks. dekode et sekund lyd på et halvt sekund, og sende det med et halvt sekund forsinkelse til utgangen mens den tar seg en pause på et halvt sekund (eller gjør andre oppgaver).

Så halverer du klokkefrekvensen, og når tar det et fullt sekund å dekode det sekundet med lyd, og det sendes til utgangen med et helt sekunds forsinkelse. CPUen får ingen hvilepause før neste blokk, og får ikke gjort noe som helst annet arbeide, men den får all lyden ut, med litt større forsinkelse.

Dette er selvsagt en sterkt overforenklet beskrivelse, men illustrerer hovedpoenget. Man kan stille to spørsmål ved denne overforenklede modellen: For det første, hva i all verden skulle radioen gjøre i "hvilepausene"? Jeg vet ikke - det kunne være f.eks. at displayet oppdateres med høyere frekvens på høy prosessorhastighet. Kanskje brikka kan oppdatere kanallista i bakgrunnen. Det ligger masse ekstra-info i pakka som mottas; kanskje dette blir ignorert i batteri-modus. Jeg vet ikke.

For det andre: Når prosessoren tar seg hvilepauser, kunne den ikke da slå av strømmen på det aller meste av brikka, og spare strøm på den måten? Det er jo en teknikk som brukes i utstrakt grad i mobiltelefoner: Bare de deler av brikka som er i aktiv operasjon får spenning. Hele ideen med Bluetooth Low Energy er at brikkene ute i "dingsene" er aktive med faste intervaller, slik at de kan slå seg av så snart en melding er behandlet, og så slår de seg på før neste avtalte dialog-tidspunkt. Igjen: Jeg vet ikke. Det kan f.eks. være langt mere strøm å spare på å sette ned frekvensen, at halve frekvensen gir tredelen av strømforbruket.

Et punkt jeg glemte å nevne i det forrige innlegget - en annen kilde til forsinkelse (spesielt i nettradio):

I analog-alderen behandlet mottakeren signalet nærmest en bølgetopp av gangen, dvs. helt umiddelbart. I digital kommunikasjon er data samlet i datapakker av en viss størrelse. Det er alltid en del administrasjon med en slik pakke, som avsender/mottaker-adresse, indikering av type innhold, sekvensnummer etc. etc. En IPv6-pakke har minimum 40 bytes administrasjon. Så legger TCP på en del til, og radio-appen har sine data - kanal etc. Regn med at for hver pakke går det bort minst 60-80 bytes. Du foretrekker derfor å bruke få og store pakker, ikke knøttsmå pakker det all plassen brukes til administrasjon.

En typisk IP pakkestørrelse kan være i området 1000 bytes lyd, med administrasjonsdata i tillegg. Når NRK sender AAC+ kodet lyd på 80 kbps, 10 kbyte/sek, da må det samles opp 100 millisekunder lyd før pakken er klar til å sendes av gårde. Komprimeres lyden mer, f.eks. NRK Vær på 40 kbps, må pakken vente i 200 ms før den er full, og kan sendes. Så sendes hele blokka ut, en byte av gangen; tiden dette tar avhenger av hastigheten på nettforbindelsen. Bytene mottas, en etter en, og alle må komme fram før radio-appen kan begynne å dekode lyden.

Hvis senderen vil spare kapasitet til adminstrasjon (og behov for prosessorkraft) ved å bruke større pakker, f.eks. 32 kbytes, da må det samles opp mer enn tre sekunder lyd før pakken er full og kan sendes. Legg merke til at her hjelper det ikke med verken hurtigere linjer eller kraftig prosessor - det man venter på er at det skal komme nok lyd fra mikrofonen! I praksis kan man ikke bruke så store pakker som 32 kbytes, selv om det teknisk sett er mulig.

Dette er særlig fremtredende i Internett, som slett ikke er desginet for sanntidsdata. Men også DAB-lyd sendes blokkvis, og du har en viss grad av samme effekt.

For enveis-trafikk gjør det egentlig ikke så mye (bortsett fra at tidssignalet forsvant fra radioen da Norkring gikk over til digitale matelinjer til senderne; det var ikke meningsfylt lenger). For toveis-trafikk, som telefonsamtaler, fungerer det adkskillig dårligere: Når du samler opp 1/10 sek tale før du overhodet begynner å tenke på å sende det ut, da blir det til at folk snakker mye mer i munnen på hverandre, fordi de ikke vet at motparten allerede har begynt å si noe, som enda ikke har kommet fram. Dette er en av de mest alvorlige kvalitetstapene da vi gikk fra ISDN til IP-telefoni. ... Ja, dette er "praktisk sett" et helt annet problem enn at to ulike radioer ikke er synkrone, men den underliggende årsaken er den samme som én av elementene som gir forsinkelse i DAB og nettradio.

Keal: Imponerende utfyllende og utrolig kunnskapsrikt!
Men: hva i all verden gjør jeg i mitt praktiske liv? Eneste løsningen jeg nå finner på, er å strekke kabler fra hovedanlegget i stua til et sett høyttalere på kjøkkenet. Men det er da en lite ønskelig løsning med strekking av kabler etc.
Eller akkurat samme DAB-anlegg i alle rom vel(?), men det blir dyrt og uhensiktsmessig.