Sikeres tervezés valós idejű akusztikai feldolgozásban

Az alacsony késleltetésű, valós idejű akusztikai feldolgozás kulcsfontosságú tényező számos beágyazott feldolgozási alkalmazásban, többek között a hang előfeldolgozásában, a beszédfelismerésben és az aktív zajszűrésben. Mivel a valós idejű teljesítményre vonatkozó követelmények folyamatosan nőnek, ezen alkalmazási területeken a fejlesztőknek stratégiai gondolkodásmódot kell alkalmazniuk ahhoz, hogy megfeleljenek az igényeknek.

Tekintettel a számos nagyobb SoC által kínált jelentős teljesítményre, csábító lehet egyszerűen megterhelni ezeket az eszközöket a felmerülő további feladatokkal, de fontos megérteni, hogy a késleltetés és a determinizmus azon kritikus elemek, amelyek könnyen komoly valós idejű rendszerproblémákhoz vezethetnek, amennyiben nem vesszük figyelembe őket. Ez a cikk olyan kérdéseket vizsgál meg, amelyeket a tervezőknek szem előtt kell tartaniuk, amikor egy SoC és egy dedikált audio DSP között választanak, hogy elkerüljék a kellemetlen meglepetéseket a valós idejű akusztikai rendszereikben.
Az alacsony késleltetésű akusztikai rendszerek az alkalmazások széles körét fedik le. Például csak az autóiparban az alacsony késleltetés kritikus fontosságú a személyes audiozónák, az útzajcsökkentés és az autóba épített kommunikációs rendszerek esetében, hogy csak néhányat említsünk.
A járművek elektronizálásának feltörekvőben lévő tendenciájával az útzajcsökkentés (RNC – Road Noise Cancellation) még fontosabbá válik, mivel nincs észrevehető zajt keltő belső égésű motor. Ezért az autó és az út közötti interfészhez kapcsolódó hangok sokkal észrevehetőbbé és sértőbbé válnak. Ennek a zajnak a csökkentése nemcsak kényelmesebb vezetési élményt teremt, hanem csökkenti a vezető fáradtságát is. Az alacsony késleltetésű akusztikai rendszer SoC-en történő megvalósítása számos kihívással jár, szemben a dedikált audio DSP-vel. Ezek közé tartoznak a késleltetés, a skálázhatóság, a frissíthetőség, az algoritmusokkal kapcsolatos megfontolások, a hardveres gyorsítás és az ügyféltámogatás kérdései. Vizsgáljuk meg ezeket sorban.

Késleltetés

A valós idejű akusztikai feldolgozó rendszereknél fontos kérdés a késleltetés. Ha a processzor nem tud lépést tartani a rendszer valós idejű adatmozgásával és számítási igényeivel, akkor elfogadhatatlan hanghullámok keletkezhetnek.
Az SoC-ek jellemzően chipen belüli SRAM-mal rendelkeznek, és ennek megfelelően a legtöbb helyi memória-hozzáférésnél a gyorsítótárra kell támaszkodniuk, ami a kód és az adatok nem determinisztikus elérhetőségét eredményezi, és növeli a feldolgozási késleltetést is. Egy olyan valós idejű alkalmazás esetében, mint az aktív zajszűrés (ANC – Active Noise Cancellation), ez önmagában is meghiúsíthatja az üzletet. Ugyanakkor az is tény, hogy az SoC-eken nem valós idejű operációs rendszerek futnak, amelyek komoly többfeladatos (multitasking) terhelést kezelnek. Ez felerősíti a rendszer nem determinisztikus működési jellemzőjét, ami nagyon megnehezíti a viszonylag összetett akusztikai feldolgozás támogatását egy többfeladatos környezetben.
Az 1. ábra egy konkrét példát mutat egy valós idejű hangfeldolgozási terhelést futtató SoC-re, ahol a CPU-terhelés kiugrik, amikor a magasabb prioritású SoC-feladatok kiszolgálása történik. Ezek a tüskék például SoC-központú tevékenységek, például médiarenderelés, böngészés vagy alkalmazásfuttatás miatt léphetnek fel a rendszeren. Amikor a tüskék meghaladják a 100%-os CPU-terhelést, az SoC már nem valós időben működik, és ez hangkimaradásokat eredményez.

1. ábra A CPU pillanatnyi terhelése egy reprezentatív SoC esetében, amely más feladatok mellett nagy hangmemória-feldolgozást is végez¹

Az audio DSP-ket viszont úgy tervezték, hogy a jelfeldolgozási útvonal teljes hosszában alacsony késleltetést garantáljanak, a mintavételezett audiobemenettől az összetett (például audio + zajcsökkentő) hangszórókimenetig. Az L1 utasítás- és adat SRAM, a processzormaghoz legközelebbi egyciklusú memória elég bőséges ahhoz, hogy számos feldolgozási algoritmust támogasson anélkül, hogy a közbenső adatokat a chipen kívüli memóriába kellene áthelyezni. Ezenkívül a chipen lévő L2 memória (a magtól távolabb van, de még mindig sokkal gyorsabb hozzáférésű, mint a chipen kívüli DRAM) segít puffert biztosítani a közbenső adatműveletekhez, ha az L1 SRAM-tároló kapacitását meghaladja. Végül, az audio DSP-k általában valós idejű operációs rendszert (RTOS) futtatnak, amely biztosítja, hogy a beérkező adatok feldolgozhatók és elküldhetők legyenek a célállomásukra, mielőtt új bemeneti adatok érkeznének, ezzel biztosítva, hogy az adatpufferek ne csorduljanak túl a valós idejű működés során.
A rendszerindítás tényleges késleltetése – amelyet gyakran az audio rendelkezésre állási idővel mérnek – szintén fontos mérőszám lehet, különösen az olyan autóipari rendszerekben, ahol a hangjelzéseket az indítástól számított bizonyos időablakon belül kell sugározni. Az SoC-ek világában, ahol jellemzően hosszadalmas rendszerindítási szekvenciával kell számolni – amely magában foglalja az egész eszköz operációs rendszerének felhozatalát – nehéz vagy lehetetlen teljesíteni ezt az indítási követelményt. Másrészről viszont egy önálló, saját RTOS-t futtató, más külső rendszerprioritásoktól független, audio DSP optimalizálható olyan gyors indításra, amely kényelmesen kielégíti a „time-to-audio” követelményt.

Skálázhatóság

Míg az SoC-ek esetében a késleltetések problémát jelentenek az olyan alkalmazásokban, mint a zajszabályozás, az akusztikai feldolgozásra irányuló SoC-ek másik fő hiányossága a skálázhatóság. Más szóval, a nagy rendszereket (például autóipari fejegységeket és klasztereket) vezérlő, sok különböző alrendszert tartalmazó SoC-ek nem tudnak könnyen skálázódni az alacsony szintű audioigényekről a magas szintű audioigényekre, mivel az egyes alrendszer-összetevők skálázhatósági igényei között állandó konfliktus áll fenn, ami kompromisszumokat igényel az SoC teljes kihasználtságában. Ha például egy fej-fej SoC egy távoli tunerhez csatlakozik, és az autóipari modellek között a tunernek néhány csatornáról sok csatornára kell skálázódnia, akkor minden egyes csatornakonfiguráció felerősíti a korábban említett valós idejű problémákat. Ennek oka, hogy minden egyes további, az SoC irányítása alatt álló funkció megváltoztatja az SoC valós idejű viselkedését és a több funkció által használt kulcsfontosságú architekturális összetevők erőforrás-ellátottságát. Ezek az erőforrások olyan szempontokat foglalnak magukban, mint a memória sávszélessége, a processzormagciklusok és a rendszerbusz használati joga (bus arbitration).
A többfeladatos SoC-hez csatlakozó más alrendszerekkel kapcsolatos aggályok mellett az akusztikai alrendszernek is megvannak a saját skálázhatósági problémái. Van egy alacsony végponttól a magas végpontig terjedő skálázás (például a mikrofon- és hangszórócsatornák számának növelése egy ANC-alkalmazásban), és ott van az audioélmény skálázása is, az alapvető hangdekódolástól és sztereó lejátszástól kezdve a 3D virtualizáción és más prémiumfunkciókon keresztül. Bár ezek a követelmények nem osztoznak az ANC-rendszerek valós idejű korlátain, mégis közvetlenül kapcsolódnak a rendszerhez kiválasztott megfelelő hangprocesszorhoz.
Egy különálló audio DSP használata egy SoC társprocesszoraként tökéletes megoldást jelent az audio skálázhatósági problémára, lehetővé téve a moduláris rendszertervezést és a költségoptimalizált megoldást. Az SoC sokkal kevésbé tud a nagyobb rendszer valós idejű akusztikai feldolgozási igényeire koncentrálni, ehelyett a feldolgozást az alacsony késleltetésű audio DSP-re terhelheti. Ezen túlmenően az átfogó kódkompatibilis és pin-kompatibilis ütemtervben több különböző ár/teljesítmény/memória szintet kínáló audio DSP-k maximális rugalmasságot biztosítanak a rendszertervezők számára, hogy egy adott termékszinthez igazítsák az audioteljesítményt.

2. ábra ADSP-2156x DSP, egy nagymértékben skálázható hangprocesszor illusztrációja

Frissíthetőség

Mivel a mai járművekben egyre gyakoribbá válnak a fedélzeti firmware-frissítések, egyre fontosabbá válik a frissíthetőség a kritikus javítások kiadásához vagy új funkciók biztosításához. Ez komoly problémákat okozhat egy SoC számára a különböző alrendszerek közötti megnövekedett függőségek miatt. Először is, az SoC-eken több feldolgozási és adatmozgatási szál verseng az erőforrásokért. Ez növeli a versenyt a processzor MIPS-ért és a memóriáért, amikor új funkciókat adnak hozzá, különösen a csúcstevékenységek kirobbanásakor. Az audio szempontjából az SoC egyéb vezérlési tartományaiban a funkciók hozzáadása kiszámíthatatlan hatással lehet a valós idejű akusztikai teljesítményre. Ennek a helyzetnek az egyik mellékhatása, hogy az új funkciókat az összes működési síkban kereszt-tesztelni kell, ami számtalan permutációt eredményez a versengő alrendszerek különböző működési módjai között. Így a szoftverellenőrzés exponenciálisan növekszik minden egyes frissítési csomag esetében. Más szemszögből nézve azt mondhatjuk, hogy az SoC audioteljesítményének javítása az SoC által vezérelt egyéb alrendszerek funkcionalitási ütemtervén kívül a rendelkezésre álló SoC MIPS-től is függ.

Algoritmusfejlesztés és teljesítmény

Nyilvánvalónak kell lennie, hogy a valós idejű akusztikai algoritmusok fejlesztéséhez az audio DSP-ket kifejezetten erre a feladatra tervezték. Az SoC-ektől való jelentős megkülönböztetésként az önálló audio DSP-k olyan grafikus fejlesztési környezeteket kínálnak, amelyek lehetővé teszik a minimális DSP-kódolási tapasztalattal rendelkező mérnökök számára, hogy minőségi akusztikai feldolgozást illesszenek a terveikbe. Az ilyen típusú eszközök a fejlesztési idő lerövidülésével csökkenthetik a fejlesztési költségeket, a minőség vagy a teljesítmény feláldozása nélkül.
Az ADI SigmaStudio^® grafikus audiofejlesztő környezete például intuitív grafikus felhasználói felületbe (GUI) integrált jelfeldolgozási algoritmusok széles választékát kínálja, lehetővé téve bonyolult audio-jelfolyamatok létrehozását. Támogatja továbbá a grafikus A2B konfigurációt az audiotovábbításhoz, ami nagyban segíti a valós idejű akusztikai rendszerek fejlesztésének megvalósulását.

3. ábra Az Analog Devices SigmaStudio grafikus fejlesztőkörnyezete

Audiobarát hardverfunkciók

A kifejezetten hatékony párhuzamos lebegőpontos számításokhoz és adatelérésekhez tervezett processzormag-architektúrán kívül az audio DSP-k gyakran rendelkeznek dedikált többcsatornás gyorsítókkal az olyan gyakori audioprimitívekhez, mint a gyors Fourier-transzformáció (FFT), a véges és végtelen impulzusválasz (FIR és IIR) -szűrés, valamint az aszinkron mintavételezési sebesség konverzió (ASRC). Ezek lehetővé teszik a valós idejű audioszűrést, mintavételt és frekvenciatartománybeli konverziót a központi processzoron kívül, növelve ezzel a hatékony magteljesítményt. Emellett optimalizált architektúrájuknak és adatfolyam-kezelési képességeiknek köszönhetően rugalmas és felhasználóbarát programozási modellt tesznek lehetővé.
Az audiocsatornák számának, a szűrőfolyamoknak, a mintavételi sebességeknek és hasonlóknak az elterjedése miatt fontos, hogy az adatok hatékony továbbítása, valamint a hozzáadott késleltetés vagy külső interfészlogika elkerülése érdekében olyan maximálisan konfigurálható pin-interfész létezzen, amely lehetővé teszi a mintavételi sebesség in-line konverzióját, a precíziós órajelek és a szinkronizált, nagy sebességű soros portok használatát. Az ADI SHARC^® családba tartozó processzorok digitális audio-összekötője (DAI) jól példázza ezt a képességet, amint az a 4. ábrán látható.

4. ábra Digitális audiointerfész (DAI) blokkdiagram

A beágyazott processzorral történő fejlesztés egyik gyakran figyelmen kívül hagyott szempontja az eszköz ügyféltámogatása.
Bár az SoC-gyártók támogatják az akusztikus algoritmusok integrált DSP-termékeiken történő futtatását, ez a gyakorlatban számos kötelezettséggel jár. Egyrészt a szállítói támogatás gyakran összetettebb, mivel az akusztikai szakértelem jellemzően nem az SoC-alkalmazásfejlesztés területe. Következésképpen általában gyenge a támogatás azon ügyfelek számára, akik saját akusztikai algoritmusokat kívánnak fejleszteni az SoC chipre épített DSP technológiáján. A gyártó inkább szabványos algoritmusokat kínál, és jelentős egyszeri mérnöki tevékenységköltséget (NRE – Non-recurring engineering) számít fel az akusztikai algoritmusoknak az SoC egy vagy több magjára történő átviteléért. Még ebben az esetben sincs garancia a sikerre, különösen, ha a gyártó nem kínál kiforrott, alacsony késleltetésű keretszoftvert. Végezetül, az SoC-alapú akusztikai feldolgozás harmadik féltől származó ökoszisztémája általában meglehetősen törékeny, mivel ez nem az SoC középpontjában áll, hanem inkább egy megbízhatatlan módon támogatott funkció.
Egyértelmű, hogy egy célzottan épített audio DSP sokkal erősebb ökoszisztémát hordoz magában az összetett akusztikai rendszerek fejlesztéséhez, az optimalizált algoritmuskönyvtáraktól és eszközillesztőktől kezdve a valós idejű operációs rendszerekig és a könnyen használható fejlesztőeszközökig. Ráadásul az audiofókuszú referenciaplatformok (mint az 5. ábrán látható ADI SHARC audio modul platformja), amelyek felgyorsítják a piacra kerülési időt, ritkaságnak számítanak az SoC-ek esetében, de meglehetősen gyakoriak az önálló audio DSP területén.

5. ábra SHARC audiomodul (SAM)-fejlesztési platform (SHARC Audio Module (ADZS-SC589-MINI) Evaluation Board | Analog Devices)

Összefoglalás

Nyilvánvaló, hogy a valós idejű akusztikai rendszerek tervezése a rendszer erőforrásainak tudatos, stratégiai tervezését igényli, és nem lehet egyszerűen a többfeladatú SoC-en megmaradt feldolgozási hely elosztásával kezelni. Ehelyett az alacsony késleltetésű feldolgozásra optimalizált önálló audio DSP valószínűleg nagyobb robusztusságot, csökkentett fejlesztési időt és optimális skálázhatóságot eredményez a jövőbeli rendszerigények és teljesítményszintek kielégítésére.

Hivatkozás

¹ Paul Beckmann. „Többmagos SoC processzorok: Teljesítmény, elemzés és optimalizálás.” 2017 AES International Conference on Automotive Audio, 2017. augusztus.

További műszaki és kereskedelmi információkat az Analog Devices hivatalos hazai forgalmazójától, az Arrow Electronics Hungary-től kaphatnak.

Szerző: David Katz – Igazgató, Infotainment rendszerek architektúra

Arrow Electronics Hungary
1138 Budapest, Váci út 140.
Bihari Tamás, Senior Field Application Engineer
E-mail: Ez az e-mail-cím a szpemrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát.
Tel.: +36 30 748 0457
www.arrow.com