Multi-rum lyd på Android: Opsætning og synkronisering

Hvad multi-rum faktisk betyder

Multi-rum lyd er at afspille den samme musik gennem højttalere i forskellige rum på samme tid. Gå fra køkkenet til stuen og sangen fortsætter problemfrit. Ingen huller, intet ekko, ingen mærkelig forsinkelse mellem rum.

Det er løftet. Enhver højttalerproducent sætter det på kassen. Og inden for et enkelt økosystem — Sonos, Apple, Google — virker det for det meste. Problemerne starter når du har højttalere fra forskellige producenter, hvilket dybest set er alle.

Den reelle definition af multi-rum er ikke bare “samme sang flere steder.” Det er synkroniseret afspilning — lyd der ankommer til dine ører fra forskellige højttalere inden for få tiendedele af et millisekund af hinanden. Hvis to højttalere er mere end cirka 50ms fra hinanden, hører du det. Ikke som et ekko, men som en udtværing, en tykkelse i lyden der får den til at føles forkert. Under 30ms kan de fleste mennesker ikke mærke forskellen. Det er målet.

Synkroniseringsproblemet

Her er hvorfor synkroniseret afspilning på tværs af forskellige enheder er genuint svært.

Når du trykker play, sker en kæde af hændelser: appen sender en kommando over WiFi til højttaleren, højttaleren modtager den, bufferer nogle lyddata, behandler dem gennem sin DAC, og lyd kommer ud. Hvert trin tager tid, og hver enhed tager forskellig tid.

En Chromecast kan tage 800ms fra play-kommando til første lyd. En Denon-receiver kan tage 200ms. En SoundTouch-højttaler ligger et sted omkring 150ms. Din telefons hovedtelefonstik? Under 10ms. Hvis du sender play-kommandoen til alle fire enheder på samme tidspunkt, kommer lyd ud af din telefon næsten med det samme, Denon’en en femtedel af et sekund senere, SoundTouch’en derefter, og Chromecast’en næsten et helt sekund efter du trykkede play.

Det er bare opstart. Når enhederne afspiller, driver de fra hinanden. Netværksjitter tilføjer et par millisekunders tilfældighed til enhver kommando. Interne ure er ikke perfekt synkroniserede — en højttaler der kører ved 44.099,8 Hz i stedet for 44.100 Hz vil drifte med cirka 150ms over en time. Nogle enheder pauser kort under WiFi-kanalskift. Nogle bufferer aggressivt og ignorerer søgekommandoer. Nogle rapporterer deres afspilningsposition nøjagtigt; andre runder af til nærmeste sekund.

Ingen af disse problemer er individuelt katastrofale. Men kombineret på tværs af et hus fuldt af forskellige højttalere, akkumulerer de hurtigt.

Protokollandskabet

Fire store protokoller håndterer multi-rum lyd i dag. Hver tager en forskellig tilgang til synkroniseringsproblemet.

	Sonos	AirPlay 2	Chromecast	UPnP/DLNA
Økosystem	Kun Sonos	Kun Apple	Kun Google	Åben standard
Synkroniseringsnøjagtighed	~1ms (proprietært mesh)	~5-20ms (Apple-optimeret)	~50-200ms (Cast-grupper)	Ingen native synkronisering
Gruppering	Native, fremragende	Native, god	Native, anstændig	Ingen grupperingsstandard
Enhedsrækkevidde	Kun Sonos-højttalere	Apple + licenserede	Cast-aktiverede	Receivere, TV’er, streamere, højttalere — hundredvis af mærker
Android-understøttelse	Kun via Sonos-app	Ikke tilgængelig	Ja	Ja

Sonos løser synkronisering med proprietær hardware — deres højttalere danner et mesh-netværk med mikrosekund-præcis ursynkronisering. Det er guldstandarden, men du er låst til Sonos-hardware.

AirPlay 2 bruger Apples timing-synkroniseringsprotokol til at holde højttalere synkroniserede. Det fungerer godt, men det er Apple-only. Ikke en mulighed på Android.

Chromecast-grupper fungerer rimeligt godt inden for Google-økosystemet. Du opretter en højttalergruppe i Google Home, og Cast-aktiverede apps kan målrette gruppen. Synkroniseringen er anstændig — normalt inden for 50-200ms — men systemet er lukket. Kun Cast-aktiverede enheder deltager.

UPnP/DLNA er den åbne standard. Den fungerer med det bredeste udvalg af hardware — Denon-receivere, Yamaha-soundbars, Panasonic Blu-ray afspillere, WiiM-streamere, smart-TV’er og mere. Hagen: UPnP har absolut intet koncept om enhedsgruppering eller synkroniseret afspilning. Specifikationen adresserer det simpelthen ikke. Hver renderer behandles som en uafhængig enhed.

De fleste mennesker lever ikke helt inden for ét økosystem. Du har den receiver du købte for fem år siden, Chromecast’en i soveværelset, smart-TV’et i stuen og måske en Bluetooth-højttaler på terrassen. Ingen enkelt protokol dækker dem alle.

Cross-protokol udfordringen

Dette er hullet som de fleste musikapps lader stå åbent.

Spotify Connect fungerer godt — med Spotify Connect-enheder. Google Home grupperer Chromecast’er smukt — men kun Chromecast’er. Din Denon-receiver understøtter UPnP og AirPlay, men din Chromecast taler ikke UPnP, og din Android-telefon taler ikke AirPlay.

Så hvad sker der når du vil have køkkenets Chromecast og stuens Denon-receiver til at spille den samme sang på samme tid? I de fleste apps: ingenting. Du vælger én enhed. Det andet rum forbliver stille.

Det underliggende problem er arkitektonisk. De fleste apps er bygget omkring et enkelt output-paradigme — de sender lyd til én destination. Multi-rum kræver en fundamentalt anderledes model: én enkelt sandhedskilde for hvad der afspilles, spredt ud til flere destinationer med den protokol hver enhed forstår, og derefter løbende overvågning og korrektion af drift på tværs af dem alle.

Sådan byggede vi multi-rum i Echobox

Vi kalder dem outputgrupper. Du vælger de enheder du vil have — enhver kombination af UPnP-renderere, Chromecast-enheder og din telefons eget output — og Echobox opretter en gruppe der koordinerer afspilning på tværs af dem alle.

Kerneidéen er enkel. Echobox opretholder en enkelt afspilningstidslinje — én autoritativ optegnelse af hvilket nummer der spiller og hvilken position det er ved. Når du trykker play, spreder gruppekoordinatoren play-kommandoer ud til hver enhed i gruppen ved hjælp af hver enheds native protokol: SOAP-kommandoer til UPnP-renderere, Cast SDK’et til Chromecast’er og den lokale lydmotor til din telefon.

At få dem til at starte nogenlunde samtidigt var den første udfordring. Forskellige enheder har vidt forskellige opstartslatenser — en Chromecast kan have brug for 500ms til at buffere og begynde, mens en UPnP-renderer har brug for 300ms og den lokale motor næsten ingenting. Så vi forskyder play-kommandoerne: den langsomste enhed får sin kommando først, derefter venter vi, derefter sender vi til den næstlangsomste og så videre. Timingen bruger absolutte urhenvisninger i stedet for kumulative forsinkelser, så eksekveringstiden for hver kommando ikke forstyrrer planlægningen.

Vi brugte måneder på at få driftkorrektion rigtigt. Den første version var forfærdelig — den overkorrigerede og skabte hørbare hop, eller underkorrigerede og lod enheder drive fra hinanden over minutter.

Det nuværende system fungerer således: når alle enheder afspiller, poller Echobox hver enkelt for dens aktuelle afspilningsposition ca. én gang per sekund. Den sammenligner hver enheds rapporterede position mod hvor den burde være baseret på synkroniseringsankeret — et referencepunkt der knytter et wall-clock tidspunkt til en medieposition. Hvis en enhed rapporterer at den er ved 1:23.400 men ankeret siger den burde være ved 1:23.650, er det 250ms drift.

Hvad der derefter sker afhænger af enheden.

Per-enheds intelligens er kritisk her. Echobox opretholder en profil for hver enhed den har set, bygget fra tre lag: hvad enheden annoncerer om sig selv, hvad vi ved om dens familie (alle Denon-receivere opfører sig ens), og hvad vi har observeret ved runtime. En Denon AVR med pålidelig søgning får stramme drift-tærskler — vi korrigerer ved 150ms drift med en søgekommando. Et generisk DLNA-TV med upålidelig søgning får meget bredere tolerance — 500ms før vi overhovedet markerer det, og vi springer måske korrektioner helt over hvis søgning har fejlet for mange gange. Systemet lærer: hvis en enheds søgekommandoer fejler 70% af tiden, stopper Echobox med at forsøge søgekorrektion af den enhed og accepterer løsere synkronisering. Se vores guide om UPnP streaming for mere om hvordan enhedskapabiliteter detekteres.

UPnP har ingen native grupperingsstandard, så vi var nødt til at bygge koordineringslaget selv. Hver UPnP-renderer i en gruppe får sine egne SOAP-kommandoer — SetAVTransportURI, Play, Seek — som om det var den eneste enhed der afspillede. Koordineringslaget sørger bare for at disse kommandoer sendes i den rigtige rækkefølge med den rigtige timing.

Noget vi er særligt stolte af: din telefon kan afspille lokalt og til netværksenheder samtidigt. Den lokale motor læser direkte fra lydbufferen med under 10ms latens, mens det samme nummer streames til netværksenheder over HTTP. Det betyder at du kan gå rundt med hovedtelefoner forbundet via Bluetooth mens højttalere i huset spiller den samme musik. Den lokale Android-lydsti håndterer sin egen timing uafhængigt, så lokal afspilning aldrig forringes af netværkskoordineringsoverhead.

Når en enhed dropper ud — WiFi-hik, højttaler går i dvale — går systemet ikke i panik. Det sporer konsekutive fejl og markerer kun en enhed som fejlet efter fem missede polls. Hvis den kommer tilbage, genopretter tre vellykkede polls den. Dette forhindrer gruppen i konstant at skifte enheder ind og ud når netværksforholdene er marginale.

Ærligt talt var den sværeste del ikke nogen enkelt teknisk udfordring. Det var at få systemet til at fungere pålideligt på tværs af den rene mangfoldighed af enheder derude. En firmwareopdatering på én producents højttalere ændrede deres søgeadfærd. Nogle renderere rapporterer position i hele sekunder, hvilket gør sub-sekund driftdetektion umulig. Nogle Chromecast-modeller tager så lang tid at starte at de allerede er et helt sekund bagud når lyden begynder. Hvert quirk havde brug for sin egen workaround, og systemet skulle degradere elegant i stedet for at gå helt i stykker.

Praktiske opsætningstips

Netværkskrav. Alle enheder skal være på det samme subnet. Hvis du har et mesh WiFi-system med separate IoT- og hovednetværk, skal dine højttalere og telefon være på det samme. SSDP multicast-opdagelse skal fungere — nogle enterprise-grade routere blokerer multicast som standard. Hvis Echobox ikke kan finde dine UPnP-enheder, er multicast-filtrering det første du skal tjekke.

WiFi-stabilitet betyder mere end hastighed. Multi-rum lyd kræver ikke meget båndbredde — selv ukomprimeret CD-kvalitetslyd er kun cirka 1,4 Mbps. Men det kræver konsistent latens. Hvis dit WiFi taber pakker eller har periodisk trængsel, akkumulerer drift hurtigere end korrektionssystemet kan kompensere. Et 5 GHz netværk giver generelt mere konsistent latens end 2,4 GHz, selvom 2,4 GHz har bedre rækkevidde gennem vægge.

Valg af enheder til grupper. For den strammeste synkronisering, grupper enheder med lignende karakteristika. To UPnP-receivere fra den samme producent vil holde sig bedre synkroniserede end en Chromecast parret med et UPnP-TV. Når det er sagt, blandede grupper fungerer — sæt bare dine forventninger passende. To UPnP-streamere kan holde sig inden for 50ms; en Chromecast plus en UPnP-renderer kan lande omkring 200ms.

Håndtering af latensforventninger. Hardwaresynkroniserede systemer som Sonos opnår 1-5ms nøjagtighed fordi højttalerne deler et ur. Software-koordineret synkronisering over WiFi, som er hvad enhver cross-protokol løsning bruger, topper omkring 30-50ms i bedste fald. Til baggrundslytning — musik der spiller gennem huset mens du laver mad eller arbejder — er alt under 200ms fint. Du bemærker kun drift hvis du står i en døråbning mellem to rum.

Hvornår du skal bruge hvad. Hvis du har flere Chromecast-enheder, er oprettelse af en Google Home højttalergruppe for dem enklere og vil synkronisere bedre end app-niveau koordinering. Brug Echobox-grupper til de tilfælde som native gruppering ikke kan håndtere: blanding af Chromecast med UPnP, tilføjelse af din telefon som gruppemedlem, eller gruppering af UPnP-enheder der slet ikke har native grupperingsunderstøttelse. De to tilgange er ikke gensidigt udelukkende — du kan bruge Chromecast-grupper til nogle rum og Echobox-grupper til andre.

Fejlfinding. Hvis en enhed konsekvent viser høj drift, tjek dens WiFi-signalstyrke først. Svagt WiFi betyder variabel latens, hvilket betyder at synkroniseringsmotoren konstant jager et bevægende mål. Hvis en specifik enhed forårsager problemer i grupper men fungerer fint alene, kan den have firmware-quirks der påvirker søgning eller positionsrapportering — Echobox’ signalvejsdiagnostik vil vise dig enhedens profil, herunder dens synkroniseringsegnethedsrating og eventuelle lærte observationer om dens adfærd.

Hvor tingene står

Multi-rum på tværs af forskellige protokoller er et svært problem, og vi lader ikke som om det er løst perfekt. Software-koordineret synkronisering vil aldrig matche hardware-synkroniserede systemer som Sonos til kritisk lytning. Nogle enheder har firmware-quirks vi endnu ikke har stødt på. Positionsrapporteringsnøjagtighed varierer vildt på tværs af producenter.

Men til det virkelige scenarie — forskellige højttalere fra forskellige epoker og forskellige mærker, alle der afspiller dit musikbibliotek synkront fra din telefon — fungerer det. Ikke med audiofil-grade synkronisering, men med den slags nøjagtighed der gør hele-huset lytning genuint fornøjelig. Og systemet bliver smartere over tid: enhver afspilningssession lærer Echobox lidt mere om hvordan hver enhed opfører sig, strammer korrektioner for pålidelige enheder og løsner dem for ustabile.