apulse
v0.1.13
Pulseaudio Emulation pour Alsa.
Le programme fournit une alternative de mise en œuvre partielle de l'API PulseAudio. Il se compose d'un script de chargeur et d'un certain nombre de bibliothèques partagées avec les mêmes noms que de PulseAudio d'origine, afin que les applications puissent les charger dynamiquement et penser qu'ils parlent à Pulseaudio. En interne, aucun démon de mélange de sons séparé n'est utilisé. Au lieu de cela, Appulse s'appuie sur les plugins dmix , dsnoop et plug Alsa pour gérer plusieurs sources sonores et capturer des flux en même temps. dmix Plugin muxes multiples flux de lecture; Le plugin dsnoop permet à plusieurs applications de capturer à partir d'un seul microphone; et le plugin plug convertit de manière transparente l'audio entre divers formats d'échantillonnage, les fréquences d'échantillonnage et les numéros de canal. Depuis plus d'une décennie, ALSA est livré avec ces plugins activés et configurés par défaut.
apulse n'a pas été conçu pour remplacer le Pulseaudio. C'est inutile, car ce ne sera que la réimplémentation de PulseAudio d'origine, avec la même architecture client-daemon, requise par l'ensemble de fonctionnalités complet. Au lieu de cela, seules des parties de l'API qui sont cruciales pour des applications spécifiques sont implémentées. C'est pourquoi il y a un script de chargeur, nommé apulse . Il met à jour la valeur de la variable d'environnement LD_LIBRARY_PATH pour pointer également vers le répertoire où les bibliothèques d'Antense sont installées, ce qui les rend à la disposition de l'application.
Le nom vient des noms d'Alsa et de Pulseaudio. Comme aoss était une couche de compatibilité entre les programmes OSS et ALSA, apulse a été conçue pour être une couche de compatibilité entre les applications Pulaudio et ALSA.
Vous avez besoin de bibliothèques ALSA et d'installation de GLIB. Sur les distributions basées sur Debian, ils sont dans les packages libasound2-dev et libglib2.0-dev .
Pour construire et installer, exécuter dans le répertoire source:
$ mkdir build && cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release ..
$ make
# make install
Cela créera un répertoire nommé build et construit-y. Il est possible d'installer simplement en exécutant make install comme root , comme indiqué ci-dessus. Mais vous ne pourrez pas désinstaller des fichiers installés. C'est pourquoi il est recommandé d'envelopper des fichiers dans un package. Utilisez checkinstall , ou une alternative.
Si vous voulez des binaires 32 bits sur une machine 64 bits (par exemple, pour Skype), utilisez:
$ mkdir build && cd build
$ CFLAGS=-m32 cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release ..
$ make
# make install
Les versions GLIB récentes utilisent différents fichiers .pc pour i386 et amd64 . Pour aider pkg-config à trouver des versions 32 bits, utilisez la variable PKG_CONFIG_PATH . Donc, sur Debian, ce sera quelque chose comme:
$ PKG_CONFIG_PATH=/usr/lib/i386-linux-gnu/pkgconfig CFLAGS=-m32 cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release ..
Il existe un moyen de configurer où les bibliothèques d'apulse seront installées, via la variable APULSEPATH CMake. Par exemple, si vous souhaitez installer des bibliothèques dans le chemin par défaut, /usr/lib , utilisez
cmake -DAPULSEPATH=/usr/lib -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release ..
Si les bibliothèques sont installées sur un chemin de bibliothèque ordinaire, vous n'avez pas besoin d'applications d'exécution via apulse Wrapper.
$ apulse <program-name> [program-parameters]
Variables d'environnement APULSE_CAPTURE_DEVICE et APULSE_PLAYBACK_DEVICE peuvent être utilisées pour configurer les périphériques de capture et de lecture. Essayez hw:0,0 , plughw:0,0 et similaires. Reportez-vous au Guide de l'utilisateur ALSA pour une liste complète des noms de périphériques.
Par défaut, les bibliothèques d' apulse sont installées dans un répertoire distinct, afin de les cacher à toutes les applications.
La plupart des applications dans la nature, qui soutiennent à la fois Pulseaudio et ALSA, essaient de automatiquement le système audio utilisé. Tout d'abord, les applications essaient de commencer par PulseAudio. Les bibliothèques de clients originales échouent tôt si aucun démon PulseAudio ne fonctionne ou ne peut être démarré. Ensuite, ils passent à Alsa. La décision est prise une fois, au début. Cela fonctionne bien avec Pulseaudio, mais ne fonctionne pas avec apulse . Ce dernier n'a pas de démons, il dit avec plaisir que tout va bien et qu'il est capable de jouer audio. Les applications essaient ensuite d'appeler plus de fonctions et finalement de toucher des pièces non implémentées, souvent avec des collisions. Ainsi, les bibliothèques sont cachées et ne deviennent visibles que lorsqu'un programme est appelé via le script de wrapper apulse .
Il est possible d'installer des bibliothèques d'apulse sur /usr/lib . Le script en wrapper ne sera pas nécessaire, mais toutes les applications essaieront d'utiliser l'API PulseAudio, bien qu'elles puissent utiliser ALSA.
Il existe la propriété RPATH du format exécutable ELF, qui est utilisé pour spécifier des chemins pour rechercher des bibliothèques dynamiques. C'est comme la variable LD_LIBRARY_PATH, mais par exemple. Étant donné que tout ce script de lanceur apulse est de définir la valeur LD_LIBRARY_PATH avant de lancer une application, il est possible de cuire des chemins pour apulser les bibliothèques dans Target Exécutable lui-même. Et donc pour le lancer comme d'habitude, sans script d'assistance.
Par exemple, pour Firefox, ce serait:
# patchelf --set-rpath /usr/lib/apulse /usr/lib/firefox/libxul.so
Pour une raison quelconque, cela ne fonctionne pas si RPATH est défini pour /usr/lib/firefox/firefox lui-même, donc certaines expériences sont nécessaires pour le faire fonctionner.
Une grande partie de l'API PulsEaudio n'est pas mise en œuvre. Il existe des fonctions qui ne font rien et renvoient certaines valeurs d'arbitrat. Souvent, si l'application essaie d'appeler quelque chose non implémenté, il se bloque tout en essayant de déréférence un pointeur nul. Par défaut, le niveau de traçage est défini sur 0 , ce qui signifie qu'aucun message n'est imprimé à la sortie standard. Il est possible d'augmenter cette valeur à 1 , qui montre des appels de fonction non implémentés, ou à 2 , qui montre tous les appels de fonction.
Pour changer de niveau, utilisez le paramètre WITH_TRACE lors de l'appel cmake . Quelque chose comme cmake -DWITH_TRACE=1 ..
La construction de l'inculse avec le niveau de trace 1 ne résoudra pas les problèmes, mais aidera au moins à identifier si les accidents sont causés par les fonctions non implémentées.
L'APULSE agit comme un client générique ALSA. Il essaie d'ouvrir un périphérique audio et échoue parfois. À la base, Appulse ne mélange ni le rééchantillonnage audio. Au lieu de cela, il s'appuie sur les plugins plug , dmix et dsnoop ALSA, qui sont généralement activés par défaut. Ces plugins gèrent plusieurs sources audio, effectuant un rééchantillonnage et un mélange de manière transparente. Depuis des années, ALSA est livré avec ces plugins activés. L'audio fonctionne simplement sans configurer quoi que ce soit. Mais tout le monde n'utilise pas les paramètres par défaut.
Sur les configurations personnalisées, l'apulse peut ne pas sortir et / ou capturer l'audio. Il ne peut y avoir de son du tout, ou juste un seul flux audio jouant à la fois. Il est également possible que les adaptateurs avec des mélangeurs matériels, capables de jouer plusieurs flux, puissent toujours être incapables de gérer plusieurs flux de capture. Selon le matériel, vous pouvez toujours avoir besoin de plugins dmix ou dsnoop . Ou les deux.
En d'autres termes, pour que Appulse fonctionne, votre configuration doit être capable de jouer et de capturer plusieurs flux simultanément.
Si les autres applications sortent très bien, il est possible que l'application que vous utilisez se limite.
Par exemple, Firefox a désormais un bac à sable, qui bloque l'accès au fichier. Il a une liste prédéfinie de chemins autorisés, mais les appareils ALSA ne sont pas inclus par défaut. Heureusement, il est possible d'ajouter ces chemins à main. Ajouter "/ dev / snd /" à "security.sandbox.content.write_path_whitelist" paramètre dans about:config . Notez que la barre de traînée dans "/ dev / snd /" est requise.
Firefox 58 (tous les soirs) a un peu plus resserré son bac à sable. Maintenant, les appels ioctl() sont également interdits, mais sont utilisés par les bibliothèques ALSA. Cela provoque une violation de bac à sable avec la fin du processus ultérieur. Une exception peut être ajoutée en définissant Paramet security.sandbox.content.syscall_whitelist dans about:config . Ce champ accepte une liste séparée de virgules de numéros d'appel système. Ajoutez-y 16 pour x86-64, ou 54 pour x86 ou bras.
Firefox 60 a maîtrisé son bac à sable de contenu, mais a en même temps déplacé les accès audio des processus de contenu au processus principal. À partir de Firefox 60, aucune modification des paramètres de bac à sable n'est nécessaire.
Le code source est distribué selon les termes de la licence MIT. Voir Licence.Mit pour le texte intégral.
/3rdparty/pulseaudio-headers Contient une partie du projet PulseAudio et est distribué en vertu de LGPLV2.1 +. Voir le contenu des fichiers pour plus de détails.
