ALSA lib pcm_hw.c:1829:(_snd_pcm_hw_open) Invalid value for card - alsa

I'm currently trying to use the ALSA lib to emit sounds. However, I'm getting this following error:
Setting random seed to 345.
Adding stimulus TestBeep...
ALSA lib pcm_hw.c:1829:(_snd_pcm_hw_open) Invalid value for card
Process Process-1:
Traceback (most recent call last):
File "/usr/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
self.run()
File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File "../soundstimulus.py", line 36, in run_playback_process
raise e
File "../soundstimulus.py", line 32, in run_playback_process
playback_system = ALSAPlaybackSystem(device_name, config, file_dir, control_pipe, log_directory)
File "../alsainterface.py", line 214, in __init__
self.adevice = alsaaudio.PCM(device=device)
alsaaudio.ALSAAudioError: No such device [hw:CARD=SoundCard,DEV=0]
I think I do have a sound card as seen in the following:
$ cat /proc/asound/card0/pcm0p/info
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: ALC269VC Analog
name: ALC269VC Analog
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1
So what does it mean that there is an invalid value for the card? Is there a way I can edit it so that the value is valid?
I'm not sure if the following is relevant, but a lot of the stackOverflow posts suggested OPs run aplay -l.
My result is
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC269VC Analog [ALC269VC Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Related

no audio recorded from alsa loopback device

I've been trying to get an alsa loopback device working (to test an application that reads audio) following the instructions here:
https://sysplay.in/blog/linux/2019/06/playing-with-alsa-loopback-devices/
The device is enabled using:
modeprobe snd-aloop
As can be seen from:
>aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 7/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
I am supposed to be able to play and record audio using:
aplay -D hw:1,0 foo.wav
&
arecord -D hw:1,0 bar.wav
However the audio recorded is completely silent.
This is more visible when I use sox:
AUDIODEV=hw:1,0 play -V foo.wav
AUDIODEV=hw:1,0 rec -V -c 1 -r 8000 bar.wav
As it provides a convenient ascii-art volume indicator:
In:100% 00:10:00.00 [00:00:00.00] Out:4.80M [ =|= ] Clip:0
The loopback device actually creates pairs of devices.
One device is the read end and a separate device is the write end.
What you actually need is:
aplay -D hw:1,0 foo.wav
&
arecord -D hw:1,1 bar.wav
or using sox:
AUDIODEV=hw:1,0 play -V foo.wav
AUDIODEV=hw:1,1 rec -V -c 1 -r 8000 bar.wav
I discovered this by accident when I copied an .asoundrc configuration that worked as below. The asound configuration is not required however:
pcm.loopin {
type plug
slave.pcm "hw:1,0,0"
}
pcm.loopout {
type plug
slave.pcm "hw:1,1,0"
}
See also https://stackoverflow.com/a/58998959/1569204

Record to a pulseaudio stream, and manage switching between streams

I am trying to set up audio card configurations along with pulseaudio, but I am not sure how alsa configuration is exactly done.
Until this point, I was able to use a single card, and select default source and sink as follows, that worked until I needed to mix another stream to my output.
pacmd set-default-source alsa_input.platform-sound.analog-mono
pacmd set-default-sink alsa_output.platform-sound.analog-mono
Now, I am going to use one more sound card, so aplay -l gives:
**** List of PLAYBACK Hardware Devices ****
card 0: cs42888audio [cs42888-audio], device 0: HiFi cs42888-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: wm8960audio [wm8960-audio], device 0: HiFi wm8960-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: wm8960audio [wm8960-audio], device 1: HiFi-ASRC-FE (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: amixaudiosai [amix-audio-sai], device 0: HiFi-AMIX-FE (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: amixaudiosai [amix-audio-sai], device 1: HiFi-AMIX-FE (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
arecord -l gives:
**** List of CAPTURE Hardware Devices ****
card 0: cs42888audio [cs42888-audio], device 0: HiFi cs42888-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: wm8960audio [wm8960-audio], device 0: HiFi wm8960-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: wm8960audio [wm8960-audio], device 1: HiFi-ASRC-FE (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: amixaudiosai [amix-audio-sai], device 0: HiFi-AMIX-FE (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
pactl list short sinks
0 alsa_output.platform-sound-amix-sai.analog-mono module-alsa-card.c s16le 1ch 48000Hz SUSPENDED
2 alsa_output.platform-sound.analog-mono module-alsa-card.c s16le 1ch 48000Hz SUSPENDED
4 alsa_output.platform-sound-cs42888.analog-surround-51 module-alsa-card.c s16le 6ch 48000Hz SUSPENDED
5 my_stream module-null-sink.c s16le 2ch 48000Hz SUSPENDED
pactl list short sources
0 alsa_output.platform-sound-amix-sai.analog-mono.monitor module-alsa-card.c s16le 1ch 48000Hz SUSPENDED
1 alsa_input.platform-sound-amix-sai.analog-mono module-alsa-card.c s16le 1ch 48000Hz SUSPENDED
3 alsa_input.platform-sound-cs42888.analog-mono module-alsa-card.c s16le 1ch 48000Hz SUSPENDED
4 alsa_output.platform-sound.analog-mono.monitor module-alsa-card.c s16le 1ch 48000Hz SUSPENDED
5 alsa_input.platform-sound.analog-mono module-alsa-card.c s16le 1ch 48000Hz SUSPENDED
7 alsa_output.platform-sound-cs42888.analog-surround-51.monitor module-alsa-card.c s16le 6ch 48000Hz SUSPENDED
8 my_stream.monitor module-null-sink.c s16le 2ch 48000Hz SUSPENDED
I would like to use CS42888 device and set up a configuration such as the following:
alsa_input.platform-sound-cs42888.analog-mono (Radio)
(Rate 48000, S16_LE)
|
> alsa_input.platform-sound.analog-mono (Microphone)
| |
| > alsa_input.a2dp_source (Bluetooth Audio, if available)
| | |
| | |
| | | System sounds
| | | |
| | | >
| | | |
| | > |
| | | |
-----------switching stream--------
|
|
>
|
|
alsa_output.platform-sound-cs42888.analog-mono
(Rate 48000, S16_LE)
(profile: output:analog-mono+input:analog-mono)
In other words, I would like to get Radio input, and be able to stream it on top of system sounds, whenever necessary. Also, I would like to achieve this in pulseaudio, since bluetooth audio and other stuff are managed using pulseaudio (module-bluez5-device).
I can get record and play radio input as follows successfully:
arecord -Dplug:hw:cs42888audio -f S16_LE -r 48000 test.wav
aplay -Dplug:hw:cs42888audio -f S16_LE test.wav
How do I set up such a configuration using pulseaudio? I would like to record to a stream and then manage switching between streams. Thanks in advance.

Automatically attaching to process on SEGV and other fatal signals (panic_action)

Background
Code to support a 'panic_action' was recently added to the FreeRADIUS v3.0.x, v2.0.x and master branches.
When radiusd (main FreeRADIUS process) receives a fatal signal (SIGFPE, SIGABRT, SIGSEGV etc...), the signal handler executes a predefined 'panic_action' which is a snippet of shell code passed to system(). The signal handler performs basic substitution for %e and %p writing in the values of the current binary name, and the current PID.
This should in theory allow a debugger like gdb or lldb to attach to the process (panic_action = lldb -f %e -p %p), either to perform interactive debugging, or to automate collection of a backtrace. This actually works well on my system OSX 10.9.2 with lldb, but only for SIGABRT.
Problem
This doesn't seem to work for other signals like SIGSEGV. The mini backtrace from execinfo is valid, but when lldb or gdb attach to the process, they only get the backtrace from for the signal handler.
There doesn't seem to be a way in lldb to switch to an arbitrary frame address.
Does anyone know if there's any way of forcing the signal handler to execute in the same stack as the the thread that received the signal? Or why when lldb attaches the backtraces don't show the full stack.
The actual output looks like:
FATAL SIGNAL: Segmentation fault: 11
Backtrace of last 12 frames:
0 libfreeradius-radius.dylib 0x000000010cf1f00f fr_fault + 127
1 libsystem_platform.dylib 0x00007fff8b03e5aa _sigtramp + 26
2 radiusd 0x000000010ce7617f do_compile_modsingle + 3103
3 libfreeradius-server.dylib 0x000000010cef3780 fr_condition_walk + 48
4 radiusd 0x000000010ce7710f modcall_pass2 + 191
5 radiusd 0x000000010ce7713f modcall_pass2 + 239
6 radiusd 0x000000010ce7078d virtual_servers_load + 685
7 radiusd 0x000000010ce71df1 setup_modules + 1633
8 radiusd 0x000000010ce6daae read_mainconfig + 2526
9 radiusd 0x000000010ce78fe6 main + 1798
10 libdyld.dylib 0x00007fff8580a5fd start + 1
11 ??? 0x0000000000000002 0x0 + 2
Calling: lldb -f /usr/local/freeradius/sbin/radiusd -p 1397
Current executable set to '/usr/local/freeradius/sbin/radiusd' (x86_64).
Attaching to process with:
process attach -p 1397
Process 1397 stopped
(lldb) bt
error: libfreeradius-radius.dylib debug map object file '/Users/arr2036/Documents/Repositories/freeradius-server-fork/build/objs//Users/arr2036/Documents/Repositories/freeradius-server-master/src/lib/debug.o' has changed (actual time is 0x530f3d21, debug map time is 0x530f37a5) since this executable was linked, file will be ignored
* thread #1: tid = 0x8d824, 0x00007fff867fee38 libsystem_kernel.dylib`wait4 + 8, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP
frame #0: 0x00007fff867fee38 libsystem_kernel.dylib`wait4 + 8
frame #1: 0x00007fff82869090 libsystem_c.dylib`system + 425
frame #2: 0x000000010cf1f2e1 libfreeradius-radius.dylib`fr_fault + 849
frame #3: 0x00007fff8b03e5aa libsystem_platform.dylib`_sigtramp + 26
(lldb)
Code
The relevant code for fr_fault() is here:https://github.com/FreeRADIUS/freeradius-server/blob/b7ec8c37c7204accbce4be4de5013397ab662ea3/src/lib/debug.c#L227
and fr_set_signal() the function used to setup signal handlers is here: https://github.com/FreeRADIUS/freeradius-server/blob/0cf0e88704228e8eac2948086e2ba2f4d17a5171/src/lib/misc.c#L61
As the links contain commit hashes the code should be static
EDIT
Finally with version lldb-330.0.48 on OSX 10.10.4 lldb can now go past _sigtram.
frame #2: 0x000000010b96c5f7 libfreeradius-radius.dylib`fr_fault(sig=11) + 983 at debug.c:735
732 FR_FAULT_LOG("Temporarily setting PR_DUMPABLE to 1");
733 }
734
-> 735 code = system(cmd);
736
737 /*
738 * We only want to error out here, if dumpable was originally disabled
(lldb)
frame #3: 0x00007fff8df77f1a libsystem_platform.dylib`_sigtramp + 26
libsystem_platform.dylib`_sigtramp:
0x7fff8df77f1a <+26>: decl -0x16f33a50(%rip)
0x7fff8df77f20 <+32>: movq %rbx, %rdi
0x7fff8df77f23 <+35>: movl $0x1e, %esi
0x7fff8df77f28 <+40>: callq 0x7fff8df794d8 ; symbol stub for: __sigreturn
(lldb)
frame #4: 0x000000010bccb027 rlm_json.dylib`_json_map_proc_get_value(ctx=0x00007ffefa62dbe0, out=0x00007fff543534b8, request=0x00007ffefa62da30, map=0x00007ffefa62aaf0, uctx=0x00007fff54353688) + 391 at rlm_json.c:191
188 }
189 vp = map->op;
190
-> 191 if (value_data_steal(vp, &vp->data, vp->da->type, value) < 0) {
192 REDEBUG("Copying data to attribute failed: %s", fr_strerror());
193 talloc_free(vp);
194 goto error;
This is a bug in lldb related to backtracing through _sigtramp, the asynchronous signal handler in user processes. Unfortunately I can't suggest a workaround for this problem. It has been fixed in the top of tree sources for lldb at http://lldb.llvm.org/ if you're willing to build from source (see the "Source" and "Build" sidebars). But Xcode 5.0 and the next dot release are going to have real problems backtracing past _sigtramp.

How can I see what library owns symbols for an lldb backtrace

I am trying to debug an EXC_BAD_ACCESS but can't tell what was executed using backtrace with lldb. Of course I am missing the debug symbols for those particular frames but I don't know how to figure out what library owns the address. I tried image list --address with the address of the stack frame but that doesn't return anything. Any pointers (no pun intended) would be greatly appreciated. My end goals is to hopefully see the line of code where the the segfault happened. I am doing this from command line and not from xcode btw.
Here is a snapshot of my stacktrace with the missing symbols in case my explanation wasn't making sense.
frame #0: 0x0000000103f7e2dc
frame #1: 0x0000000103f5c3d0
frame #2: 0x0000000103f5c2b3
frame #3: 0x0000000103f5c2b3
frame #4: 0x0000000103f5c2b3
frame #5: 0x0000000103f5c2b3
frame #6: 0x0000000103f5c0d8
frame #7: 0x0000000103f564e7
frame #8: 0x00000001036d6d90 libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 554
frame #9: 0x00000001036d6b60 libjvm.dylib`JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
frame #10: 0x0000000103860580 libjvm.dylib`Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2556
frame #11: 0x00000001038609e6 libjvm.dylib`Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 366
frame #12: 0x00000001037236d7 libjvm.dylib`JVM_InvokeMethod + 358
frame #13: 0x0000000103f6e4b9
frame #14: 0x0000000103f5c2b3
frame #15: 0x0000000103f5c2b3
frame #16: 0x0000000103f5c961
frame #17: 0x0000000103f5c2b3
frame #18: 0x0000000103f5c2b3
frame #19: 0x0000000103f5c2b3
frame #20: 0x0000000103f5c2b3
frame #21: 0x0000000103f5c0d8
frame #22: 0x0000000103f5c0d8
Normally, the name of the library stands next to the address. Since your backtrace shows libjvm, I guess that the frames without further information are JIT-compiled Java code.

linux kernel module dies after 100000 interrupts

I'm working on a kernel module for the 2.6.39 kernel. (I know this is out of date, but it's what came with my evaluation board and I wanted to get this working before moving to the 3.x series.)
My module is very simple at the moment. It listens for a 200us pulse on a GPIO pin, then increments a counter which resets it every 25089 iterations. (25089 is the size of a buffer to be used later.) Strangely enough though, my module dies after exactly 100000 interrupts every time I use it, and I'm really at a loss. I looked at changing the kernel jiffy frequency, but that seems like it's unrelated. I also tried using a tickless kernel, and that doesn't seem to have an effect either. I can't find much of anything on google about this problem either. Has anyone else seen this issue?
I'm building for an Atmel AT91 processor if that is important. I'll list my crash message below.
root#at91:~# irq 56: nobody cared (try booting with the "irqpoll" option)
[<c0036804>] (unwind_backtrace+0x0/0xec) from [<c006eca4>] (__report_bad_irq+0x34/0xa0)
[<c006eca4>] (__report_bad_irq+0x34/0xa0) from [<c006eed0>] (note_interrupt+0x1c0/0x22c)
[<c006eed0>] (note_interrupt+0x1c0/0x22c) from [<c006d904>] (handle_irq_event_percpu+0x168/0x19c)
[<c006d904>] (handle_irq_event_percpu+0x168/0x19c) from [<c006d960>] (handle_irq_event+0x28/0x38)
[<c006d960>] (handle_irq_event+0x28/0x38) from [<c003ace0>] (gpio_irq_handler+0x74/0x98)
[<c003ace0>] (gpio_irq_handler+0x74/0x98) from [<c002b078>] (asm_do_IRQ+0x78/0xac)
[<c002b078>] (asm_do_IRQ+0x78/0xac) from [<c00313d4>] (__irq_svc+0x34/0x60)
Exception stack(0xc04b1f70 to 0xc04b1fb8)
1f60: 00000000 0005317f 0005217f 60000013
1f80: c04b0000 c04b61cc c04b5ffc c04e1224 20000000 41069265 20025cbc 00000000
1fa0: 600000d3 c04b1fb8 c0032cc8 c0032cd4 60000013 ffffffff
[<c00313d4>] (__irq_svc+0x34/0x60) from [<c0032cd4>] (default_idle+0x38/0x40)
[<c0032cd4>] (default_idle+0x38/0x40) from [<c0032af8>] (cpu_idle+0x70/0xc8)
[<c0032af8>] (cpu_idle+0x70/0xc8) from [<c00089c0>] (start_kernel+0x284/0x2e4)
[<c00089c0>] (start_kernel+0x284/0x2e4) from [<20008038>] (0x20008038)
handlers:
[<c01eb660>] (grab_spi_data+0x0/0x6c)
Disabling IRQ #56
root#at91:~# cat /proc/interrupts
CPU0
1: 1387 AIC at91_tick, at91_rtc, ttyS0
12: 39 AIC atmel_mci.0
13: 0 AIC atmel_spi.0
14: 0 AIC atmel_spi.1
17: 1804 AIC tc_clkevt
20: 7520 AIC at_hdmac
21: 0 AIC at_hdmac
22: 1 AIC ehci_hcd:usb1, ohci_hcd:usb2
23: 0 AIC atmel_usba_udc
24: 136 AIC eth0
26: 0 AIC atmel_mci.1
56: 100000 GPIO quicklogic_ready
80: 0 GPIO atmel_usba_udc
142: 0 GPIO mmc-detect
143: 1 GPIO mmc-detect
Err: 0
My interrupt handler is called grab_spi_data, which you can see is that the bottom of the backtrace, and I'm watching IRQ 56. I am really stumped.
Looks like you're not handling the IRQs.
Linux gets upset after 100,000 times - See the comment above __report_bad_irq and find this magic number.
Your interrupt handler probably never returns IRQ_HANDLED, which is what it should do after handling the interrupt.

Resources