OP25 Audio Slow and Choppy

[wayside93]

I am working with a Raspberry Pi3B and a NooElec SDR. I am able to get SDRTrunk to monitor my local system properly, though I would much prefer OP25 based on it seeming to be less resource heavy and no GUI.

At this point OP25 seems to be functioning fine, with one exception, the audio from the headphone jack sounds like its being played in slow motion and the audio is almost illegible. At this point I'm not sure where to turn. I've searched threads to no avail.

Any ideas on where to start?

 

[boatbod]

I am working with a Raspberry Pi3B and a NooElec SDR. I am able to get SDRTrunk to monitor my local system properly, though I would much prefer OP25 based on it seeming to be less resource heavy and no GUI.

At this point OP25 seems to be functioning fine, with one exception, the audio from the headphone jack sounds like its being played in slow motion and the audio is almost illegible. At this point I'm not sure where to turn. I've searched threads to no avail.

Any ideas on where to start?

The pi3 has a pretty low end cpu spec. You didn't way what you had for RTL sample size (-S), but I recommend you reduce it to the bare minimum. There's probably some notes about it in the "RPIi3" thread, but somewhere down around 57600 might be a good starting point.

 

[wayside93]

The pi3 has a pretty low end cpu spec. You didn't way what you had for RTL sample size (-S), but I recommend you reduce it to the bare minimum. There's probably some notes about it in the "RPIi3" thread, but somewhere down around 57600 might be a good starting point.

I've adjusted it around a bit but haven't gone that low. I'll give that a shot later today and let you know how it worked. Thanks Boatbod.

 

[wayside93]

The pi3 has a pretty low end cpu spec. You didn't way what you had for RTL sample size (-S), but I recommend you reduce it to the bare minimum. There's probably some notes about it in the "RPIi3" thread, but somewhere down around 57600 might be a good starting point.

I tried changing the sampling rate to as low as it would go (250000) and it didn't seem to have any impact on the audio

I recorded a couple of quick transmissions (https://www.dropbox.com/s/xmueyee79t243hw/OP25 Audio.mp3?dl=0), though I'm not sure if hearing it would help.

I'm scratching (banging) my head...a lot.

 

[boatbod]

I tried changing the sampling rate to as low as it would go (250000) and it didn't seem to have any impact on the audio

I recorded a couple of quick transmissions (https://www.dropbox.com/s/xmueyee79t243hw/OP25 Audio.mp3?dl=0), though I'm not sure if hearing it would help.

I'm scratching (banging) my head...a lot.

Curious - that's definitely different than the usual pcm underruns. Sample rate sounds wrong, not that you usually have control over that.

Questions:-
- which version of op25 are you using? (osmocom or boatbod)
- are you using the built-in audio server (-U) or netcat | aplay
- is there anything else running on the host machine?

A copy of the stderr.2 log might provide some insight, along with a screen capture of "top -H" when there is audio playing.

 

[wayside93]

Curious - that's definitely different than the usual pcm underruns. Sample rate sounds wrong, not that you usually have control over that.

Questions:-
- which version of op25 are you using? (osmocom or boatbod)
- are you using the built-in audio server (-U) or netcat | aplay
- is there anything else running on the host machine?

A copy of the stderr.2 log might provide some insight, along with a screen capture of "top -H" when there is audio playing.

I'm using osmocom and the built in audio server. Also, nothing else running, though I am connecting via RealVNC. Not sure if that would have any impact. Overall resource use is pretty low when OP25 is running. CPU @ 17% and Mem is 203 of 927.

I apologize, but I'm not sure what the "top -H" is.


Below is a copy of stderr.2:

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya
Using device #0 Realtek RTL2838UHIDIR SN: 00000002
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!
Using two-stage decimator for speed=960000, decim=10/4 if1=96000 if2=24000
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.
op25_audio:pen_socket(): enabled udp host(127.0.0.1), wireshark(23456), audio(23456)
p25_frame_assembler_impl: do_imbe[1], do_output[0], do_audio_output[1], do_phase2_tdma[0], do_nocrypt[0]
audio device: default

 

[boatbod]

I'm using osmocom and the built in audio server. Also, nothing else running, though I am connecting via RealVNC. Not sure if that would have any impact. Overall resource use is pretty low when OP25 is running. CPU @ 17% and Mem is 203 of 927.

I apologize, but I'm not sure what the "top -H" is.

Would you mind trying the boatbod version and see if that gives you the same problem. They differ in subtle ways, including the way sockaudio.py module sets up the alsa buffering.

You can build both versions more or less in parallel, but only one can "make install" at any given time.

mv ~/op25 ~/op25.max
git clone https://github.com/boatbod/op25 ~/op25.boatbod
ln -s ~/op25.boatbod op25
cd op25
mkdir build
cd build
cmake ../
make
sudo make install

Then when you want to swap between versions, just delete the sym link and make a new one pointing to the other version
rm ~/op25
ln -s ~/op25.max ~/op25
cd ~/op25/build
sudo make install

 

[wayside93]

I tried the boatbod version and it did the same thing. However, I had another SD card with a fresh copy of Raspbian on it. I started from scratch, using your version, and it worked flawlessly. I'm not sure what the issue was with the other install or if it had to do with something I had previously done, but at this point its working...and working well. In comparison to my scanner, the audio quality is on par, if not better.

Your version is working flawlessly.

Not sure what the issue was, but it seems to be gone now

Thanks again!

 

[boatbod]

That's weird. I can only think there must have been something wrong with the alsa drivers or asound.conf. Glad to hear it's working now.

 

[Dygear]

I tried the boatbod version and it did the same thing. However, I had another SD card with a fresh copy of Raspbian on it. I started from scratch, using your version, and it worked flawlessly.

That's weird. I can only think there must have been something wrong with the alsa drivers or asound.conf. Glad to hear it's working now.

I wonder how much the new SD Card played into it. Was the original not a Class 10? U1 / U3?

 

[wayside93]

I wonder how much the new SD Card played into it. Was the original not a Class 10? U1 / U3?

Its possible, though specs were so similar. The orig was a Samsung 32G Class 10 U1 (the one that didn't work). The one that did work was a PNY 16G class 10 U1.

Both purchased new within the last month and only used for this project. Odd, but it absolutely could be a user error on my part.

 

[wayside93]

Quick update, I cloned the functioning image to the 32gb card and everything was functioning flawlessly. Must have been user error on my part.

Thanks for all the help