OpenBSD FAQ: Multimedia : (v1.226 ; 30/04/2021)
— [ FAQ Index ] ~ Traduction française de la FAQ OpenBSD : Multimédia —
Pour des raisons de confidentialité, l'enregistrement audio est désactivé par défaut dans OpenBSD. Le paramètre sysctl kern.audio.record
peut être utilisé pour l'activer.
# sysctl kern.audio.record=1 # echo kern.audio.record=1 >> /etc/sysctl.conf
Chaque modèle de carte son a son propre ensemble de contrôles. Certains n'en ont aucun ; d'autres en ont une centaine voire plus. Exécuter mixerctl(8) en tant que root listera tous les contrôles et les paramètres actuels.
Toutes les options de chaque puce audio ne sortent pas nécessairement vers le monde extérieur. Il peut y avoir, par exemple, plusieurs sorties listées qui sont connectées physiquement. Les contrôles d'un dispositif audio peuvent être labellisés différemment. Habituellement les contrôles ont un label explicite, mais parfois il faut simplement essayer différents paramètres pour se rendre compte des effets par chaque contrôle.
Voici une liste de contrôles à considérer :
Contrôles des niveaux et mode muet - Même si les principaux contrôles semblent être correctement paramétrés, il peut y avoir de multiples niveaux de contrôles ou mode muet dans le chemin du signal. Dans l'exemple ci-dessous, le dispositif a un niveau d'enregistrement maître et un contrôle du gain du microphone :
record.adc-0:1=248,248 record.adc-0:1_source=mic inputs.mic=85,85
Amplificateur Externe d'Arrêt (EAPD) -
Cet interrupteur est typiquement utilisé pour gérer l'energie des laptops et peut être utilisé pour avoir un signal de sortie :
outputs.spkr_eapd=on
Enregistrement de Source - Certains dispositifs ont de multiples entrées microphones. Des exemples de tels contrôles :
record.source=mic record.adc-0:1_source=mic
Pour que ces changements prennent effets à chaque redémarrage, éditez le fichier /etc/mixerctl.conf
. Par exemple :
record.adc-0:1_source=mic inputs.mic=85,85
L'utilitaire sndioctl(1) est utilisé pour manipuler les contrôles audio en tant qu'utilisateur normal. L'exécuter sans argument listera tous les contrôles et paramètres actuels.
Le contrôle output.level
est toujours présent. Il correspond soit au contrôle matériel, soit est émulé logiciellement.
Un exemple d'interface USB audio dans la sortie de dmesg ressemblerait à cela :
uaudio0 at uhub2 port 1 configuration 1 interface 1 "ABC C-Media USB Audio Device" rev 1.10/1.00 addr 2 uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls audio1 at uaudio0
Sur la plupart des systèmes, le premier dispositif audio est la carte son interne. Un dispositif USB audio devient alors le second lorsqu'il est connecté. Dans la configuration par défaut de sndiod(8), les deux dispositifs sont connus pour être respectivement snd/0
(celui par défaut) et snd/1
et peuvent être utilisés indépendamment. Les programmes configurés pour utiliser snd/1
utiliseront le périphérique USB.
sndiod(8) peut être configuré pour faire correspondre snd/0
au périphérique USB s'il est connecté ou au périphérique interne lorsqu'il ne l'est pas :
# rcctl set sndiod flags -f rsnd/0 -F rsnd/1 # rcctl restart sndiod
Lorsque le serveur ouvre le dispositif, il essaiera en premier l'USB. S'il n'est pas présent, le dispositif interne est utilisé à la place. Si le dispositif USB es déconnecté, sndiod essaie de continuer l'opération en utilisant la carte son interne. Si le dispositif USB est encore connecté, sndiod le verra la fois suivant lorsqu'il essaiera d'ouvrir le dispositif. Pour force sndiod à basculer entre les dispositifs, recharger le serveur :
# rcctl reload sndiod
OpenBSD est fourni avec aucat(1), un programme qui est capable de jouer des fichiers WAV, AIFF et AU. Il peut être utilisé dans des cas très simples ou pour tester la lecture :
$ aucat -i filename.wav
Il y a beaucoup d'autres lecteurs disponibles en paquets qui prennent en charge d'autres formats audios.
Une fois que l'enregistrement audio est activé par le paramètre sysctl kern.audio.record
, aucat(1) peut être utilisé pour enregistrer des fichiers non compressés au format WAV, AIFF et AU.
$ aucat -o file.wav
La commande ci-dessus commencera l'enregistrement d'un fichier au format WAV. Appuyez sur CTRL+C pour terminer l'enregistrement.
Pour relire le fichier, lancez la lecture :
$ aucat -i file.wav
Si l'enregistrement semble fonctionner mais que la lecture de l'enregistrement est muette ou n'est pas ce que vous espériez, le mixer a probablement besoin de certaines configurations. Assurez-vous de sélectionner le bon périphérique à partir duquel enregistrer et que la source ne soit pas en mode muet.
Si nécessaire, le fichier WAV résultant pourrait être compressé avec le programme approprié depuis l'arborescence des ports. Alternativement, des ports tels que sox, ffmpeg ou audacity peuvent être utilisés pour enregistrer, procéder et compresser des fichiers audio.
Un moniteur général enregistre toutes les sorties audio combinées provenant des différents périphériques, vous permettant ainsi de reproduire ou de sauvegarder tout ce qui passe par le sous-système audio. Cette fonctionnalité peut être utile dans le cas d'une télé-conférence ou toute sorte de mixage audio en direct.
Créez le sous-périphérique moniteur mon
pour sndiod(8) en utilisant :
# rcctl set sndiod flags -s default -m play,mon -s mon # rcctl restart sndiod
Configurez votre programme afin d'enregistrer l'audio à partir du périphérique snd/0.mon
, par exemple :
$ aucat -f snd/0.mon -o file.wav
À ce stade, tout ce que votre système joue sera enregistré dans file.wav
.
Le temps de latence est le temps qui s'écoule entre le moment ou un programme décide de jouer un échantillon et le moment où l'utilisateur entend cet échantillon. Comme les données audio passent par un cache, ce délai est proportionnel à la taille du cache audio. Les valeurs suivantes sont recommandées:
Plus le cache audio est petit (pour avoir un temps de latence faible), plus les probabilités sont grandes d'avoir des problèmes de overrun/underrun. Le cache en overruns/underruns donnera au son un “bégaiement”.
sndiod(8) impose une latence minimale sur toutes les applications audio, et la latence par défaut est 160 ms. Si vous prévoyez d'utiliser des applications qui requièrent une plus faible latence, utilisez l'option -b
pour sélectionner la latence désirée (exprimée en nombre de frames). Par exemple à 48 000 échantillons/seconde, 50 ms de latence correspond à :
48 000 échantillons/seconde x 0,050 secondes = 2 400 échantillons
ensuite, utilisez :
# rcctl set sndiod_flags -b2400
Non, synchroniser l'audio à la vidéo ne nécessite pas une latence faible. Les problèmes de synchronisation sont souvent causés par le logiciel lui-même (mauvaise implémentation, bogues, …). Forcer l'application à utiliser des caches plus petits (en démarrant sndiod(8) en mode latence faible) peut éventuellement cacher le véritable problème, et donner l'impression que le logiciel fonctionne mieux, mais évidemment la meilleure chose à faire est de commencer à chercher le bogue incriminé.
sndiod(8) peut être configuré pour accepter les connexions provenant du réseau, permettant ainsi à d'autres machines d'utiliser la carte son. Sur le système distant (celui avec la carte audio), lancez :
# rcctl set sndiod flags -L-
Sur le système local, configurez votre programme pour qu'il utilise : snd@hostname/0
où “hostname” est l'adresse du système distant. La variable d'environnement AUDIODEVICE
devrait être définie à la valeur précédente pour faire de la carte audio distante le périphérique audio par défaut.
Notez qu'un système capable de se connecter au port TCP 11025 de la machine distante sera capable d'utiliser le périphérique audio. Pour des raisons de confidentialité, seul un utilisateur sur une seule machine peut se connecter au système à la fois. Si plusieurs systèmes doivent utiliser le même périphérique audio simultanément, le cookie d'autorisation de sndio(7) doit être le même. Pour ce faire, copiez votre fichier ~/.sndio/cookie
sur tous les comptes qui pourraient utiliser le périphérique audio.
Pour éviter les bogues, le trafic TCP sur le port 11025 pourrait être prioritaire avec packet filter. Avec la configuration par défaut, sndiod va utiliser environ 200 kB/s de bande passante.
Le dispositif audio par défaut est choisi avec la variable d'environnement AUDIODEVICE
. Si elle n'est pas paramétrée, snd/0
est utilisée, qui est le premier dispositif audio géré par sndiod(8). La manière la plus flexible de choisir le dispositif par défaut est d'exporter AUDIODEVICE
, dans le profil de session de l'utilisateur.
Une autre manière de changer le dispositif de sortie audio par défaut est de le faire gérer par sndiod(8) en tant que premier dispositif. Par exemple, pour utiliser une DAC externe plutôt que la puce embarquée de votre carte-mère, changez simplement les drapeaux de démarrage de sndiod(8) pour utiliser ce dispositif :
# rcctl set sndiod flags -f rsnd/1 # rcctl restart sndiod
Le second dispositif audio (rsnd/1) deviendra celui par défaut.
Si vous n'entendez rien quand vous jouez de l'audio, il est possible que le contrôle du mixage soit trop faible ou simplement muet. Voir la section 13.1 - Configurer les périphériques audios pour configurer le mixage. Merci d'activer toutes les entrées et sorties avant de reporter un problème.
Si vous croyez que votre périphérique doit fonctionner, mais que pour une raison inconnue ce n'est pas le cas, il est temps de déboguer. Les étapes suivantes peuvent déterminer si les données sont traitées par le DAC.
# cat > /dev/audio0 < /dev/zero & [1] 9926 # audioctl play.{bytes,errors} play.bytes=3312000 play.errors=0 # audioctl play.{bytes,errors} play.bytes=7065600 play.errors=0 # audioctl play.{bytes,errors} play.bytes=9379200 play.errors=0 # kill %1 # fg %1 cat > /dev/audio0 < /dev/zero Terminated
Ici nous observons que le compteur des données traitées play.bytes
augmente chaque fois lors de la vérification, donc les données passent. Nous observons aussi que le périphérique récupère assez de données dans le tampon play.seek et que le périphérique n'a pas de problèmes via play.errors
. C'est une bonne chose.
Il faut remarquer que même si vous avez des enceintes connectées quand vous faites vos tests, vous n'entendrez rien. Le test envoie des zéros au périphérique qui devient silencieux pour tous les encodages par défaut supportés.
Puisque nous savons que le périphérique peut traiter des données, c'est un bonne idée de vérifier à nouveau les paramètres du mixage. Soyez sûr que toutes les sorties et entrées ne sont pas muettes et à un niveau raisonnable.
Si à ce moment vous continuez d'avoir des problèmes, il est probablement temps d'envoyer un rapport de bogue. En plus du rapport d'information de bogue comme un dmesg complet et une description du problème, merci d'inclure aussi la sortie par défaut de mixerctl -v
et les sorties des tests précédents du traitement DAC.
Le protocole “Musical Intrument Digital Interface” (MIDI) fournit une façon standardisée et efficace de représenter les informations musicales sous forme de données électroniques. La donnée MIDI contient uniquement les informations nécessaires au synthétiseur pour jouer les sons, plutôt que des sons eux-mêmes.
Pour jouer des données MIDI, un synthétiseur connecté au port MIDI de la machine est indispensable. De façon similaire, pour enregistrer des données MIDI, un instrument MIDI est indispensable (comme un clavier MIDI). Les instruments MIDI évolués peuvent contenir plusieurs éléments (synthétiseurs, claviers, surfaces de contrôle, etc…). Ils apparaissent sous forme de plusieurs ports MIDI sous OpenBSD.
Quand OpenBSD est déjà fonctionnel, regardez les ports MIDI dans la sortie de la commande dmesg(8). Un exemple de ports MIDI dans une sortie dmesg :
umidi0 at uhub2 port 2 configuration 1 interface 0 "Roland Roland XV-2020" rev 1.10/1.00 addr 2 midi0 at umidi0: <USB MIDI I/F> umidi1 at uhub1 port 2 configuration 1 interface 1 "Evolution Electronics Ltd. USB Keystation 61es" rev 1.00/1.25 addr 3 midi1 at umidi1: <USB MIDI I/F>
Cela montre deux pilotes midi(4) attachés, vus par sndio(7) comme:
midi/0
- un synthétiseur connecté par USBmidi/1
- un clavier MIDI maître La sortie du clavier peut être connectée à l'entrée du synthétiseur comme :
$ midicat -q midi/0 -q midi/1
Maintenant vous pouvez entendre ce que vous jouez sur le clavier MIDI à travers le synthétiseur.
Le serveur sndiod(8) expose les ports MIDI thru, permettant à des programmes de s'envoyer des données MIDI. Par exemple, si vouz n'avez pas un synthétiseur matériel connecté, vous pourriez en démarrer qui soit logiciel (tel que le port audio/fluidsynth) et ensuite d'utiliser la sortie MIDI tel que :
$ midicat -q midi/0 -q midithru/0
Pour des raisons de confidentialité, l'enregistrement vidéo est désactivé par défaut dans OpenBSD. Le paramètre kern.video.record
de sysctl doit être utilisé pour l'activer.
# sysctl kern.video.record=1 # echo kern.video.record=1 >> /etc/sysctl.conf
Beaucoup de webcam suivant la spécification UVC (USB Video Class) sont prises en charge par le pilote de dispositif uvideo(4) et sont rendues accessibles à l'utilisateur via le calque video(4).
Une webcam prise en charge (ou tout autre dispositif vidéo) se voit dans dmesg tel que :
uvideo0 at uhub0 port 8 configuration 1 interface 0 "Azurewave Integrated Camera" rev 2.01/69.05 addr 10 video0 at uvideo0 uvideo1 at uhub0 port 8 configuration 1 interface 2 "Azurewave Integrated Camera" rev 2.01/69.05 addr 10 video1 at uvideo1
Ce dispositif sera accessible au-travers de /dev/video0
.
Certains ordinateurs portables attachent un second dispositif vidéo (inutilisable) pour les caméras infra-rouge. Ce dispositif de caméra utilisable peut être trouvé avec la commande video(1) :
$ video -q -f /dev/video0 video device /dev/video0: encodings: yuy2 frame sizes (width x height, in pixels) and rates (in frames per second): 320x180: 30 320x240: 30 352x288: 30 424x240: 30 640x360: 30 640x480: 30 848x480: 20 960x540: 15 1280x720: 10 controls: brightness, contrast, saturation, hue, gamma, sharpness, white_balance_temperature $ video -q -f /dev/video1 video: /dev/video1 has no usable YUV encodings
Seul root est autorisé à accéder aux dispositifs vidéo par défaut. Les permissions du dispositifs doivent être changées vers un utilisateur régulier :
# chown $USER /dev/video0
Cette section utilise ffplay et ffmpeg du paquet ffmpeg. Pour connaître les capacités d'un caméra donnée, utilisez ce qui suit :
$ ffplay -f v4l2 -list_formats all -i /dev/video0 [...] [video4linux2,v4l2 @ 0x921f8420800] Raw : yuyv422 : YUYV : 640x480 320x180 320x240 352x288 424x240 640x360 848x480 960x540 1280x720 [video4linux2,v4l2 @ 0x921f8420800] Compressed: mjpeg : MJPEG : 1280x720 320x180 320x240 352x288 424x240 640x360 640x480 848x480 960x540
La première ligne montre les résolutions supportées dans le format non compressé YUYV. Les taux de débit peuvent être très bas. La seconde ligne montre les résolutions supportées du format MJPEG compressé, qui peut délivrer des taux de débit plus haut.
Choisissez une des résolutions MJPEG et exécutez la commande suivante pour la tester :
$ ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0 [...] Input #0, video4linux2,v4l2, from '/dev/video0':B sq= 0B f=0/0 Duration: N/A, start: 1599377893.546533, bitrate: N/A Stream #0:0: Video: mjpeg (Baseline), yuvj422p(pc, bt470bg/unknown/unknown), 1280x720, 30 fps, 30 tbr, 1000k tbn, 1000k tbc
Le flux webcam devrait être affiché selon la résolution et le taux de débit choisis.
Si cela fonctionne, la vidé peut être enregistré avec ffmpeg, tel que :
$ ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0 ~/video.mkv
Appuyez sur la touche Q pour arrêter l'enregistrement.
Les webcam ont généralement une luminosité, un contraste et d'autres contrôles qui peuvent être modifiés avec la commande video(1).
$ video -c brightness=128 contrast=32 saturation=64 hue=0 gamma=120 sharpness=3 white_balance_temperature=auto
Pour exemple, la luminosité peut être changée à une valeur de 200 :
$ video brightness=200 brightness: 128 -> 200
Tous les paramétres peuvent être réinitialisés à leur valeur par défaut avec la commande video -d
.
Certains paramétres prennent en charge l'auto-ajustement si leur valeur est sur “auto”.
Chromium a accès par défaut à /dev/video
. Pour permettre à Chromium d'accéder à d'autres dispositifs vidéo, le chemin vers le dispositif doit être ajouté à /etc/chromium/unveil.main
et /etc/chromium/unveil.utility_video
.
Firefox a accès par défaut à /dev/video
et /dev/video0
. Pour permettre à Firefox d'accèder à d'autres dispositifs vidéo, le chemin vers le dispositif doit être ajouté à /etc/firefox/unveil.main
.
Cette page est la traduction officieuse de la page “FAQ - Multimedia“ de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !
Si vous voulez participer à l'effort de traduction, merci de lire ce topic.
Contribut(rice|eur)s :