I am trying alsa speaker-test utility after playing a .mp3 file using gst-play-1.0 in my customized Linux Os.but the speaker-test utility is unable to produce the sound over any channel and its producing a following error message given below.
speaker-test -p 1000 -t wav -c 6 -s 6
speaker-test 1.2.1
Playback device is default
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Playback open error: -16,Device or resource busy.
Based on my analysis, I found that the audio card/device "/dev/snd/pcmC0D0p" was used by gst-play-1.0 and its is not released even after gst-play-1.0 command execution.
I could see the result of lsof /dev/snd/* as
root 29u CHR 116,16 0t0 13359 /dev/snd/pcmC0D0p
Is anyone know how to release this resource so that I can use it for speaker-test ?
Your device is busy and your lsof shows about a process using the device, just that doesn't seems to indicate the exact command where this comes. Probably because of the CoreUtils your custom Linux uses for these tools, in this case lsof. Otherwise you will have a little more info, some output similar to this one:
$ lsof /dev/video*
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
gst-launc 20425 my-user 5u CHR 81,0 0t0 606 /dev/video0
As your lsof seems to indicate that someone is using that device, let's suppose it is an instance of speaker-test. So that you can just do a process search and kill that process to free the device; rerun lsof and see if the device is now available. If it is try again with your sound test!
ps aux | grep speaker
kill -9 <PID for Speaker>
lsof /dev/snd/*
Related
Edit: All of this was probably caused by a terribly configured microphone (or a faulty one, I changed laptops and now use Ubuntu instead of Arch Linux, so I actually don't have any idea). To record to a wav file, all I do now is run:
arecord -d $DURATION -f cd -t wav $OUTPUT_FILE_PATH
...replacing $DURATION with the duration of the recording in seconds, and $OUTPUT_FILE_PATH with the path to the desired file to write. I omitted the -D sysdefault argument as it caused problems for me (as with most things, your mileage may vary, so if the command doesn't work for you, try playing with several variables until it works).
Goes without saying, but all of this requires alsa-utils to be installed.
(The original question is left below, for those that still want to see it.)
Tl;dr version: arecord not recognizing plughw:1,0 , nor hw:1,0 , nor anything without the -D option
Whole story: I'm trying to make a simple voice assistant using a Bash script (I don't find Python/Perl easy for me to use, but that's just me). Dialogs are made in Zenity/KDialog. Voice recognition isn't included yet, so one has to type in the phrase/command. For now the program is represented in Spanish, but I plan to have an English version as well.
Doing my research, I found: http://blog.oscarliang.net/raspberry-pi-voice-recognition-works-like-siri/
But it doesn't work correctly on my machine.
[owner#arch-hp-2000-notebook-pc ~]$ ~/test-speech-input
“Recording… Press Ctrl+C to Stop.”
ALSA lib pcm.c:2267:(snd_pcm_open_noupdate) Unknown PCM “plughw:1,0″
arecord: main:722: audio open error: No such file or directory
“Processing…”
^C
[owner#arch-hp-2000-notebook-pc ~]$
It apparently has to do with the arecord -D "plughw:1,0" -q -f cd -t wav part.
Output of arecord -l:
[owner#arch-hp-2000-notebook-pc ~]$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: Generic_1 [HD-Audio Generic], device 0: ALC269VC Analog [ALC269VC Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
Output of arecord -L:
[owner#arch-hp-2000-notebook-pc ~]$
null
Discard all samples (playback) or generate zero samples (capture)
pulse
PulseAudio Sound Server
default
Default ALSA Output (currently PulseAudio Sound Server)
sysdefault:CARD=Generic_1
HD-Audio Generic, ALC269VC Analog
Default Audio Device
front:CARD=Generic_1,DEV=0
HD-Audio Generic, ALC269VC Analog
Front speakers
surround21:CARD=Generic_1,DEV=0
HD-Audio Generic, ALC269VC Analog
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Generic_1,DEV=0
HD-Audio Generic, ALC269VC Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=Generic_1,DEV=0
HD-Audio Generic, ALC269VC Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Generic_1,DEV=0
HD-Audio Generic, ALC269VC Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Generic_1,DEV=0
HD-Audio Generic, ALC269VC Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Generic_1,DEV=0
HD-Audio Generic, ALC269VC Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
[owner#arch-hp-2000-notebook-pc ~]$
Following the first part of the answer by #CharlesDuffy (thanks for the help):
[owner#arch-hp-2000-notebook-pc ~]$ ~/test-speech-input
Recording… Press Ctrl+C to Stop.
Processing…
You Said: [owner#arch-hp-2000-notebook-pc ~]$
Following the new answer, also by #CharlesDuffy (although this system is all AMD I think, no intel):
[owner#arch-hp-2000-notebook-pc ~]$ test-speech-input
Recording… Press Ctrl+C to Stop.
ALSA lib pcm.c:2267:(snd_pcm_open_noupdate) Unknown PCM CARD=Generic_1
arecord: main:722: audio open error: No such file or directory
Processing…
You Said: [owner#arch-hp-2000-notebook-pc ~]$
Following the newest answer by #CharlesDuffy:
[owner#arch-hp-2000-notebook-pc ~]$
Recording… Press Ctrl+C to Stop.
ALSA lib pcm_dsnoop.c:614:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:722: audio open error: No such file or directory
Processing…
^C
[owner#arch-hp-2000-notebook-pc ~]$
Double-checked the volume of the internal mic, and it seemed to have selected a non-existent mic. Switching to the real mic yielded the same results.
I'm lost right now. Any other ideas? Is there any other command-line voice recording tool that might work or that might be easier to use (at least for me)?
Machine: HP 2000 Notebook PC, Arch Linux, uname -a returns Linux HOST_NAME 4.1.2-2-ARCH #1 SMP PREEMPT Wed Jul 15 08:30:32 UTC 2015 x86_64 GNU/Linux
The plughw:1,0 suggestion is specific to Raspberry Pi hardware, and doesn't necessarily apply elsewhere.
The first thing I'd suggest is removing the -D DEVICE argument entirely.
If that doesn't work, I'd suggest trying:
-D sysdefault
...for your basic on-board audio, as listed by arecord -L.
I was wondering what possibilities are available to detect a connection on a tty. My goal is to create an alert in case someone tries to watch what I am doing through the console
First I though about who, which allows to see wether someone is connected and on what tty, but let's say this user isn't logged in, is there still a way of detecting that a tty is opened? Maybe with /dev/tty? Or is it possible to know how many file descriptors are pointing to the file /dev/console and what processes are using the hardware/io? Or maybe using hardware detection with vcs? I actually have no idea how to use/test those.
let's say this user isn't logged in
Each process belongs to some user. The only way to run some code and not being logged in is to write this code in kernel.
I was wondering what possibilities are available to detect a connection on a tty
Try this:
$ lsof /dev/tty0
lsof is a tool for observe open files.
For example, serial console for my development board is /dev/ttyUSB0. So I opened minicom session and also made cat for my TTY file:
$ minicom -D /dev/ttyUSB0
$ cat /dev/ttyUSB0
and checked this:
$ lsof /dev/ttyUSB0
which gave me:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
minicom 13299 joe 3u CHR 188,0 0t0 135832 /dev/ttyUSB0
cat 13310 joe 3r CHR 188,0 0t0 135832 /dev/ttyUSB0
From this output you can figure out, who (USER) connected to your TTY, and whic program he used (COMMAND, PID).
After closing minicom session and cat, lsof doesn't print anything.
Also it can be done using w command:
$ w | grep ttyUSB0
Output:
joe pts/2 :0 17:57 2:47 0.12s 0.00s minicom -D /dev/ttyUSB0
joe pts/3 :0 17:58 2:39 0.08s 0.00s cat /dev/ttyUSB0
UPDATE
If you don't want to be watched in the way described above (i.e. via open descriptor), you can do next.
Let's say you are using /dev/ttyUSB0. To connect to your console via this file, you must open it first (no matter which way, e.g. using cat or minicom etc.). Once you have opened it, your session can be seen by other users (e.g. by root) just looking if there are open file descriptors for that file (lsof /dev/ttyUSB0).
Now, TTY devices are just character devices, and you can create your own files (nodes) for those devices. Let's see closely to /dev/ttyUSB0 file:
$ ls -l /dev/ttyUSB0
Output:
crw-rw---- 1 root dialout 188, 0 Mar 4 16:07 /dev/ttyUSB0
Here c indicates that this is character device, and we can see that it has major number 188 and minor number 0. Let's create our own node (file) for this device.
$ cd /tmp
$ sudo mknod some_tricky_name c 188 0
$ sudo chown root:dialout some_tricky_name
$ sudo chmod 644 some_trickyname
Now you can connect to this file instead of /dev/ttyUSB0 and nobody's gonna see you:
$ minicom -D /tmp/some_tricky_name
Still, if you are gonna run some shell in this TTY, good administrator still can catch you, looking to /var/log/auth.log. But I believe this technique prevents you from being caught using w or lsof commands.
Getting status of serial ports (ttyS*) via linux terminal is simple:
sudo cat /proc/tty/driver/serial
Then it shows serinfo with list of all uarts with info about status and buffers. When I call
sudo cat /proc/tty/drivers
then I can see that rfcomm drivers are available:
rfcomm /dev/rfcomm 216 0-255 serial
And, of course, reading data comming from paired bluetooth device is not a problem.
The question is: how to get status of rfcomm serial ports (e.g. Blueotooth SPP devices)? Is this information available somewhere in the /proc directory like for ttyS* or could I use totally different way?
It depends what status you are looking for. The "rfcomm" command that comes with bluez does have some status info. It depends if that is adequate for you.
% rfcomm -h
RFCOMM configuration utility ver 4.101
Usage:
rfcomm [options] <command> <dev>
Options:
-i [hciX|bdaddr] Local HCI device or BD Address
-h, --help Display help
-r, --raw Switch TTY into raw mode
-A, --auth Enable authentication
-E, --encrypt Enable encryption
-S, --secure Secure connection
-M, --master Become the master of a piconet
-f, --config [file] Specify alternate config file
-a Show all devices (default)
Commands:
bind <dev> <bdaddr> [channel] Bind device
release <dev> Release device
show <dev> Show device
connect <dev> <bdaddr> [channel] Connect device
listen <dev> [channel [cmd]] Listen
watch <dev> [channel [cmd]] Watch
i am totally new to pulse audio and alsa. the situation is this:
i have mpd compiled for alsa. this is embedded system and pulse audio plugin for mpd is not available.
when i DO NOT start pulse audio, mpd runs fine using alsa
as soon as i start pulse audio [ which is needed by bluetooth audio unfortunately ] , mpd / alsa stops working .
seems like, somehow pulse audio is grabbing the device and not letting it go . even after i stop pulse audio daemon .
Trying to run mpd afterwards gives me:
root#FINGI_GCC:~# mpc play
http://relay3.slayradio.org:8000/
[paused] #1/1 0:00/0:00 (0%)
volume:100% repeat: off random: off single: off consume: off
ERROR: problems opening audio device
So i was wondering how to reset pulse audio ? need to keep running pulse audio,mpd,alsa all on the same device..but not all at the same time.
Any suggestion on this?
Assuming this audio device in in /dev/snd/, you could try to see which process is holding it with:
lsof /dev/snd/*
Then you could try to kill this process.
For instance when I'm running alsamixer, I get:
$ lsof /dev/snd/*
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
...
alsamixer 7152 emilien 3u CHR 116,5 0t0 10154 /dev/snd/controlC0
...
I'm trying to figure out what process is holding the other end of a unix domain socket. In some strace output I've identified a given file descriptor which is involved in the problem I'm currently debugging, and I'd like to know which process is on the other end of that. As there are multiple connections to that socket, simply going by path name won't work.
lsof provides me with the following information:
dbus-daem 4175 mvg 10u unix 0xffff8803e256d9c0 0t0 12828 #/tmp/dbus-LyGToFzlcG
So I know some address (“kernel address”?), I know some socket number, and I know the path. I can find that same information in other places:
$ netstat -n | grep 12828
unix 3 [ ] STREAM CONNECTED 12828 #/tmp/dbus-LyGToFzlcG
$ grep -E '12828|ffff8803e256d9c0' /proc/net/unix
ffff8803e256d9c0: 00000003 00000000 00000000 0001 03 12828 #/tmp/dbus-LyGToFzlcG
$ ls -l /proc/*/fd/* 2>/dev/null | grep 12828
lrwx------ 1 mvg users 64 10. Aug 09:08 /proc/4175/fd/10 -> socket:[12828]
However, none of this tells me what the other end of my socket connection is. How can I tell which process is holding the other end?
Similar questions have been asked on Server Fault and Unix & Linux. The accepted answer is that this information is not reliably available to the user space on Linux.
A common suggestion is to look at adjacent socket numbers, but ls -l /proc/*/fd/* 2>/dev/null | grep 1282[79] gave no results here. Perhaps adjacent lines in the output from netstat can be used. It seems like there was a pattern of connections with and without an associated socket name. But I'd like some kind of certainty, not just guesswork.
One answer suggests a tool which appears to be able to address this by digging through kernel structures. Using that option requires debug information for the kernel, as generated by the CONFIG_DEBUG_INFO option and provided as a separate package by some distributions. Based on that answer, using the address provided by lsof, the following solution worked for me:
# gdb /usr/src/linux/vmlinux /proc/kcore
(gdb) p ((struct unix_sock*)0xffff8803e256d9c0)->peer
This will print the address of the other end of the connection. Grepping lsof -U for that number will provide details like the process id and the file descriptor number.
If debug information is not available, it might be possible to access the required information by knowing the offset of the peer member into the unix_sock structure. In my case, on Linux 3.5.0 for x86_64, the following code can be used to compute the same address without relying on debugging symbols:
(gdb) p ((void**)0xffff8803e256d9c0)[0x52]
I won't make any guarantees about how portable that solution is.
Update: It's been possible to to do this using actual interfaces for a while now. Starting with Linux 3.3, the UNIX_DIAG feature provides a netlink-based API for this information, and lsof 4.89 and later support it. See https://unix.stackexchange.com/a/190606/1820 for more information.