Úgy néz ki a Jelly Bean nem csak vizuális, teljesítménybeli és használhatósági szempontból hoz változást az ICS-hez képest, de az audió rész is sokat fog javulni. Az eddigi Android verziók és készülékek eddig nem tették lehetővé a hangkeltő appok kellő minőségben történő futtatását, de a hardvergyártók elé állított szigorúbb követelményekkel és a szoftveres módosításokkal ez hamarosan megváltozik.

Miről is beszélünk?

Sok támadás érte eddig az Android platformot a rá írt zenei applikációk teljesítményével/használhatóságával kapcsolatban, mondván: a rendszernek akkora a jelkésleltetése, hogy nem lehet rá normális, hangkeltéssel kapcsolatos szoftvert írni. Röviden:

Hát ez tényleg WTF.

Miért alakult ki ez az állapot?

Ha egy hanglejátszással kapcsolatos app minőségét vizsgáljuk, akkor vizsgálnunk kell az app mögött lévő operációs rendszer és a hardver tulajdonságait is, mert ezek nagyban befolyásolják a kapott eredményt. Ez duplán igaz ha valamilyen hangszert emuláló szoftvert vizsgálunk, mert itt az egész rendszer azonnali reakciója alapvetően fontos. Ha a hardver, az OS vagy az app túlterhelt, akkor tapasztalhatjuk hogy ugrál, kattog a hang, vagy (ha a fejlesztők ezt elkerülendő nagy átmeneti buffert alkalmaznak) az egész szoftver lomhán reagál.

Mi is az a latency?

A latency nem egyetlen elem mérőszáma. A rendszer minden összetevőjének amin a hang keresztülmegy, van valamennyi késleltetése, a latency ezeknek a késleltetéseknek az összege. Nem lehet egyetlen összetevőt hibáztatni a magas késleltetésért, hiszen ez leginkább az API hiányosságaiból, a rendszer mixer lassúságából, és egyéb, eszközspecifikus késleltetésekből adódik össze. Az Apple tökéletes munkát végzett ezen a téren az iOS-ben, ezért is érthető a dominanciája a mobil zenei alkalmazások terén. De ez nem azt jelenti hogy nem lehet elérni ugyanezt más rendszerek alatt, akár számos különböző hw kiépítés esetében. A Windows  (vagy a Linux) jó példa arra hogy mik azok a megoldások amik működnek (ASIO, Linux RT kernelek 10ms alatti latency értékkel) és mik azok amik nem, hogyan javul az egész rendszer teljesítőképessége a hw változtatása nélkül.
A netes fórumokon nagyon sokan egy adott (jelenleg csak tárolt változatban elérhető) oldal mérőszámaira hivatkoznak, mely iOS-ra 5.8ms, általános Androidra 371.5ms-ot, míg legjobb Android eredménynek 108.8ms-ot jelöl meg. Ez annyiból nem igaz hogy ezt pusztán a minimális bufferméretből vezették le (tehát a rendszerkésleltetés nincs benne, sőt, urambocsá' van aki elég egzakt külső méréssel 40-80ms-ot mért iOS-on, persze ez az ICS Google által megadott ~100ms értékén nem segít), de belátható, hogy az Android sokkal rosszabbul teljesített.
Eddig.

Mi változik a 4.1-ben, és a támogatott eszközökben?

- Alacsony késleltetésű (low latency) audio lejátszás új mixerrel, és egyéb API módosításokkal
- A késleltetési idő 10ms alá szorítása. Jelenleg ezzel kapcsolatban kizárólag a Galaxy Nexusra hivatkoznak, más eszközökön hasonló teljesítményjavulás érhető el, de még nincs szó arról hogy melyiken, és mikor.
- Szigorú követelmények a beszállítókkal szemben a maximális késleltetési idővel kapcsolatban, valamikor a jövőben.
- Továbbfejlesztett OS funkciók, úgymint: USB audio eszköz támogatása, többcsatornás hang (HDMI), felvételi funkciók, stb. lásd: http://developer.android.com/about/versions/jelly-bean.html

Tehát úgy tűnik az Android végre a helyes irányba fordul ezen a téren is. Jövő ilyenkor talán már Android alatt is tud a szomszéd büdös kölke real time cintányérozni, avagy a jövő lo-fi dubstep hercege már az új Jelly Bean funkciók segítségével nyomhatja a performanszait. Telóról.

Kapcsolódó anyagok:

A írást a kommentekben igen cserfes decoati küldte nekünk, köszönjük! :)

Címkék: audio olvir

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.