Interessante Entwicklung, die hier passiert!
Ich will keinesfalls den Thread entern, aber hier werden ein paar Dinge durcheinander gebracht:
Das heißt, OpenMax gibt Bild und Ton direkt an den Grafiktreiber weiter, und der teilt dann Bild und Ton auf.
Die GPU teilt nichts auf, Audio und Video gelangen durch separate Pfade zur Ausgabe. Aber OpenMax (genauer gesagt die GPU, OpenMax ist nur ein Framework) stellt eine Methode zur Verfügung, die beiden Pfade zu synchronisieren. Konkret einen Video-Scheduler, der die decodierten Video-Frames puffert und, gesteuert durch die Audio-Ausgabe, diese synchron dem "Display-Manager" zur Ausgabe weitergibt. Dieser Mechanismus ist auch nicht RaspberryPi-spezifisch, ein identischer Mechanismus ist auch bei den Amlogic-SoCs zu finden.
Im Kodi z.B. kann man dazu mmal & alsa verwenden.
MMAL ist, vereinfacht gesagt, eine Weiterentwicklung von OpenMax, bietet aber die selben Möglichkeiten bezüglich Audioausgabe. Sowohl Kodi wie auch sofhddevice haben aber eigene Mechanismen zur A/V-Synchronisation implementiert und können deshalb den Ton unabhängig über ALSA ausgeben und sorgen selbständig für die zeitgerechte Darstellung der Video-Frames.
Unter dem rpihddevice, welches zur Ausgabe von Bild & Ton auf den omxplayer zurückgreift, geht das aber nicht.
OT: rpihddevice nutzt nicht omxplayer, aber OpenMax als gemeinsames Framework. Das könnte genau so gut MMAL sein, doch der war zu der Zeit schlicht nicht verfügbar. Im Gegensatz zu omxplayer nutzt rpihddevice aber den ilclient, eine Library von Broadcom um die Programmierung von OpenMax ein wenig zu vereinfachen.
Gruss
Thomas
