Teil 2: Anwendungsbeispiele einer flexiblen Middleware für Infotainment-Systeme
Die Multimedia-Engine: Teil 2 #####
Fortsetzung des Artikels von Teil 3
Die Multimedia-Engine: Teil 2
Jobangebote+ passend zum Thema
Filtergraphen für Multimedia-Anwendungen
Der in Bild 5 dargestellte Filtergraph implementiert die Funktionen eines CPUbasierten Audio-Players. Der Zugriff auf die Medien erfolgt durch den Media-Reader-Filter. Mit Hilfe der bereitgestellten Dateisysteme und Zugriffsprotokolle wie ATAPI werden die Daten in einen Read- Ahead-Buffer eingelesen. Falls aufgrund vorheriger Synchronisationsvorgänge noch nicht bekannt, wird das vorliegende Format analysiert und ein geeigneter Decoder-Filter ausgewählt. Zur Verfügung stehen neben unkomprimierten PCM-Audio üblicherweise die Formate MP3, WMA und AAC. Sie decodieren den Audio-Strom in ein PCM-Signal, welches in darauffolgenden Filtern nachbearbeitet werden kann. Beispiele hierfür sind Equalizer-Einstellung und -Anzeige. Der Media-Writer-Filter gibt das aufbereitete PCM-Signal schließlich an die Audio-Senke aus.
In Bild 6 ist als erste Verfeinerung die CPU-basierte Encodierung bei gleichzeitiger Audio-Wiedergabe dargestellt. Entsprechend dem Szenario besteht der Filtergraph aus zwei parallelen Ästen, welche von einem gemeinsamen Media-Reader-Filter ausgehen. Der Media-Reader liefert einen einzigen PCM-Audio-Strom, ausgehend von einer Audio-CD. Dieser Audio-Strom wird im WMA-Encoder-Filter encodiert und über einen Media-Writer-Filter auf der Festplatte gespeichert. Die gleichen PCM-Daten werden über den Equalizer und einen weiteren Media-Writer an die Audio-Senke ausgegeben.
Die Limitierung dieses Szenarios ist offensichtlich: Benutzer-Aktionen wie schneller Vorlauf oder Titelsprung sind hier nicht möglich, da sie den PCM-Audio-Strom und damit auch die Encodierung unterbrechen würden. Der Grund dafür ist der gemeinsam genutzte Media-Reader-Filter, der genau einen Audio-Strom vom CD-Laufwerk lesen kann. Ein zweiter, davon unabhängiger Audio-Strom scheitert an der Lesekopf-Trägheit aktuell verfügbarer automotive-tauglicher Laufwerke. Dieser Nachteil wird mit dem in Bild 7 dargestellten Filtergraph des Rip-and-Play-Szenarios überwunden. Die deutlich höhere Geschwindigkeit von Festplatten erlaubt den Einsatz eines zweiten, unabhängigen Media-Reader-Filters, welcher auf die bereits encodierten Daten der Festplatte zugreift und sie in einem zweiten Filtergraphen, einem WMA-Decoder-Filter, zur Verfügung stellt. Die Audio-Wiedergabe erfolgt hier also nicht vom Original-Medium wie in Bild 6. Da das CD-Laufwerk durchaus mit dreibis achtfacher Geschwindigkeit lesen kann, ist schon nach kurzer Vorlaufzeit genügend Material auf der Festplatte vorhanden, um auch Trick-Play- Kommandos ausführen zu können.
Bei schnellen CD-Laufwerken wird hier aber eine weitere Limitierung sichtbar. Der CPU-basierte Encoder benötigt erhebliche CPU-Leistung, die linear mit der Bandbreite des Audio-Stroms, beginnend bei etwa 50 MIPS, ansteigt. Um die Vorteile des Rip-and-Play-Szenarios voll nutzen zu können, ohne dabei andere Applikationen zu beeinträchtigen, ist eine Entlastung der CPU durch einen externen DSP notwendig.
Das Szenario für das DSP-basierte Rip-and-Play ist in Bild 8 dargestellt. Der Unterschied zu Bild 7 besteht in der Verlagerung rechenintensiver Filterfunktionen in den DSP. Der Multispeed-WMA-Encoder wird mit Hilfe des DSP-Link-Filters über die Multimedia-IPC in den DSP ausgelagert. Über den Downlink werden PCM-Daten in den DSP gesandt, während die encodierten Daten über den Uplink zurück in die CPU geladen werden. Der Wiedergabe-Zweig des Filtergraphen nutzt die DSPBeschleunigung auch für den Decoder, der mit einem DSP-Writer-Filter angebunden wird. Dieser hat nur einen Downlink-Kanal, da der decodierte PCM-Strom direkt vom DSP über einen eigenen Media-Writer-Filter an die Audio-Senke ausgegeben wird.
- Die Multimedia-Engine: Teil 2 #####
- Die Multimedia-Engine: Teil 2
- Die Multimedia-Engine: Teil 2
- Die Multimedia-Engine: Teil 2
- Die Multimedia-Engine: Teil 2
