Musikken dekodes til PCM-sampler, behandles av båndtransporten og effektracken og sendes til Androids lydutgang. Systemet og hodetelefonene kan også kølegge, resample eller kode lyden. Størrelsen på én buffer er ikke hele tiden fra fingerbevegelse til hørbar lyd.

En PCM-ramme inneholder samplene fra alle kanaler på ett tidspunkt. En behandlingsblokk inneholder flere lydrammer. Omregning til tid krever samplingsfrekvensen; skjermens bildefrekvens eller én behandlingsblokk måler ikke direkte den hørbare forsinkelsen.

Bruk hodetelefoner med kabel. I utviklerens tester fjernet de den tydelige hørbare forsinkelsen ved hjul- og ristebetjening over Bluetooth. Faktisk respons avhenger fortsatt av telefon, system og utgangsenhet.

I forgrunnen brukes enhetens minste bufferkrav som nedre grense sammen med en forespørsel på omtrent 30 ms. Dette reduserer lydkøen slik at transportbetjeningen kan påvirke den etterfølgende lyden tidligere.

Avspillingen beholder høyst fire forhåndslesingsvinduer og gjenbruker dekodet lyd i en behovsstyrt hurtigbuffer med grense på 16 MiB. Det reduserer gjentatt dekoding og begrenser minnebruken. Det betyr ikke at hele sporet eller så mye lyd står i kø til hodetelefonene.

Forhåndslesingsvinduer, hurtigbuffer for dekodet lyd og utgangsbuffer har ulike oppgaver. Minnekapasitet kan ikke omregnes direkte til faktisk utgangsforsinkelse uten å skille mellom disse trinnene.

Effektkjeden oppdateres ved lydblokkgrenser, med omtrent 20 ms overgang mellom gammel og ny kjede. Overgangen kan kortvarig øke arbeidet, men fastslår ikke årsaken til knitring. Hvis Android bare tar imot en del av en blokk, sendes den ferdigbehandlede resten etterpå uten ny effektbehandling.

Bypass endrer det hørbare resultatet, men instansen beregner fortsatt for å bevare tilstanden. Fjern ubrukte instanser for å redusere belastningen.

Ved knitring: kontroller kjedens utgangstopper og senk for høy effektforsterkning for å undersøke klipping. Fjern deretter ubrukte effekter og sammenlign belastningen. Manglende lyddata kan gi bufferunderløp, mens for høye topper kan klippe. Overbelastningslampen viser topper, ikke underløp. Trinnene snevrer inn mulighetene, men gir ingen sikker diagnose.

I bakgrunnen sendes PCM i bolker med normal 1× hastighet, og effektbehandlingen beholdes. Et tomt rack ber om omtrent 200 ms buffer; med effekter er målet omtrent 600 ms, begrenset av den tildelte kapasiteten.

En større bakgrunnsbuffer gir rom for variasjoner i systemets planlegging. Er behandlingen vedvarende for langsom, kan det fortsatt bli underløp. I forgrunnen gjenopprettes mindre bufferinnstillinger, men lyden som allerede ligger i kø, må fortsatt avvikles.

Tegningen av hjulet beholder bare nyeste tilstand og høyst én ventende tegneoppgave, slik at gamle tilstander ikke hoper seg opp. Skjermoppdatering og lydutgang følger ulike veier; hørbar Bluetooth-forsinkelse forklarer ikke tapte bilder på skjermen.

Når appen går i bakgrunnen, skjermen slås av eller funksjonen deaktiveres, stoppes de relevante orienteringsmålingene og sensorlytterne frigjøres. Dynamiske refleksjoner endrer lys, ikke lyd. Ristesimuleringens lydeffekt styres separat.

Det som hittil er offentliggjort, er utviklerens kvalitative sammenligning av kabel og Bluetooth. Reproduserbare tall for samlet forsinkelse, behandlingsbelastning eller strømforbruk med fullstendige betingelser er ikke publisert.

Sammenligning krever telefonmodell, systemversjon, utgangsenhet og tilkobling, samplingsfrekvens, effektkjede og samme testpassasje. Bufferforespørsler og mål erstatter ikke målinger. Ti rackplasser beskriver kapasitet, ikke en garanti for at alle kombinasjoner går jevnt, fast forsinkelse eller en bestemt strømbesparelse.