Je suis étonné que le tout-puissant Google n'ait pas de réponse toute prête à la question "qu'est-ce que VCHIQ?" Je suis un geek du noyau de longue date et je ne suis pas un employé de Broadcom, et je ne suis pas non plus un expert du BCM283 *, mais voici ce que j'ai trouvé pour (peut-être) la postérité:
Depuis la branche du noyau Raspberry Pi :
Interface de communication noyau à VideoCore pour la famille de produits BCM2708.
Il convient de noter ici que le VideoCore est (surprise surprise) le contrôleur vidéo du SoC que le Pi exécute, et il semblerait que ce soit un moyen pratique d'exécuter des IOCTL plus ou moins directs vers divers sous-systèmes connectés au GPU . Que cela inclut la vidéo n'est pas une grande surprise, mais je suppose qu'il est logique que l'interface de la caméra ait son silicium dans VideoCore compte tenu de tout ce que la vidéo doit faire.
Alors pourquoi le contrôle audio est-il également exécuté via le VideoCore (sinon il n'aurait pas besoin de VCHIQ pour le contrôler)? Je soupçonne que, étant donné que VC prend en charge le matériel pour H.264 et d'autres codecs (et parce que vous pouvez acheminer l'audio via HDMI), c'était juste l'endroit le plus simple pour mettre le silicium. Eh bien, cela et le fait que la puce BCM possède deux MMU (une pour le VC + ARM, une autre pour une utilisation normale du système d'exploitation - voir le diagramme à la page 5 ), ce qui rend possible le DMA sans copie (pas besoin de copier les choses sur le silicium audio - dites-lui simplement qu'un morceau de mémoire lui appartient et non le CPU. Vous ne savez pas encore s'ils le font réellement sous les couvertures, mais pourquoi pas?).
Notez que les IOCTL sur VCHIQ ne transfèrent pas vraiment les données en soi - ils configurent DMA et d'autres opérations entre des morceaux de mémoire et envoient des commandes à divers bits. Cela peut être super dangereux, car vous pourriez potentiellement visser avec les structures de données du noyau interne de l'espace utilisateur, planter le GPU, écarter les données corrompues, etc. Donc, ne définissez pas / dev / vhciq en mode 777 !!!
En tout cas, la réponse courte à "qu'est-ce que VCHIQ?" C'est ici:
VCHIQ est une interface de commande entre le noyau Linux en cours d'exécution et les périphériques (entre autres) dans le silicium VideoCore. / dev / vhciq fournit un accès générique à l'espace utilisateur à ces commandes pour une utilisation (au minimum) par la caméra et les sous-systèmes audio également. C'est une interface décemment dangereuse à exposer à des programmes aléatoires, d'où les autorisations quelque peu restrictives par défaut.
Il y a des gens qui sont à la hauteur de leurs yeux dans le matériel BCM de la communauté RPi; Je ne suis pas l'un d'eux (je suis peut-être jusqu'aux chevilles après quelques heures de recherche :-)). Cela dit, je pense que c'est une vue d'ensemble de haut niveau décente et apprécierait les ajouts / corrections.
En ce qui concerne les raisons pour lesquelles www-data nécessite une autorisation, cela serait dû au fait que votre programme CGI génère des processus enfants en tant qu'utilisateur. Je ne connais pas bien ce joueur en particulier, mais la meilleure pratique serait généralement d'exécuter un démon spécialisé pour contrôler le programme qui s'interface avec le son et le contrôler à partir de CGI en utilisant un socket UNIX ou une interface similaire plutôt que de générer directement un enfant.
En effet, un fournisseur de sécurité a été arrêté il y a quelque temps pour avoir autorisé son serveur racine à accéder à sa machine. Ils ont probablement fait cela pour faciliter la gestion des processus plutôt que d'écrire ce type de couche intermédiaire, mais c'est un non-non de sécurité. Donner à Apache un accès fondamentalement libre au GPU DMA est une mauvaise idée (bien que plus difficile à exploiter, je l'admets).
En esperant que cela répond à votre question.
/dev/vhciqpour exécuter l'audio en général - dans ce cas, c'est parce que l'OP l'utiliseomxplayerpour le faire, ce qui n'est probablement pas idéal.