Re: ALSAPulseAudio procedure
You might be interested in my revisions to the https://wiki.gnuradio.org/index.php/ALSAPulseAudio page. Best wishes. --- Barry Duggan KV4FV On 7/5/20 8:29 PM, Cinaed Simson wrote: Okay, I stand corrected - I've only tried to use once about a couple of years ago. If I can't open a GRC in email then I don't look at it. I'm lazy. On 7/3/20 4:02 AM, Barry Duggan wrote: Cinaed, Just as one has to do with getting a file from Github, you have to click on the 'Raw' button before you copy the file with your text editor. Once you do that, you will have the correct format. I don't download individual files from github either - I just copy the URL and do a git clone on my desktop. For good measure, attached is the grc file. Thanks! BTW, Ryan gave me the info I needed about the PulseAudio page. Barry Duggan KV4FV On 7/3/20 4:28 AM, Cinaed Simson wrote: Hi Barry - the GRC isn't an image or binary file - it's a text based XML file. Send it as an attachment to your email. If I recall correctly, uploading a GRC file to pastbin.com and then downloading it destroys the flow graph (the XML formatting) and reduces the GRC flowgraph to a stack of text from the blocks. Try it. -- Cinaed On 7/2/20 4:26 AM, Barry Duggan wrote: Hi Cinaed, The Pluto_NFM.grc is in https://pastebin.com/XZN0dK6x I have found that reducing the buffer size on the Pluto almost eliminated the audio underruns. So what I am left with is needing to know what is wrong with the procedure in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system I have been doing a lot of documentation updates and would like to correct / improve that page. Thanks for your help. --- Barry Duggan KV4FV On 7/1/20 4:53 PM, Cinaed Simson wrote: Hi Barry - can you post the GRC file (no images please) for when the audio doesn't work correctly? -- Cinaed On 7/1/20 5:43 AM, Barry Duggan wrote: Hi Cinaed, Thank you for your response. Yes, I have tried those and the "hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained that from the 'aplay -L' command. Let me reiterate my request: In exploring the audio problems, I followed the instructions in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system and it gave the error I cited. So what I want to know is: Did I do something wrong, or is the procedure not correct? I need someone who is familiar with the ALSA and PulseAudio software to look at this. Thanks. .
Re: ALSAPulseAudio procedure
Okay, I stand corrected - I've only tried to use once about a couple of years ago. If I can't open a GRC in email then I don't look at it. I'm lazy. On 7/3/20 4:02 AM, Barry Duggan wrote: Cinaed, Just as one has to do with getting a file from Github, you have to click on the 'Raw' button before you copy the file with your text editor. Once you do that, you will have the correct format. I don't download individual files from github either - I just copy the URL and do a git clone on my desktop. For good measure, attached is the grc file. Thanks! BTW, Ryan gave me the info I needed about the PulseAudio page. Barry Duggan KV4FV On 7/3/20 4:28 AM, Cinaed Simson wrote: Hi Barry - the GRC isn't an image or binary file - it's a text based XML file. Send it as an attachment to your email. If I recall correctly, uploading a GRC file to pastbin.com and then downloading it destroys the flow graph (the XML formatting) and reduces the GRC flowgraph to a stack of text from the blocks. Try it. -- Cinaed On 7/2/20 4:26 AM, Barry Duggan wrote: Hi Cinaed, The Pluto_NFM.grc is in https://pastebin.com/XZN0dK6x I have found that reducing the buffer size on the Pluto almost eliminated the audio underruns. So what I am left with is needing to know what is wrong with the procedure in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system I have been doing a lot of documentation updates and would like to correct / improve that page. Thanks for your help. --- Barry Duggan KV4FV On 7/1/20 4:53 PM, Cinaed Simson wrote: Hi Barry - can you post the GRC file (no images please) for when the audio doesn't work correctly? -- Cinaed On 7/1/20 5:43 AM, Barry Duggan wrote: Hi Cinaed, Thank you for your response. Yes, I have tried those and the "hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained that from the 'aplay -L' command. Let me reiterate my request: In exploring the audio problems, I followed the instructions in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system and it gave the error I cited. So what I want to know is: Did I do something wrong, or is the procedure not correct? I need someone who is familiar with the ALSA and PulseAudio software to look at this. Thanks. .
Re: ALSAPulseAudio procedure
Cinaed,
Just as one has to do with getting a file from Github, you have to click
on the 'Raw' button before you copy the file with your text editor. Once
you do that, you will have the correct format.
For good measure, attached is the grc file.
BTW, Ryan gave me the info I needed about the PulseAudio page.
Barry Duggan KV4FV
On 7/3/20 4:28 AM, Cinaed Simson wrote:
Hi Barry - the GRC isn't an image or binary file - it's a text based XML
file.
Send it as an attachment to your email.
If I recall correctly, uploading a GRC file to pastbin.com and then
downloading it destroys the flow graph (the XML formatting) and reduces
the GRC flowgraph to a stack of text from the blocks.
Try it.
-- Cinaed
On 7/2/20 4:26 AM, Barry Duggan wrote:
Hi Cinaed,
The Pluto_NFM.grc is in https://pastebin.com/XZN0dK6x I have found
that reducing the buffer size on the Pluto almost eliminated the audio
underruns.
So what I am left with is needing to know what is wrong with the
procedure in
https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system
I have been doing a lot of documentation updates and would like to
correct / improve that page.
Thanks for your help.
---
Barry Duggan KV4FV
On 7/1/20 4:53 PM, Cinaed Simson wrote:
Hi Barry - can you post the GRC file (no images please) for when the
audio doesn't work correctly?
-- Cinaed
On 7/1/20 5:43 AM, Barry Duggan wrote:
Hi Cinaed,
Thank you for your response. Yes, I have tried those and the
"hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained
that from the 'aplay -L' command.
Let me reiterate my request: In exploring the audio problems, I
followed the instructions in
https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system
and it gave the error I cited. So what I want to know is: Did I do
something wrong, or is the procedure not correct?
I need someone who is familiar with the ALSA and PulseAudio software
to look at this.
Thanks.
.
options:
parameters:
author: ''
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: ''
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: Pluto_NFM
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: Pluto 2 meter NB FM
window_size: (1536,1024)
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [16, 12.0]
rotation: 0
state: enabled
blocks:
- name: rf_decim
id: variable
parameters:
comment: ''
value: '5'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [272, 12.0]
rotation: 0
state: true
- name: rf_gain
id: variable_qtgui_range
parameters:
comment: ''
gui_hint: ''
label: RF Gain
min_len: '200'
orient: Qt.Horizontal
rangeType: float
start: '0'
step: '1'
stop: '70'
value: '50'
widget: slider
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [504, 12.0]
rotation: 0
state: true
- name: samp_rate
id: variable
parameters:
comment: ''
value: '192'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [184, 12.0]
rotation: 0
state: enabled
- name: sq_lvl
id: variable_qtgui_range
parameters:
comment: ''
gui_hint: ''
label: Squelch
min_len: '200'
orient: Qt.Horizontal
rangeType: float
start: '-100'
step: '5'
stop: '0'
value: '-50'
widget: counter_slider
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [624, 12.0]
rotation: 0
state: enabled
- name: tuning
id: variable_qtgui_range
parameters:
comment: ''
gui_hint: ''
label: Tuning
min_len: '200'
orient: Qt.Horizontal
rangeType: float
start: 144.0e6
step: 1.0e3
stop: 148.0e6
value: 146.94e6
widget: counter_slider
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [360, 12.0]
rotation: 0
state: enabled
- name: volume
id: variable_qtgui_range
parameters:
comment: ''
gui_hint: ''
label: Volume
min_len: '200'
orient: Qt.Horizontal
rangeType: float
start: '0'
step: '0.1'
stop: '1.00'
value: '0.3'
widget: slider
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [744, 12.0]
rotation: 0
state: enabled
- name: analog_nbfm_rx_0
id: analog_nbfm_rx
parameters:
affinity: ''
alias: ''
audio_rate: '48000'
comment: ''
max_dev: 5e3
maxoutbuf: '0'
minoutbuf: '0'
quad_rate: (int)(samp_rate/
Re: ALSAPulseAudio procedure
There's nothing wrong with the flow graph Barry posted to pastbin. GNU Radio 3.8 uses YAML instead of XML. Ron On 7/3/20 02:28, Cinaed Simson wrote: Hi Barry - the GRC isn't an image or binary file - it's a text based XML file. Send it as an attachment to your email. If I recall correctly, uploading a GRC file to pastbin.com and then downloading it destroys the flow graph (the XML formatting) and reduces the GRC flowgraph to a stack of text from the blocks. Try it. -- Cinaed On 7/2/20 4:26 AM, Barry Duggan wrote: Hi Cinaed, The Pluto_NFM.grc is in https://pastebin.com/XZN0dK6x I have found that reducing the buffer size on the Pluto almost eliminated the audio underruns. So what I am left with is needing to know what is wrong with the procedure in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system I have been doing a lot of documentation updates and would like to correct / improve that page. Thanks for your help. --- Barry Duggan KV4FV On 7/1/20 4:53 PM, Cinaed Simson wrote: Hi Barry - can you post the GRC file (no images please) for when the audio doesn't work correctly? -- Cinaed On 7/1/20 5:43 AM, Barry Duggan wrote: Hi Cinaed, Thank you for your response. Yes, I have tried those and the "hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained that from the 'aplay -L' command. Let me reiterate my request: In exploring the audio problems, I followed the instructions in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system and it gave the error I cited. So what I want to know is: Did I do something wrong, or is the procedure not correct? I need someone who is familiar with the ALSA and PulseAudio software to look at this. Thanks. .
Re: ALSAPulseAudio procedure
Hi Barry - the GRC isn't an image or binary file - it's a text based XML file. Send it as an attachment to your email. If I recall correctly, uploading a GRC file to pastbin.com and then downloading it destroys the flow graph (the XML formatting) and reduces the GRC flowgraph to a stack of text from the blocks. Try it. -- Cinaed On 7/2/20 4:26 AM, Barry Duggan wrote: Hi Cinaed, The Pluto_NFM.grc is in https://pastebin.com/XZN0dK6x I have found that reducing the buffer size on the Pluto almost eliminated the audio underruns. So what I am left with is needing to know what is wrong with the procedure in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system I have been doing a lot of documentation updates and would like to correct / improve that page. Thanks for your help. --- Barry Duggan KV4FV On 7/1/20 4:53 PM, Cinaed Simson wrote: Hi Barry - can you post the GRC file (no images please) for when the audio doesn't work correctly? -- Cinaed On 7/1/20 5:43 AM, Barry Duggan wrote: Hi Cinaed, Thank you for your response. Yes, I have tried those and the "hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained that from the 'aplay -L' command. Let me reiterate my request: In exploring the audio problems, I followed the instructions in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system and it gave the error I cited. So what I want to know is: Did I do something wrong, or is the procedure not correct? I need someone who is familiar with the ALSA and PulseAudio software to look at this. Thanks. .
Re: ALSAPulseAudio procedure
On Thu, Jul 02, 2020 at 06:43:21AM -0500, Barry Duggan wrote: > Probably I will create a new page for diagnosing audio problems. All > suggestions are welcome :) Depending on what exactly you are doing, there may be another problem. If you take the signal from an RF source, process and decimate it to e.g. 48 kHz, that frequency will never be *exactly* equal to the 48 kHz that the audio hardware is using. The reason is simple: each end uses its own clock. Your RF hardware may have 1 ppm accuracy, but most internal PC audio cards have much wider tolerances. No matter how small the difference, this will produce overruns or underruns. The solution is to use adaptive resampling in the audio sink. This is a problem I've solved a number of times - as a Linux user you may know the zita-ajbridge and zita-njbridge packages. I once modified the GR Jack sink to do this, and the same could be done with the ALSA sink. It worked but required too much latency to be useful, and the solution wasn't as clean as it could be. The reason for that is that the GR framework doesn't provide (AFAIK) the required 'hooks' to do this. Basically what is required for an audio sink is that the sink module needs to know *when* the producer is writing to the queue that feeds the audio sink, and how much. And for an audio source used with and RF sink (i.e. for a transmitter), the audio source module should know *when* the consumer of the audio samples reads its input, and how much it reads. And this should work without the module that is connected to the audio source or sink being aware of this and forced to cooperate -- that would put a burden on each and every module that would ever connect to audio. Without this information, the only robust solution is to have a large internal buffer in the audio source or sink. Which in turn means high latency, apart from being not really an efficient solution. This was one of the reasons why I abandoned GR and wrote my own SDR framework. Ciao, -- FA
Re: ALSAPulseAudio procedure
Hi Ryan, Thank you for that information! That certainly is an essential piece to be added to the wiki! Probably I will create a new page for diagnosing audio problems. All suggestions are welcome :) Stay safe. -- Barry Duggan KV4FV On Wed, 1 Jul 2020 13:31:15 -0400, Ryan Volz wrote: Hi Barry, I don't know too much about ALSA or PulseAudio, but I do know that the part of the wiki that you cited is for setting up an ALSA source that grabs whatever is playing through PulseAudio. It is *not* something that you can use for an audio sink, only an audio source, which I think is why that didn't work for you. If anything, then, I'd say that the wiki entry is a bit misleading to frame that discussion as a "problem" and "solution". It's really just a how-to for creating an audio source for the sounds that the system is producing elsewhere. The problem you're having with audio underruns is probably pretty common and likely would merit a wiki entry in the "problem" and "solution" style. Unfortunately, I don't have much help for you there since you're already avoiding PulseAudio and having ALSA talk to the sound card directly. Cheers, Ryan
Re: ALSAPulseAudio procedure
Hi Cinaed, The Pluto_NFM.grc is in https://pastebin.com/XZN0dK6x I have found that reducing the buffer size on the Pluto almost eliminated the audio underruns. So what I am left with is needing to know what is wrong with the procedure in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system I have been doing a lot of documentation updates and would like to correct / improve that page. Thanks for your help. --- Barry Duggan KV4FV On 7/1/20 4:53 PM, Cinaed Simson wrote: Hi Barry - can you post the GRC file (no images please) for when the audio doesn't work correctly? -- Cinaed On 7/1/20 5:43 AM, Barry Duggan wrote: Hi Cinaed, Thank you for your response. Yes, I have tried those and the "hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained that from the 'aplay -L' command. Let me reiterate my request: In exploring the audio problems, I followed the instructions in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system and it gave the error I cited. So what I want to know is: Did I do something wrong, or is the procedure not correct? I need someone who is familiar with the ALSA and PulseAudio software to look at this. Thanks.
Re: ALSAPulseAudio procedure
Hi Barry - can you post the GRC file (no images please) for when the audio doesn't work correctly? -- Cinaed On 7/1/20 5:43 AM, Barry Duggan wrote: Hi Cinaed, Thank you for your response. Yes, I have tried those and the "hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained that from the 'aplay -L' command. Let me reiterate my request: In exploring the audio problems, I followed the instructions in https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system and it gave the error I cited. So what I want to know is: Did I do something wrong, or is the procedure not correct? I need someone who is familiar with the ALSA and PulseAudio software to look at this. Thanks.
Re: ALSAPulseAudio procedure
Hi Barry, I don't know too much about ALSA or PulseAudio, but I do know that the part of the wiki that you cited is for setting up an ALSA source that grabs whatever is playing through PulseAudio. It is *not* something that you can use for an audio sink, only an audio source, which I think is why that didn't work for you. If anything, then, I'd say that the wiki entry is a bit misleading to frame that discussion as a "problem" and "solution". It's really just a how-to for creating an audio source for the sounds that the system is producing elsewhere. The problem you're having with audio underruns is probably pretty common and likely would merit a wiki entry in the "problem" and "solution" style. Unfortunately, I don't have much help for you there since you're already avoiding PulseAudio and having ALSA talk to the sound card directly. Cheers, Ryan On 7/1/20 8:43 AM, Barry Duggan wrote: > Hi Cinaed, > > Thank you for your response. Yes, I have tried those and the > "hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained that from > the 'aplay -L' command. > > Let me reiterate my request: In exploring the audio problems, I followed the > instructions in > https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system > and it gave the error I cited. So what I want to know is: Did I do something > wrong, or is the procedure not correct? > > I need someone who is familiar with the ALSA and PulseAudio software to look > at this. > > Thanks.
Re: ALSAPulseAudio procedure
Hi Cinaed,
Thank you for your response. Yes, I have tried those and the
"hw:CARD=Generic,DEV=0" works well for most flowgraphs. I obtained that
from the 'aplay -L' command.
Let me reiterate my request: In exploring the audio problems, I followed
the instructions in
https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Monitoring_the_output_of_your_system
and it gave the error I cited. So what I want to know is: Did I do
something wrong, or is the procedure not correct?
I need someone who is familiar with the ALSA and PulseAudio software to
look at this.
Thanks.
--
Barry Duggan KV4FV
On Tue, 30 Jun 2020 00:22:02 -0700, Cinaed Simson wrote:
What does
aplay -l
indicate?
When using
hw:CARD=Generic,DEV=0
in gnuradio, try using numbers, for example,
hw:0,0
or
plughw:0,0
and see if it makes a difference.
Or try switching between sampling rates of 48000 and 44100.
-- CInaed
On 6/29/20 3:00 PM, Barry Duggan wrote:
I have been having problems with audio underruns on some of my
flowgraphs, so I decided to try the procedure in
https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Solution_2
I found one entry (other than HDMI) for my speakers and created the
following for ~/.asoundrc :
pcm.pulse_monitor {
type pulse
device alsa_output.pci-_0f_00.4.analog-stereo.monitor
}
ctl.pulse_monitor {
type pulse
device alsa_output.pci-_0f_00.4.analog-stereo.monitor
}
I changed my Audio Sink device name to 'pulse_monitor' and got the
following error: ALSA lib pcm_pulse.c:752:(pulse_prepare) PulseAudio:
Unable to create stream: No such entity
gr::log :ERROR: audio_alsa_sink0 - [pulse_monitor]:
snd_pcm_hw_params failed: Input/output error
Traceback (most recent call last):
File "/home/barry/GRdev/Pluto_NFM.py", line 216, in
main()
File "/home/barry/GRdev/Pluto_NFM.py", line 194, in main
tb.start()
File
"/usr/local/lib/python3/dist-packages/gnuradio/gr/top_block.py", line
111, in start
top_block_start_unlocked(self._impl, max_noutput_items)
File
"/usr/local/lib/python3/dist-packages/gnuradio/gr/runtime_swig.py", line
5828, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: check topology failed on audio_alsa_sink(9) using
ninputs=1, noutputs=0
Using the device name "hw:CARD=Generic,DEV=0" works, but gives the
underruns. I'm using Ubuntu 19.10.
Any ideas?
Thanks.
Re: ALSAPulseAudio procedure
What does
aplay -l
indicate?
When using
hw:CARD=Generic,DEV=0
in gnuradio, try using numbers, for example,
hw:0,0
or
plughw:0,0
and see if it makes a difference.
Or try switching between sampling rates of 48000 and 44100.
-- CInaed
On 6/29/20 3:00 PM, Barry Duggan wrote:
I have been having problems with audio underruns on some of my
flowgraphs, so I decided to try the procedure in
https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Solution_2
I found one entry (other than HDMI) for my speakers and created the
following for ~/.asoundrc :
pcm.pulse_monitor {
type pulse
device alsa_output.pci-_0f_00.4.analog-stereo.monitor
}
ctl.pulse_monitor {
type pulse
device alsa_output.pci-_0f_00.4.analog-stereo.monitor
}
I changed my Audio Sink device name to 'pulse_monitor' and got the
following error:
ALSA lib pcm_pulse.c:752:(pulse_prepare) PulseAudio: Unable to create
stream: No such entity
gr::log :ERROR: audio_alsa_sink0 - [pulse_monitor]: snd_pcm_hw_params
failed: Input/output error
Traceback (most recent call last):
File "/home/barry/GRdev/Pluto_NFM.py", line 216, in
main()
File "/home/barry/GRdev/Pluto_NFM.py", line 194, in main
tb.start()
File
"/usr/local/lib/python3/dist-packages/gnuradio/gr/top_block.py", line
111, in start
top_block_start_unlocked(self._impl, max_noutput_items)
File
"/usr/local/lib/python3/dist-packages/gnuradio/gr/runtime_swig.py",
line 5828, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: check topology failed on audio_alsa_sink(9) using
ninputs=1, noutputs=0
Using the device name "hw:CARD=Generic,DEV=0" works, but gives the
underruns. I'm using Ubuntu 19.10.
Any ideas?
Thanks.
