Re: Audio source - device or resource busy error - PROBLEM SOLVED

Marcus,

I have discovered a solution to this issue but I don't understand why.

The 'main()' of FT8_Receive contains lines related to sig_handler which were
included in the original file created by GNU Radio as shown below:

def main(top_block_cls=FT8_Receive, options=None):
tb = top_block_cls()

now = float(datetime.now().strftime('%S.%f'))
print ("RX main = ", now)
def sig_handler(sig=None, frame=None):
tb.stop()
tb.wait()
sys.exit(0)

signal.signal(signal.SIGINT, sig_handler)
signal.signal(signal.SIGTERM, sig_handler)

check_time(cycle)
print("\nReceiving...")
#Receiving = time.time()
#now = float(datetime.now().strftime('%S.%f'))
#print ("After Receiving = ", now)
tb.start()
#start = time.time()
#print ("start = ",start)
tb.wait()

In desperation I removed those lines to see what the effect would be. I am
no longer getting the resource busy error and the code is running as I
intended.

Why are those lines included and why did their removal fix the problem?

Jim

-----Original Message-----
From: Elmore Family
Sent: Monday, April 15, 2024 11:01 AM
To: GNURadio Discussion List ; Marcus Müller
Subject: Re: Audio source - device or resource busy error



Marcus,

The following is the config.conf file as modified per your request:

[audio_alsa]
audio_module = portaudio
default_input_device = portaudio
default_output_device = pulse
nperiods = 32
period_time = 0.010
verbose = false

Did I do this correctly?

I wasn't sure what to use for the Device Name so I tried portaudio - didn't
recognize it. Used default - it ran but produced exactly the same error as
pulse after 6 iterations.

Note for reference:
Prior to calling the FT8_Receive.main() as I do now I was using either
os.system or subprocess calls to call FT8_Receive. These did not result in
any audio errors but the time to start of execution (1.2 secs) is excessive
rendering the application unusable due to critical timing constraints.

Jim

-----Original Message-----
From: Marcus Müller
Sent: Monday, April 15, 2024 4:55 AM
To: Elmore Family ; GNURadio Discussion List
Subject: Re: Audio source - device or resource busy error

Hi Jim,
so, that's an interesting problem with your sound system. I don't see why it
*should* fail
at six created sources (my suspicion is that the non-deterministic
destruction of objects
that is inherent to Python means there's six parallel endpoints active, from
a perspective
of ALSA and pulseaudio).
Sadly, we don't have a test that covers this (yet?).
Maybe this is a problem specific to the way the ALSA source works.

Would be able to test the portaudio sink? For that, we'll have to force GNU
Radio to use
it (because it uses ALSA by default). You can do that by adding

[audio]
audio_module = portaudio

to your GNU Radio configuration, so to a file ending in .conf (e.g.,
audio.conf) in the
directory that `gnuradio-config-info --userprefsdir` shows.

Best regards,
Marcus


On 15.04.24 02:18, Elmore Family wrote:
> Marcus,
>
> I first tried:
> For ALSA users with audio trouble, follow this procedure ( which I
> followed):
>
> The result was the same.
>
> Then I selected pulse as the device name. it worked for 6 iterations of
> the loop and then gave the following error:
>
> mmap() failed: Cannot allocate memory
> mmap() failed: Cannot allocate memory
> gr::log :ERROR: audio_alsa_source6 - [pulse]: Input/output error
> Traceback (most recent call last):
> File "/home/pi/gr-ft8_rxtx/python/ft8_rxtx.py", line 337, in <module>
> main()
> File "/home/pi/gr-ft8_rxtx/python/ft8_rxtx.py", line 320, in main
> FT8_Receive.main()
> File "/home/pi/gr-ft8_rxtx/python/FT8_Receive.py", line 205, in main
> tb = top_block_cls()
> File "/home/pi/gr-ft8_rxtx/python/FT8_Receive.py", line 85, in __init__
> self.audio_source_0 = audio.source(samp_rate, 'pulse', True)
> RuntimeError: audio_alsa_source
>
> Jim
>
> -----Original Message----- From: Marcus Müller
> Sent: Sunday, April 14, 2024 3:45 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: Audio source - device or resource busy error
>
> Hi Jim,
>
> try not using the direct hardware device, but the device provided by your
> sound system;
> see the "for users wiht audio trouble" section on the Audio Source
> documentation page.
>
> Best regards,
> Marcus
>
> On 14.04.24 18:02, Elmore Family wrote:
>> I am getting the subject error when running a Python script called
>> repeatedly from another script.
>> The snippet_ft8_rxtx.py shows the call, FT8_Receive.main(), in the while
>> loop.
>> FT8_Receive.py shows the called script.
>> FT8_Receive.pdf is the flowgraph used to generate the called script which
>> as you can see has been modified in main() and with check_time added.
>> The first call to the script is OK but the second call results in the
>> error shown in audio_error.txt.
>> Why is the audio source busy when the flowgraph is stopped (or is it not
>> stopped?) and how do I fix the issue?
>> Jim
>>
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> Virus-free.www.avg.com
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

Re: Debugging Existing C++ Blocks with VS Code & GDB

Hi Matt, 

I'm not sure if this is an apples-to-apples situation, but your issue sounds exactly like something I've run into while abusing Python snippets. 

It was easy to avoid after understanding order-of-events for block creation.

I suspect this is language-independent, and you can quickly create a python flowgraph / review the code - it will illustrate the principles:

1. Create a python flowgraph 'FOO.grc' with minimal blocks (e.g. [signal source] --> [throttle2] --> [null sink]).  

2. Add four [Python Snippet] blocks - one for each type of [Section of Flowgraph] param: 'Init - Before Blocks', 'Main - After Start', etc.

3. For each Python Snippet block, add a one-line snippet distinct to the [Section of Flowgraph], for example: 

print("Hello IAMA Init - Before Blocks")    

# NOTE: it's important to have a least one line of code or nothing will be generated for the snippet!

4. Set the Title param of the [Options] block (top block) to "FOO".

5. Press [F5] to generate the flowgraph code, which will be called FOO.py (in same directory as FOO.grc).

6. Examine the resulting FOO.py script in VSCode - in particular, where each of the snippets are invoked.

The most obvious example is that in 'Init - Before Block' it's possible to reference a block or variable self.X before self.X has been instantiated.

More subtle cases are possible, depending on how clever one tries to be when using this mechanism.

- W 

Attached: screencap of example error (take my word that the block 'radio' exists).  I can send a shot of the flowgraph, but it probably wouldn't shed further light.

On Apr 23, 2024, at 13:46, Matt Clemons <mattclems11@gmail.com> wrote:

Hello,

I've walked through tutorials and successfully set breakpoints and debugged OOT modules in Gnu Radio using the DCMAKE_BUILD_TYPE=Debug option. However, I'm trying to debug local changes I've made to existing gnuradio/dtv/ files and not having success.

I've followed the steps in a similar question/email chain here: https://lists.gnu.org/archive/html/discuss-gnuradio/2021-08/msg00008.html (I wasn't sure if replying to this old chain with a question or referencing it was better, let me know if there is a preference for future scenerios).

I also tried recompiling all of the gnu radio source code on my machine with the  DCMAKE_BUILD_TYPE=Debug option and still can not get VScode to stop on my set breakpoint within the dtv/dvbt_demod_reference_signals_impl.cc file. The flowchart runs, and completes but when I hover over the break point it just says "Module containing this breakpoint has not yet loaded or the address could not be obtained".

Any suggestions? I don't like the option of copying this into an OOT module just to debug. I'm not sure I understand the difference either.

Thanks,

Matt

Debugging Existing C++ Blocks with VS Code & GDB

Hello,

I've walked through tutorials and successfully set breakpoints and debugged OOT modules in Gnu Radio using the DCMAKE_BUILD_TYPE=Debug option. However, I'm trying to debug local changes I've made to existing gnuradio/dtv/ files and not having success.

I've followed the steps in a similar question/email chain here: https://lists.gnu.org/archive/html/discuss-gnuradio/2021-08/msg00008.html (I wasn't sure if replying to this old chain with a question or referencing it was better, let me know if there is a preference for future scenerios).

I also tried recompiling all of the gnu radio source code on my machine with the  DCMAKE_BUILD_TYPE=Debug option and still can not get VScode to stop on my set breakpoint within the dtv/dvbt_demod_reference_signals_impl.cc file. The flowchart runs, and completes but when I hover over the break point it just says "Module containing this breakpoint has not yet loaded or the address could not be obtained".

Any suggestions? I don't like the option of copying this into an OOT module just to debug. I'm not sure I understand the difference either.

Thanks,

Matt

Howto Tutorial: Python Module Not Found in Unit Testing

Hello,

I was working through some of the Gnu Radio tutorials to understand the python unit testing and I'm having an issue where the python module can't be found.

I'm following the tutorial here: https://wiki.gnuradio.org/index.php/OutOfTreeModules

When I run `make test` it fails and when I run `ctest -V` for more details it shows 'ModuleNotFoundError: No module named 'howto'.

I'm not savvy with the build process, but it seems this python module is not being built/installed for python correctly?

I followed the instructions here: https://wiki.gnuradio.org/index.php/ModuleNotFoundError , but I'm still getting the same error on the unit test.

I'm running GnuRadio 3.10.7.0

Any suggestions?

Thanks,

Matt

Release v3.10.10.0

GNU Radio v3.10.10.0 is available (https://github.com/gnuradio/gnuradio/releases/tag/v3.10.10.0). There were just a few fixups since the RC. The Qt front end to GRC can be tested using gnuradio-companion --qt. Most things work, but this is still a work in progress.

Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks

Hi Matt,

++props for Ron's example of PMT tagging in C++  :-)

Quick tip: as a person with strong/current Python skills and C++ expertise that's 20 years out-of-date, I've found that I can get "best results per unit time" by reading the C++ code/docs but coding my blocks and snippets in efficiently-written Python.  

I've found that well-written Python doesn't introduce bottlenecks, and I can apply the time saved to high-level organization of flowgraphs that optimizes throughput and latency. 

Getting acceptable performance in Python requires being comfortable with loop-free vector coding in numpy, as well as judicious use of itertools, functools, and other "straight-to-C" mechanisms.

A nice feature to be aware of is that GR sidesteps the Python GIL at a high level.  This provides a level of efficiency unavailable in ordinary Python environments.  

Hope this helps.

- W

Matt wrote:

> Thank you Ron! This does look like exactly what I need.  ...

(and earlier)

> data called out in the spec. Implementing this in the c++ code is 
> where I'm running into issues and where I'm looking for help/advice.

....

> I am fairly new to GnuRadio and C++ these modifications seem difficult 
> to me, hoping someone with more experience in both could point me in 
> the right direction.

----------

On Apr 19, 2024, at 08:13, Matt Clemons <mattclems11@gmail.com> wrote:

Thank you Ron!

...

Matt

On Thu, Apr 18, 2024 at 6:33 PM Ron Economos <w6rz@comcast.net> wrote:

Matt,

Take a look at ...
https://github.com/drmpeg/gr-dvbs2

It implements exactly what you're talking about to achieve VCM (Variable
Coding and Modulation).

...

https://github.com/drmpeg/gr-dvbs2/blob/master/lib/bbheader_bb_impl.cc#L496

Then it's sent downstream and all the subsequent blocks use it for
configuration (and also pass it downstream to the next block).

Ron

On 4/18/24 09:39, Matt Clemons wrote:
> Hello,
>
> I've been using the dtv/dvbt blocks in GnuRadio Companion to decode 

Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks

Thank you Ron! This does look like exactly what I need. I almost reached out to you directly, seeing all the DrMpeg commits related to gnuradio DTV blocks.

Thanks for your help and all the contributions you've made to the community.

Matt

On Thu, Apr 18, 2024 at 6:33 PM Ron Economos <w6rz@comcast.net> wrote:

Matt,

Take a look at my DVB-S2 OOT. This is a different version of the DVB-S2
transmitter that implements VCM (as opposed to the regular CCM version
included in GNU Radio).

https://github.com/drmpeg/gr-dvbs2

It implements exactly what you're talking about to achieve VCM (Variable
Coding and Modulation). In VCM, the coding and modulation parameters can
change on a frame by frame basis. To accomplish this, the parameters are
sent as stream tags.

To get you started, here's where the stream tag is first created. It bit
packs a 64-bit PMT with all the parameters.

https://github.com/drmpeg/gr-dvbs2/blob/master/lib/bbheader_bb_impl.cc#L496

Then it's sent downstream and all the subsequent blocks use it for
configuration (and also pass it downstream to the next block).

Ron

On 4/18/24 09:39, Matt Clemons wrote:
> Hello,
>
> I've been using the dtv/dvbt blocks in GnuRadio Companion to decode
> dvbt signal recordings. I noticed a lot of the blocks in the RX chain
> require the user to select the modulation parameters (Constellation,
> Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user
> parameters with the use of Transmission Parameter Signals (TPS) data
> called out in the DVB-T spec. This would make the DVBT receiver more
> autonomous, and be better than brute forcing all the modulation
> settings until you get a recovered transport stream in the cases where
> you don't know the transmitter settings. This solution seems to be a
> worthwhile improvement to the current DVBT blocks by utilizing the TPS
> data called out in the spec. Implementing this in the c++ code is
> where I'm running into issues and where I'm looking for help/advice.
>
> In the DVB-T spec the Transmission Parameter Signals (TPS) data can be
> recovered which will tell you all the modulation parameters of the
> main signal. As long as you know the TX mode and Guard Time, you can
> configure the OFDM Symbol Acquisition block and the FFT block, which
> are the only 2 required blocks before the Demod Reference Signals
> (DRS) block. The DRS code already decodes the TPS data but is only
> looking at 2 of the total 68 bits to determine what the frame index
> is, and then clears the std::deque of TPS data.
>
> My goal is to use all of the TPS data and either pass it in a tag or
> pass through a new port so that all the remaining downstream blocks
> can get the modulation parameters from that data rather than a user.
> I've dug into the tags and the PMT types required to pass data, but I
> can't wrap my head around how I would configure the modulation
> parameters of the downstream blocks from the port or tag TPS data
> passed to it.
>
> For example, a lot of the DRS modulation parameters are not needed for
> the DRS block to work, and when you recover Constellation Type,
> Hierarchy Type, and Tx Mode you could then pass these parameters to
> the DVB-T Demap block instead of having to create the block with those
> parameters.
>
> If there are any examples of other blocks using tags or ports to
> change the functionality of another block, that would be useful. Since
> I am fairly new to GnuRadio and C++ these modifications seem difficult
> to me, hoping someone with more experience in both could point me in
> the right direction.
>
> thanks!