OP25 VirtualBox Project - Run OP25 on Windows 7

[boatbod]

I do not like using "hw:0,0" or "plughw:0,0" as audio parameters for the simple fact that it locks the hardware, which kills audio for everything else, and visa versa.

Having said that, I did some testing with those parameters, and discovered my hardware also does not support 8000 natively. The lowest sample rate my hardware supports is 41000. So I modified the source code to implement a "fractional resampler" between the volume scaler and the audio sink. This works of course, but it still does not solve the "aU" messages you see in the terminal, those can be ignored. The audio output however was just fine. I do not think this modification will solve your problem.

Under Ubuntu, I recommend you use "default" or don't specify anything and let alsa handle the resampling at the driver level.

The modification I had you make to the "config.conf" file should have taken care of the stuttering. If it didn't work, I don't know what else to tell you. You aren't running in a virtual machine are you?

No, not a virtual machine, just an older Core i5 2410M laptop with 8GB running Ubuntu Mate 14.04 that is dedicated to providing a broadcastify feed. The aU's are issued about 1 per second or so, and while the audio quality is generally ok, the glitches do cause key words/ phrases to go silent right when you don't want them to.

I've tried all sorts of values of nperiods & period_time but it doesn't make much if any discernible difference.

I did determine that if I disable PulseAudio I get no usable sound due to the mismatched sample rate. When I try a 'plughw' device, scope.py errors out attempting to set alsa time periods inside the audio alsa sink code. If I try a plain 'hw' or 'default' device , the sample rate mismatch prevents the audio doing more than the occasional squeak.

How can I try your rational resampler modification? Sounds promising.

 

[PiccoIntegra]

I'm just going to post a screenshot of the changes needed. It's a very simple process..

 

[boatbod]

I'm just going to post a screenshot of the changes needed. It's a very simple process..

After making these changes, OP25 performs much the same when using PulseAudio (no surprises there), but I still cannot get it to work properly with the native ALSA drivers. The error is different, but it's still having issues setting up the audio sink. Tried it with hw:0,0 plughw:0,0 and default devices.

./scope.py --args "rtl=0" -N 'LNA:36' -f 773.84375e6 -S 1440000 -q 0 -d 200 -2 -v 0 -V -T trunk-test.tsv
gnorbury@vaio:~/op25/op25/gr-op25_repeater/apps$ ./first-test.sh 
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown

gr-osmosdr 0.1.1 (0.1.1) gnuradio 3.7.2.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
gain: name: LNA range: start 0 stop 0 step 0
setting gain LNA to 36
supported sample rates 250000-2560000 step 24000
Using Volk machine: avx_64_mmx_orc
set_center_freq: 773843750
Project 25 IMBE Encoder/Decoder Fixed-Point implementation
Developed by Pavel Yazev E-mail: pyazev@gmail.com
Version 1.0 (c) Copyright 2009
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file ``LICENSE'' for details.
audio_alsa_sink[default]: snd_pcm_sw_params: Invalid argument
Traceback (most recent call last):
  File "./scope.py", line 2785, in <module>
    app = stdgui2.stdapp(p25_rx_block, "APCO P25 Receiver", 3)
  <<<<extraneous info redacted>>>>
RuntimeError: audio_alsa_sink

 

[PiccoIntegra]

./scope.py --args "rtl=0" -N 'LNA:36' -f 773.84375e6 -S 1440000 -q 0 -d 200 -2 -v 0 -V -T trunk-test.tsv
gnorbury@vaio:~/op25/op25/gr-op25_repeater/apps$ ./first-test.sh 
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown

[COLOR="Red"]gr-osmosdr 0.1.1 (0.1.1) gnuradio 3.7.2.1[/COLOR]
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
gain: name: LNA range: start 0 stop 0 step 0
setting gain LNA to 36
supported sample rates 250000-2560000 step 24000
Using Volk machine: avx_64_mmx_orc
set_center_freq: 773843750
Project 25 IMBE Encoder/Decoder Fixed-Point implementation
Developed by Pavel Yazev E-mail: pyazev@gmail.com
Version 1.0 (c) Copyright 2009
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file ``LICENSE'' for details.
audio_alsa_sink[default]: snd_pcm_sw_params: Invalid argument
Traceback (most recent call last):
  File "./scope.py", line 2785, in <module>
    app = stdgui2.stdapp(p25_rx_block, "APCO P25 Receiver", 3)
  <<<<extraneous info redacted>>>>
RuntimeError: audio_alsa_sink

Ooooookay.... you're running a very old version of gnuradio and gr-osmosdr. You got these versions from the Ubuntu repository installs. I don't know if this is a direct cause for your audio problems. I recommend reinstalling Ubuntu 14.04.5 LTS, and installing via pybombs. If you want help with that, I can send you an email with instructions on how to do that.

 

[rrbum]

Please report any success with curing the Au underruns and audible stuttering. I 've been following along and was hoping to see some sort of solution.
I have audio issues as well. Several different PC's. Should have enough cpu for op25 to run well but plagued with underruns and stutter. That's with the more recent gnuradio and osmosdr thanks to help from PicoIntegra. Running on bare metal.

 

[KA1RBI]

Ooooookay.... you're running a very old version of gnuradio and gr-osmosdr. You got these versions from the Ubuntu repository installs. I don't know if this is a direct cause for your audio problems. I recommend reinstalling Ubuntu 14.04.5 LTS, and installing via pybombs. If you want help with that, I can send you an email with instructions on how to do that.

Not sure if this goes in the FWIW Dept., or the YMMV Dept., but here goes - I'm running gnuradio-3.7.2.1-5ubuntu0.1 and gr-osmosdr 0.1.0.55.80c4af-2 - audio is clean with no difficulties... Surprised the 8,000 vs, 48,000 rate is an issue - but I wasn't able to view Scott's screen print (takes you to a google login reg page)

73

Max

 

[KA1RBI]

also, what option is this?

-d 200

 

[boatbod]

Ooooookay.... you're running a very old version of gnuradio and gr-osmosdr. You got these versions from the Ubuntu repository installs. I don't know if this is a direct cause for your audio problems. I recommend reinstalling Ubuntu 14.04.5 LTS, and installing via pybombs. If you want help with that, I can send you an email with instructions on how to do that.

Ah I see. Recently I've been experimenting with building everything from sources but that is not without it's own challenges, pybombs notwithstanding.

Tonight I made an attempt to get 16.04 up and running so I could experiment without interrupting the 14.04 machine providing my live feed. No joy yet, but it seems Max tweaked a few things in scope.py that I will need to merge with my own version (which has Fine Tuning as a command line option). My other approach would be to take a 14.04 build of gnuradio that I did in a virtual machine and move that across to the live machine. Running out of time tonight, so will think on this some more.

 

[boatbod]

I thought I'd post a followup to my earlier experiences trying to reduce audio glitches and make my OP25 installation work with ALSA. The following is the result of pretty much an entire weekend of digging around in gnuradio sources and several long evenings researching ALSA settings and kernel parameters.

i. If you are trying to use either the hw:0,0 or plughw:0,0 interfaces and see weird errors that state "snd_pcm_hw_params_..." or "snd_pcm_sw_params...", there are most likely the result of inadequately small kernel buffer size setting for the chosen alsa pcm playback device. This can be fixed by changing the value in the file found at /proc/asound/card0/pcm0p/sub0/prealloc. I increased my system from 64 to 1024 and all those problems went away. Note that any changes are not preserved across a reboot, so you will have to write a script to automate the process at boot time.

As an aside, I found that the code for gnuradio's ALSA Sink (found in gnuradio/gr-audio/alsa/lib/alsa_sink.cc) performs very minimal error checking when it sets up it's hw and sw parameters. If your kernel buffers are too small - like mine apparently were - the sink fails rather than handling the problem gracefully by scaling back the size of the buffer. Excessively high nperiods or too long a period_time (set by ~/.gnuradio/config.conf) will definitely cause problems if your kernel buffers are too small.

ii. When attempting to have OP25 send audio direct to an ALSA pcm device, you definitely need to use the "plughw:X,Y" variant of the device name (or really understand how to define virtual pcm devices using .asoundrc). The reason for this is that OP25 output audio at 8khz sample rate, but few sound cards support that rate natively. If you see the message that a sample rathe of 8000 was requested but the card chose 44100 instead, you can pretty much guarantee you're only going to hear the occasional high pitched squeak.

iii. Finally, as has been stated before by others, you do need to make sure you have good settings in your ~/.gnuradio/config.conf file. Too small a buffer causes excessive underruns (aUaUaU) whereas too large a buffer causes high latency. The latter doesn't seem so bad, except that any interruption to decode causes the audio stream to go silent for much longer. nperiods=16, period_time=0.025 work well for some people, but I'm using 32 and 0.030 as it seems to work best for me. Expect to spend some time tweaking these values.

My op25 system streams to Broadcastify using icecast. It's up 24x7, but the radio traffic tends to be infrequent unless there is an active Fire or EMS incident underway. Personally I'm pretty happy with how things turned out, especially comparing the quality of the audio to my PSR800 scanner which seemingly misses have the traffic. Talbot County Fire and EMS
--Graham

 

[scan18]

Forgive me if this is a lame question, but I'm trying to get a handle on the different repos/braches that are available. This is what I'm seeing, does this make sense?

git://op25.osmocom.org/op25.git - If I clone this one and do NOT switch to the max branch, then the git log shows the latest change was in October 2015.

git://op25.osmocom.org/op25.git - If I clone this same one and DO switch to the max branch, then the git log shows the latest change was in December 2016.

git://git.osmocom.org/op25 - If I clone this one (slightly different) and DO switch to the max branch, the git log shows the latest change was 3/20/2017

Is there any consensus as to which "version" people are getting the best results from? I'm currently using the 3/20/2017 version and not seeing any glaring issues.

Thanks.

 

[boatbod]

also, what option is this?

-d 200

Ah yes, that's one of my own tweaks. I added the ability to preset the fine tune because my RTL dongle needed less than 1ppm error correction but was still 'off' enough to cause decoding errors if left at fine_tune=0.

diff --git a/op25/gr-op25_repeater/apps/scope.py b/op25/gr-op25_repeater/apps/scope.py
index 1c8cffb..60bf9f8 100755
--- a/op25/gr-op25_repeater/apps/scope.py
+++ b/op25/gr-op25_repeater/apps/scope.py
@@ -128,6 +128,7 @@ class p25_rx_block (stdgui2.std_top_block):
         #parser.add_option("-O", "--audio-output", type="string", default="plughw:0,0", help="audio output device name")
         parser.add_option("-O", "--audio-output", type="string", default="default", help="audio output device name")
         parser.add_option("-q", "--freq-corr", type="eng_float", default=0.0, help="frequency correction")
+        parser.add_option("-d", "--freq-tune", type="eng_float", default=0.0, help="fine tuning")
         parser.add_option("-2", "--phase2-tdma", action="store_true", default=False, help="enable phase2 tdma decode")
         (options, args) = parser.parse_args()
         if len(args) != 0:
@@ -273,7 +274,7 @@ class p25_rx_block (stdgui2.std_top_block):
                 self.lo_freq += self.options.calibration
             self.demod = p25_demodulator.p25_demod_cb( input_rate = capture_rate,
                                                        demod_type = 'cqpsk',           ### FIXME
-                                                       relative_freq = self.lo_freq,
+                                                       relative_freq = self.lo_freq + self.myform['freq_tune'].get_value(),
                                                        offset = self.options.offset,
                                                        if_rate = 48000,
                                                        gain_mu = self.options.gain_mu,
@@ -643,7 +644,7 @@ class p25_rx_block (stdgui2.std_top_block):
         if not self.baseband_input:
             myform['freq_tune'] = form.slider_field(parent=self.panel, sizer=vbox_sliders, label="Fine Tune",
                 weight=0,
-                min=-3000, max=3000,
+                min=-3000, max=3000, value=self.options.freq_tune,
                 callback=self.set_freq_tune)
             if not self.options.trunk_conf_file:
                 myform['demod_type'] = form.radiobox_field(parent=self.panel, sizer=hbox, label="Demod",

 

[boatbod]

Forgive me if this is a lame question, but I'm trying to get a handle on the different repos/braches that are available. This is what I'm seeing, does this make sense?

git://op25.osmocom.org/op25.git - If I clone this one and do NOT switch to the max branch, then the git log shows the latest change was in October 2015.

git://op25.osmocom.org/op25.git - If I clone this same one and DO switch to the max branch, then the git log shows the latest change was in December 2016.

git://git.osmocom.org/op25 - If I clone this one (slightly different) and DO switch to the max branch, the git log shows the latest change was 3/20/2017

Is there any consensus as to which "version" people are getting the best results from? I'm currently using the 3/20/2017 version and not seeing any glaring issues.

Thanks.

I'm using the 3rd one on your list. git://git.osmocom.org/op25 on the 'max' branch.

 

[apu]

Ooooookay.... you're running a very old version of gnuradio and gr-osmosdr. You got these versions from the Ubuntu repository installs. I don't know if this is a direct cause for your audio problems. I recommend reinstalling Ubuntu 14.04.5 LTS, and installing via pybombs. If you want help with that, I can send you an email with instructions on how to do that.

PiccoIntegra,

What's your recommendation?

The Fall 2016 update to the install instructions suggest using the default Ubuntu repository for the install. But I'm open to better options as I rebuild my box.

Thanks.

 

[KA1RBI]

git://git.osmocom.org/op25 - If I clone this one (slightly different) and DO switch to the max branch, the git log shows the latest change was 3/20/2017

yep, this is the current repo. the vast bulk of the recent change activity (but possibly not all) has been unrelated to the RX - instead for the new OP25 TX app that enables digital voice transmission for dstar, dmr, p25, and ysf...

73

Max

 

[scan18]

yep, this is the current repo. the vast bulk of the recent change activity (but possibly not all) has been unrelated to the RX - instead for the new OP25 TX app that enables digital voice transmission for dstar, dmr, p25, and ysf...



73



Max

Sounds good, thanks for the clarification.

 

[boatbod]

After much head scratching, lots of investigation, and support from RR member PiccoIntegra, I have finally eliminated all my P25 Phase 2 audio glitches and the spurious "process_data_unit timeout" messages that have been bugging me since setting up an OP25 system to stream our local Fire & EMS dispatch traffic.

Three source files based on the current "max" branch of the git://git.osmocom.com/op25 repository were modified. All three reside in the op25/op25/gr-op25_repeater/lib directory.

If you feel like trying my changes, you can access copies of the files on my google drive:
http://drive.google.com/open?id=0B-9lC78gYedOUnJvdElvLTJFekU
Note: if you don't care about the timeout messages, you only need to update p25_frame_assembler_impl.cc to tweak the forecast() routine which has the biggest affect on audio quality next to setting proper values in your ~/.gnuradio/config.conf file.

 

[PiccoIntegra]

Three source files based on the current "max" branch of the git://git.osmocom.com/op25 repository were modified. All three reside in the op25/op25/gr-op25_repeater/lib directory.

As a baseline, I installed the current max branch, and it ran just fine for both P1 & P2. Audio was great, no glitching noticed. I applied your modifications, and it was mixed results for me. Phase 2 traffic worked really good, while Phase 1 was terrible. I realize you don't have P1 traffic, but the system I monitor is a mixed system so I need both.

Other than the variable input rate, 4800 vs 6000 symbols, I have no idea why the default code doesn't work well for P2 on your system. I did listen to your feed quite a bit the other day, and did notice the audio stalls. It doesn't much matter in your case though, as long as you're satisfied with the results.

The message timeout mod is a keeper.

 

[boatbod]

As a baseline, I installed the current max branch, and it ran just fine for both P1 & P2. Audio was great, no glitching noticed. I applied your modifications, and it was mixed results for me. Phase 2 traffic worked really good, while Phase 1 was terrible. I realize you don't have P1 traffic, but the system I monitor is a mixed system so I need both.

Other than the variable input rate, 4800 vs 6000 symbols, I have no idea why the default code doesn't work well for P2 on your system. I did listen to your feed quite a bit the other day, and did notice the audio stalls. It doesn't much matter in your case though, as long as you're satisfied with the results.

The message timeout mod is a keeper.

I'm curious why it doesn't work on P1 for you. I have a suspicion, but it'd be interesting to test it with a few carefully placed printf()'s in the forecast() method. Specifically, what is the multiplier the eventually gets applied in the max branch vs my modification?

I'm not convinced whether the d_do_phase2_tdma flag is being set based on decode or if it is applied based on command line "-2" option. Trouble is I have no way of testing it...

 

[boatbod]

I'm curious why it doesn't work on P1 for you. I have a suspicion, but it'd be interesting to test it with a few carefully placed printf()'s in the forecast() method. Specifically, what is the multiplier the eventually gets applied in the max branch vs my modification?

I'm not convinced whether the d_do_phase2_tdma flag is being set based on decode or if it is applied based on command line "-2" option. Trouble is I have no way of testing it...

Quick follow up:
First observation: once you set ' -2' on the command line the frame assembler does the same thing for every received frame regardless of type (phase 1 or phase 2).
Second observation: making the multiplier in the forecast() method smaller than necessary does not affect audio quality, but making it too large causes choppy audio.
Consequently, if the multiplier were always 0.6 (or in my case 0.5) I'm willing to bet that both phase 1 and phase 2 would sound great.
(I've tried it all the way down to 0.2 and noticed no difference in ph2).

Max, your thoughts world be appreciated.
Thanks,
Graham

 

[KA1RBI]

Consequently, if the multiplier were always 0.6 (or in my case 0.5) I'm willing to bet that both phase 1 and phase 2 would sound great.
(I've tried it all the way down to 0.2 and noticed no difference in ph2).

for some reason the forecast multiplier value has caused more grief per line of code than just about any other thing in OP25. One of the issues that's bearing down on this has to do with the "two clocks problem" and the bad things that will happen if the app doesn't have speed matching buffers or elastic stores (which OP25 doesn't) to handle the case where two unsynchronized timing sources are coming at you. I'd bet though that may not be the root cause of this issue. Nonetheless in any (mythical) future rewrite of OP25 I think the GR block in question would undoubtedly change to a sink-only block, which would eliminate the forecast method altogether. Any time a piece of code causes that much trouble the only solution is to delete it!

As an aside we may note tangentially that the frame sync recognizer has been rewritten to be slightly less CPU hoggish. That code has been pushed to the 'max' branch, if I recall correctly...

And as for the report of choppy audio, unfortunately I don't yet have any P25P2 TDMA sites locally. Accordingly the P2 code isn't as well tested as the P1. There is supposed to be logic that keeps the trunk scanner from resuming a scan if a TDMA call is in progress, are you saying that doesn't work? Or is this just run of the mill choppy audio? Are there underrun (U) indicators that occur that correlate with the choppy audio?

Max