OP25 Horrible audio quality after Raspbian update

[BrianC0000]

Boatbod fork - even rebuilt from scratch to be on the safe side... but since updating my Pi 3 B last night, my audio is all garbled and unintelligible. I have a nasty feeling that a Raspbian update to Python is causing this (?)
No errors in my logs.. my startup commandline is as follows:
rx.py --args 'rtl' -N 'LNA:47' -S 1024000 -f 772.98125e6 -o 25000 -q -0 -T trunk.tsv -V -2 -U 2> stderr.2

My plot looks amazing, so it doesn't seem to be a SDR tuning issue, but rather a decoding issue.
Python looks to be at version 2.7.13

 

[boatbod]

Python shouldn't change much or have much impact on audio performance. I suspect a kernel change in ALSA buffering our something along those lines. Try swapping to liqiidsoap Pulse audio rather than native ALSA.

 

[zapman987]

Why are you stating a freq as well as a trunk file? normally the trunk has the freq (I think it may even override it.)

I dont disagree with boatbod but was there any network changes (including drivers, etc)? Maybe something there, dropped packets, etc.

 

[BrianC0000]

Why are you stating a freq as well as a trunk file? normally the trunk has the freq (I think it may even override it.)

I dont disagree with boatbod but was there any network changes (including drivers, etc)? Maybe something there, dropped packets, etc.

Is that right? I actually thought that defining it in this manner set the "primary" control channel when there are alternates.

 

[zapman987]

That may be true, and if so, my bad. I only monitor sites with 1 primary freq, which I set in trunk.tsv.

 

[boatbod]

The -f option is only used when there are no control channels defined in trunk.tsv. Primarily this means when receiving P25 Conventional.

In prior versions, and possibly still with osmocom, you needed to specify -f to get the radio to start. I took care of that hiccup a good while back, so it's not strictly necessary these days, but won't hurt if present.