Hi Ivan,
excellent investigation. I must admit that I don't know what could've gone wrong there,
because if the program flow reaches the point at which it can throw that error,
https://github.com/gnuradio/gnuradio/blob/0425a9c9b5b4934fdab89812bce315e2f47d9956/gr-audio/lib/alsa/alsa_sink.cc#L175-L178
the setting of the sample rate must have already worked. Maybe the ALSA sink is expecting
things that aren't true for your PCM device? Maybe the PCM device is strrange? Hard to
tell, not enough of an internals expert for ALSA, to be honest. Hm.
I'd propose this:
1. we do a quick sanity check on the demand on the length of the period with a
debugger
2. we try whether the portaudio wrapper around ALSA is smarter than the
alsa_sink itself.
So, diving straight in:
1. debugging
you have your C++ program, awesome, that makes a lot of things easier.
Install gdb, and debugging symbols for GNU Radio and ALSA (I'm not sure whether Arch does
that automatically, or supports debuginfod?); then run
gdb --args ./yourprogram [arguments if any]
on the gdb shell
(gdb) start
(gdb) break snd_pcm_hw_params_set_periods
(gdb) continue
… you wait until it hits the point at which we call into snd_pcm_hw_params_set_periods;
you should see something like
Thread 1 "dial_tone" hit Breakpoint 2, snd_pcm_hw_params_set_periods
(pcm=0x47a9b0, params=0x423360, val=32, dir=0) at pcm/pcm.c:5601
What's the value of "val" for you?
we can also explicitly print d_nperiods, min_nperiods, and max_nperiods
(gdb) frame 1
(gdb) printf "max: %d, min: %d; d_: %d\n", max_nperiods, min_nperiods,
d_nperiods
Hope these numbers make sense?
2. trying whether portaudio sets up ALSA "smarter"
run
gnuradio-config-info --userprefsdir
and make a new file in that directory, let's call it "use_portaudio.conf", with
the content
[audio]
audio_module=portaudio
and try again to run your Python or C++ flowgraph.
Hope this gets us closer to a solution!
Best regards,
Marcus
On 01.05.24 15:51, Ivan wrote:
Hey, everybody.
I am just starting to try GNUradio and I am facing some difficulties. Maybe someone can
comment and suggest a direction to find an answer to my question.
I have GNUradio 3.10.9.2 installed on ArchLinux; in gnuradio-companion I created a
simple flowgraph: noise source -> throttle -> audio sink.
My problem is that if I specify as device name my device in audio sink, the start of the
flowgraph fails:
--------
File “/home/user/gnuradio/alsa1.py”, line 70, in __init__
self.audio_sink_0 = audio.sink(48000, 'k15', True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: audio_alsa_sink
--------
I'll clarify at this point that the name of the ALSA device, k15, is defined in
~/.asoundrc and the device itself is a software audio resampler implemented in the ALSA
subsystem, that's how it's defined:
pcm.k15 {
type rate
slave {
pcm default
rate 48000
}
converter “samplerate_linear”
}
This device takes an audio stream, resamples it to 48000 and sends it to the sound
controller with a sampling rate of 48000 allowed for it.
This device works great when using different programs, like aplay, with different sample
rates and parameters, example:
aplay -D k15 -c 1 -r 10000 -f S32_LE /dev/urandom (sound mono, sample rate 10000, format
S32_LE).
But it doesn't work with GNUradio.
Can anyone suggest what could be the reason for the error of working with this sound
device ?
Another thing: if I compile the flowgraph into C++ and then into an executable file, the
error looks like this:
audio_alsa_sink :error: [k15]: set_periods failed: Invalid argument
Thank you.
