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:

• Synthétiseur temps-réel : 5 ms. C'est le temps qui est pris entre l'appui d'une touche sur le clavier MIDI et l'audition de la note. Grossièrement, 5 ms correspond au temps que met le son pour parcourir 1,75 m.
• Jeux : 50 ms. C'est le temps qui correspond au moment où vous voyez l'événement et entendez le son correspondant.
• Lecteurs de films et assimilés : 500 ms et plus. Ces applications sont “connues” pour jouer le son en avance, et envoyer les données audio de telle façon qu'elles sont jouées simultanément avec l'image correspondante.

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 USB
• midi/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 :