Generazione di rumore casuale per divertimento in / dev / snd /

41

Recentemente ho esplorato la cartella / dev incantata. Voglio scrivere alcuni dati casuali su un dispositivo audio per generare del rumore.

Sto usando ALSA.

Quindi chiedo a cat di reindirizzare alcuni dati casuali al file di riproduzione nella cartella / dev ...

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

poi ricevo quello che sembra essere un errore dal gatto

 cat: write error: File descriptor in bad state

Come posso risolvere questo problema in modo da poter ascoltare un delizioso gioco statico dalla mia scheda audio?

audio alsa

— jones
fonte

1

Penso che tu debba inviare dati PCM casuali , o forse devi prima configurare il dispositivo con alcuni ioctls - non puoi semplicemente scaricare byte casuali.

— Gilles 'SO- smetti di essere malvagio'

@Gilles Secondo Wikipedia, .wav è PCM e ottengo esattamente lo stesso risultato quando sostituisco il file casuale con un file .wav. Esaminerò l'impostazione di alcuni controlli in / out.

— jones,

Qualcuno ha un puntatore per un tutorial su come impostare alcuni ioctls? Per qualcosa chiamato ioctls, ho pensato che ALSA come API dovesse fornire l'interfaccia per input e output?

— jones,

Ecco un esempio funzionante su come scrivere i dati pcm direttamente nel file del dispositivo: github.com/igor-liferenko/pcm

— Igor Liferenko

46

Penso che il motivo per cui questo non funziona per te sia perché quell'interfaccia è stata deprecata. Normalmente non puoi più scrivere audio usando /dev/dsp, almeno senza essere complicato.

C'è un programma che compirà questo per voi sul vostro sistema: padsp. Questo mapperà il file /dev/audioo /dev/dspsul nuovo sistema Audio Server.

Accendi il terminale ed entra in modalità root con sudo su.

Quindi, andrò a cat /dev/urandomreindirizzare l'output padspe utilizzare il teecomando a cui inviare i dati /dev/audio. Avrai un sacco di immondizia nel tuo terminale, quindi potresti voler reindirizzare a /dev/null.

Una volta che sei in superutente, prova questo comando:

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

Potresti anche provare con altri dispositivi, come il tuo mouse: Usa /dev/psaux:, ad esempio o il driver USB. Puoi anche far scorrere la tua memoria attraverso di essa: /dev/mem

Spero che questo chiarisca perché non funzionava prima.

Personalmente, ho trovato il mouse e la memoria molto più interessanti rispetto alla riproduzione di dati statici casuali!

— Chris Thomas
fonte

1

Molte grazie! Questo è quello che stavo cercando. Ha risposto per ben 7 mesi dopo aver pubblicato la domanda! :-)

— jones

3

Sembra che i sudoprivilegi non siano richiesti per questo.

— iyrin,

2

grazie mille. ho trovato che i binari sono stranamente interessanti. cose come / usr / bin / ls / usr / bin / gnome-terminal / usr / bin / mysql

— don bright

hmm, strano, 'tee' può farlo ma 'dd of = / dev / audio' non può farlo.

— Jasen,

@Jasen dd potrebbe scrivere troppo alla volta. padsp simula / dev / audio per reindirizzarlo tramite alsa. dd senza padsp non vedrà nemmeno / dev / audio a meno che l'emulazione OSS nel kernel sia abilitata (e di default non lo è). E penso che scrivere un blocco di grandi dimensioni, molto più grande dei buffer nel driver, potrebbe anche fallire.

— Paul Stelian,

8

cat /dev/urandom | aplay è il comando che deve essere digitato. Se non fai parte del gruppo "audio", puoi aggiungere il prefisso aplay con sudo. Anche questo non interferisce con nessun demone (stavo correndo pulseaudiomentre questo comando era attivo e ho sentito correttamente il "rumore".

EDIT (6 Agosto 2019): In una vecchia versione del comando ho anche avuto una padsp teecosa tra il cate aplay. Ora che sto effettivamente lavorando sul campo, mi rendo conto che non ha assolutamente senso. Inoltre, so che il comando aggiornato (quello visibile ora all'inizio di questa risposta) funziona perché lo uso più volte al giorno al lavoro.

— Paul Stelian
fonte

6

Uso ALSA e "padsp tee" non è necessario.

— Geremia,

1

Nelle mie esperienze pulseaudio (e qualunque cosa Ubuntu stia usando quando PA è inattivo) che padsp teeera necessario (avevo 12.04.2 preciso in quel momento) Il fatto è che non dovresti provare a scaricare i dati direttamente nei dispositivi, anche se eri root ( per quanto ne so pochi file sono leggibili e nessuno è scrivibile nella cartella / dev), perché potresti ottenere un errore (nel migliore dei casi, che diventa più comune con ogni aggiornamento), bloccare il kernel o persino rompere il dispositivo, in rari casi. Si dovrebbe usare elementi non privilegiati, come aplay, per fare questo (purtroppo è richiesto il gruppo audio o il root). @geremia

— Paul Stelian

Divertente come ora vedo che la padsp teecosa in realtà non ha alcun senso. Al lavoro uso qualcosa di simile senza quella riga per testare che sto facendo progressi con la scrittura del driver audio. Ora aggiornerò la mia risposta.

— Paul Stelian,

3

Prova / dev / audio o uno degli altri dispositivi in / dev / snd. Non tutti sono lavandini di dati audio, potresti aver catturato un mixer, un microfono o qualcosa del genere

— Stefan Noack
fonte

1

Grazie per la risposta. Secondo / proc / asound / devices / dev / snd / pcmC0D0p è il dispositivo giusto per la riproduzione audio (da qui la 'p')

— jones

1

Inoltre, non sono sicuro, ma possono esserci più "file" di sviluppo per la riproduzione? Io non ho un '/ dev / audio' Credo '/ dev / audio' ha qualcosa a che fare con OSS che viene utilizzato su vecchi kernel (prima 2.5)

— jones

2

Un demone audio (ad es. pulseaudio) Tiene un lucchetto sul dispositivo? Penso che puoi scoprire se qualcos'altro ha una maniglia su di esso tramite lsof.

— jmtd
fonte

1

Grazie per il suggerimento utile. Ho fatto un controllo, usando grepe lsof. pulseaudiosta usando /dev/snd/controlC0ma non è acceso /dev/snd/pcmC0D0p. Ho fatto un doppio controllo andando a /var/lockscoprire se c'era un file per un blocco sul dispositivo. ls -aldice che la cartella è vuota. Quindi suppongo che non ci sia alcun blocco su pcmC0D0p

— jones

@jones Tenere un blocco sul controllo può essere sufficiente per bloccare l'intera scheda, a seconda del driver. (scusa per la risposta dopo 8 anni, ora l'ho imparato da solo)

— Paul Stelian il

0

TL; DR: i parametri del dispositivo devono essere impostati prima di leggere o scrivere dati su di esso.

Passo dopo passo:

Apri il dispositivo PCM. Ad esempio: fd = open("/dev/snd/pcmC0D0p", O_RDWR). Dopo l'apertura, PCM è nello OPENstato.
Impostare i parametri con ioctl(fd, SNDRV_PCM_IOCTL_HW_PARAMS, (struct snd_pcm_hw_params*) p). La struttura dei parametri hardware ha maschere (ogni bit è un valore) e intervalli ( intervallo [minimo, massimo]). I parametri che non vengono impostati devono essere passati riempiti (tutti i bit / valori impostati per le maschere; intervallo completo per gli intervalli). Dopo aver impostato i parametri hardware, PCM è nello SETUPstato. Vedi pcm_set_config () di TinyALSA per il codice.

Impostazione ACCESS, FORMAT, RATE, CHANNELS, PERIOD_SIZEed PERIODSè sufficiente. Gli altri parametri sono varianti di questi, tranne per il fatto BUFFER_SIZEche in alcuni dispositivi può essere impostato un non multiplo di PERIOD_SIZE.
Chiama ioctl(fd, SNDRV_PCM_IOCTL_PREPARE)per preparare le variabili di runtime del dispositivo e ALSA. Successivamente, il PCM è nello PREPAREDstato.
Inizia a leggere (acquisire) o scrivere (riproduzione).

Un'applicazione minima per la lettura o la scrittura su un dispositivo PCM avrà la maggior parte del suo codice relativo alla manipolazione dei parametri hardware.

— Ricardo Biehl Pasquali
fonte

Non sono sicuro che l'effettiva lettura / scrittura funzioni, poiché aplay utilizza (almeno sul sistema su cui sto sviluppando) ioctl (fd, SNDRV_PCM_IOCTL_WRITEI_FRAMES, ...) e non una chiamata write () effettiva sulla riproduzione. ALSA stesso ha un wrapper che prende i punti di ingresso in lettura / scrittura e li traduce in ioctl?

— Paul Stelian,

@PaulStelian Sì. Vedere la definizione delle operazioni sui file per pcm . In snd_pcm_read()e snd_pcm_write(), i byte vengono convertiti in frame .

— Ricardo Biehl Pasquali,