Générer du bruit aléatoire pour le plaisir dans / dev / snd /

41

Récemment, j'ai exploré le dossier enchanted / dev. Je souhaite écrire des données aléatoires sur un périphérique audio afin de générer du bruit.

J'utilise ALSA.

Je demande donc à cat de diriger des données aléatoires vers le fichier de lecture situé dans le dossier / dev ...

 cat file-of-random-data > /dev/snd/pcmC0D0p

alors je reçois ce qui semble être une erreur de chat

 cat: write error: File descriptor in bad state

Comment puis-je résoudre ce problème afin d’entendre de délicieux jeux statiques sur ma carte son?

audio alsa

— jones
source

1

Je pense que vous devez envoyer des données PCM aléatoires , ou peut-être que vous devez d'abord configurer l'appareil avec quelques ioctls - vous ne pouvez pas simplement vider des octets aléatoires.

— Gilles, arrête de faire le mal

@Gilles Selon Wikipedia, .wav est PCM et j'obtiens exactement le même résultat en remplaçant le fichier aléatoire par un fichier .wav. Je vais étudier la configuration de certaines commandes d'entrée / sortie.

— jones

Quelqu'un at-il un pointeur pour un tutoriel sur la façon de configurer des ioctls? Pour quelque chose appelé ioctls, je pensais qu'ALSA en tant qu'API devrait fournir l'interface pour les entrées et les sorties.

— jones

Voici un exemple de travail sur la manière d'écrire des données pcm directement dans le fichier de périphérique: github.com/igor-liferenko/pcm

— Igor Liferenko

46

Je pense que la raison pour laquelle cela ne fonctionne pas pour vous est que cette interface est obsolète. Normalement, vous ne pouvez plus écrire d’audio /dev/dsp, du moins sans être compliqué.

Il existe un programme qui accomplira pour vous sur votre système: padsp. Cela mappera le fichier /dev/audioou /dev/dsple nouveau système de serveur audio.

Lancez le terminal et passez en mode racine avec sudo su.

Ensuite, je vais diriger cat /dev/urandomla sortie vers padspet utiliser la teecommande pour envoyer les données /dev/audio. Vous aurez une tonne de déchets dans votre terminal, de sorte que vous voudrez peut-être rediriger vers /dev/null.

Une fois que vous êtes dans le superutilisateur, essayez cette commande:

cat /dev/urandom | padsp tee /dev/audio > /dev/null

Vous voudrez peut-être même essayer avec d’autres périphériques, comme votre souris: Utilisez /dev/psaux, par exemple, ou le pilote USB. Vous pouvez même passer votre mémoire à travers elle: /dev/mem

J'espère que cela explique pourquoi cela ne fonctionnait pas auparavant.

Personnellement, j’ai trouvé la souris et la mémoire beaucoup plus intéressantes que de jouer au statique!

— Chris Thomas
source

1

Merci beaucoup! C'est ce que je cherchais. Répondu 7 mois après avoir posté la question! :-)

— jones

3

Il semble que les sudoprivilèges ne sont pas nécessaires pour cela.

— Iyrin

2

Merci beaucoup. J'ai trouvé les binaires étrangement intéressants. des choses comme / usr / bin / ls / usr / bin / gnome-terminal / usr / bin / mysql

— don bright

hmm, étrange, "tee" peut le faire, mais pas "dd of = / dev / audio".

— Jasen

@Jasen dd écrit peut-être trop à la fois. padsp simule / dev / audio pour le rediriger via alsa. dd sans padsp ne verra même pas / dev / audio sauf si l'émulation OSS dans le noyau est activée (et par défaut, ce n'est pas le cas). Et je pense qu’écrire un gros bloc, beaucoup plus grand que les tampons intégrés au pilote, pourrait même échouer.

— Paul Stelian

8

cat /dev/urandom | aplay est la commande à saisir. Si vous n'êtes pas dans le groupe "audio", vous pouvez préfixer aplay avec sudo. Cela n’interfère pas non plus avec les démons (j’exécutais pulseaudioalors que cette commande était active et entendais correctement le "bruit".

EDIT (6 août 2019): Dans une version plus ancienne de la commande, j'avais également un padsp teeproblème entre catet aplay. Maintenant que je travaille réellement sur le terrain, je me rends compte que cela n’a absolument aucun sens. De plus, je sais que la commande mise à jour (celle qui est visible maintenant au début de cette réponse) fonctionne parce que je l'utilise plusieurs fois par jour au travail.

— Paul Stelian
source

6

J'utilise ALSA et "padsp tee" n'est pas nécessaire.

— Geremia

1

Dans mes expériences pulseaudio (et tout ce que Ubuntu utilise lorsque PA est en panne) qui padsp teeétait nécessaire (j’avais alors précisé le 12.04.2), le fait est que vous ne devriez pas essayer de vider les données directement dans des périphériques, même si vous étiez root ( pour autant que je sache, peu de fichiers sont lisibles et ne peuvent pas être écrits dans le dossier / dev), car vous pourriez soit obtenir une erreur (dans le meilleur des cas, ce qui devient plus commun à chaque mise à jour), planter le noyau ou même casser le périphérique, Dans certains cas. Pour ce faire, il convient d’utiliser des éléments non privilégiés, comme aplay (groupe audio ou racine requise, malheureusement). @geremia

— Paul Stelian

C'est drôle comme je vois maintenant que la padsp teechose n'a vraiment aucun sens. Au travail, j'utilise quelque chose de similaire sans cette ligne pour vérifier que j'avance dans l'écriture du pilote audio. Va maintenant mettre à jour ma réponse.

— Paul Stelian

3

Essayez / dev / audio ou l’un des autres périphériques sous / dev / snd. Ce ne sont pas tous des puits de données audio, vous avez peut-être attrapé un mélangeur, un microphone ou autre chose

— Stefan Noack
source

1

Merci pour la réponse. Selon / proc / asound / devices / dev / snd / pcmC0D0p, c’est le bon périphérique pour la lecture audio (d’où le "p")

— jones

1

De plus, je ne suis pas sûr, mais peut-il y avoir plusieurs "fichiers" de dev pour la lecture? Je n'ai pas de '/ dev / audio' Je pense '/ dev / audio' a quelque chose à voir avec les logiciels libres qui sont utilisés sur les anciens noyaux (avant la version 2.5)

— jones

2

Un démon du son (par exemple pulseaudio) détient-il un verrou sur l'appareil? Je pense que vous pouvez savoir si quelque chose d'autre a une poignée dessus via lsof.

— jmtd
source

1

Merci pour la suggestion utile. J'ai eu un chèque, en utilisant grepet lsof. pulseaudioutilise /dev/snd/controlC0mais il n'est pas allumé /dev/snd/pcmC0D0p. J'ai eu une double vérification en allant à /var/lockpour trouver s'il y avait un fichier pour un verrou sur l'appareil. ls -alindique que le dossier est vide. Donc, je suppose qu'il n'y a pas de verrou sur pcmC0D0p

— jones

@jones Garder un verrou sur le contrôle peut suffire à verrouiller l’ensemble de la carte, selon le pilote. (désolé de répondre après 8 ans, maintenant je l’ai appris moi-même)

— Paul Stelian

0

TL; DR: Les paramètres de l'appareil doivent être définis avant de pouvoir lire ou écrire des données dessus.

Pas à pas:

Ouvrez le périphérique PCM. Par exemple: fd = open("/dev/snd/pcmC0D0p", O_RDWR). Après ouverture, le PCM est en OPENétat.
Définir les paramètres avec ioctl(fd, SNDRV_PCM_IOCTL_HW_PARAMS, (struct snd_pcm_hw_params*) p). La structure des paramètres matériels comporte des masques (chaque bit est une valeur) et des intervalles (plage [minimum, maximum]). Les paramètres qui ne sont pas définis doivent être renseignés (tous les bits / valeurs définis pour les masques; plage complète pour les intervalles). Une fois les paramètres matériels définis, le PCM est à l’ SETUPétat. Voir pcm_set_config () de TinyALSA pour le code.

Réglage ACCESS, FORMAT, RATE, CHANNELS, PERIOD_SIZEet PERIODSest suffisante. Les autres paramètres sont des variantes de ceux-ci, sauf BUFFER_SIZEque, dans certains appareils, il est possible de définir un non multiple de PERIOD_SIZE.
Appelez ioctl(fd, SNDRV_PCM_IOCTL_PREPARE)pour préparer le périphérique et les variables d'exécution ALSA. Après cela, le PCM est en PREPAREDétat.
Commencez la lecture (capture) ou l'écriture (lecture).

Une application minimale pour lire ou écrire sur un périphérique PCM aura la plupart de son code autour de la manipulation des paramètres matériels.

— Ricardo Biehl Pasquali
source

Je ne sais pas si la lecture / écriture fonctionne, comme l'aplay utilise (du moins sur le système sur lequel je développe) ioctl (fd, SNDRV_PCM_IOCTL_WRITEI_FRAMES, ...) et non un appel réel write () en lecture. ALSA a-t-il lui-même un wrapper qui prend les points d’entrée en lecture / écriture et les traduit en ioctl?

— Paul Stelian

@ PaulStelian Oui. Voir la définition des opérations de fichier pour pcm . Dans snd_pcm_read()et snd_pcm_write(), les octets sont convertis en images .

— Ricardo Biehl Pasquali