Ok thanks, will test this and post back results.
Thanks
Thanks
OP25 Setting up op25 to stream to broadcastify
- Thread starter boatbod
- Start date
- Status
boatbod
Member
There is a way to use another module called dsnoop that will allow you to both loopback and monitor the audio locally. Its somewhat more complex so not worth doing unless you really want that capability.
It works. Audio is heard on the stream. Nice !
Only thing is that the audio is a bit low. I've made sure everything on all sound cards were at 100% in alsamixer, but audio is still low. I believe you once said in a reply, that nothing could be done in OP25 as for audio levels.
However, I know there is a setting in lame that could be used to boost the audio:
--scale <arg> multiply PCM input by <arg>
For another stream I'm feeding to Broadcastify (a local analog ham radio repeater), I'm using another RPI (2B) and SDR dongle, and setup was made using the instructions on Radioreference:
https://wiki.radioreference.com/index.php/Raspberry_Pi_RTL-SDR_Broadcastify
It's a single command line with rtl_fm, lame and EZ-Stream. Audio was also low on that, so I've inserted the --scale 3 argument in the lame part of the command line, and it boosts audio a bit without distorting it.
Command line used, and inserted in /etc/rc.local to mak it run at boot:
/usr/local/bin/rtl_fm -d 0 -M fm -f 146.61M -p 51 -l 68 -g 48 -t 2 -E pad -s 12k | /usr/bin/lame -r -s 12 --scale 3 --resample 22.05 -m m -b 16 --cbr --lowpass 5 - - | /usr/bin/ezstream -c /etc/ezstream_bcfy.xml > /home/pi/log/bcfy2.log 2>&1 &
Since Darkice is also using lame, I've checked in the darkice.cfg manual to see if the --scale argument could be inserted somewhere in it, so that it would be passed on to lame, but I did not find anything about it. Unless I missed something, I'm wondering if the same method could be used with op25, instead of using Darkice. It would allow to insert the --scale argument to boost audio a bit for the stream.
Anyhow, thanks for your work Boatbod !
boatbod
Member
Great to hear that it's working. Implementing an audio gain in op25 would require sockaudio.py to scale the samples it sends to libasound. It's probably not that difficult, but I don't think it's a straight linear operation and may take me some time to research and figure out.
Perhaps more useful would be if it could implement an AGC to even out the levels. I know there are algorithms and tools out there (such as lame) but for efficiency and ease of setup it all needs to work inside python to avoid external library calls.
Searched if something could be doable in ALSA, and apparently a "preamp" type cursor could be added in asound.conf, to add a volume cursor in alsamixer, that would allow to amplify the pcm signal up.
Sources : https://www.reddit.com/r/archlinux/comments/2vb1wm/artificially_boosting_alsa_audio_above_100/
Alien Pastures » Adding an ALSA software pre-amp to fix low sound levels
Something like: (sample codes not adapted to your snd-aloop module settings):
pcm.!default {
type hw
card 0
}
ctl.!default {
type hw
card 0
}
pcm.!default {
type plug
slave.pcm “softvol”
}
pcm.softvol {
type softvol
slave {
pcm “dmix”
}
control {
name “Pre-Amp”
card 0
}
min_dB -5.0
max_dB 20.0
resolution 6
}
or:
pcm.!default {
type asym
playback.pcm "plug:softvol"
capture.pcm "plug:dsnoop"
}
pcm.softvol {
type softvol
slave.pcm "dmix"
control { name "PCM"; card 0; }
max_dB 32.0
}
Would something like this be feasible and adapted to the asound.conf ?
Sources : https://www.reddit.com/r/archlinux/comments/2vb1wm/artificially_boosting_alsa_audio_above_100/
Alien Pastures » Adding an ALSA software pre-amp to fix low sound levels
Something like: (sample codes not adapted to your snd-aloop module settings):
pcm.!default {
type hw
card 0
}
ctl.!default {
type hw
card 0
}
pcm.!default {
type plug
slave.pcm “softvol”
}
pcm.softvol {
type softvol
slave {
pcm “dmix”
}
control {
name “Pre-Amp”
card 0
}
min_dB -5.0
max_dB 20.0
resolution 6
}
or:
pcm.!default {
type asym
playback.pcm "plug:softvol"
capture.pcm "plug:dsnoop"
}
pcm.softvol {
type softvol
slave.pcm "dmix"
control { name "PCM"; card 0; }
max_dB 32.0
}
Would something like this be feasible and adapted to the asound.conf ?
boatbod
Member
Absolutely it could be added in. You'll probably have to experiment a bit to find out exactly where to insert it in the chain.
Did a lot of experimentation today. Was not able to enable mixer control for the loopback device.
Also, read that pavucontrol would allow increasing the volume levels up to 160%, so I tried this, which has installed pulseaudio, and it screwed everything...
Before that, I didn't even need to use audio.py / audio.sh, the stream was working without this. After that, even after unintalling / purging pulseaudio and everything associated with it, I wasn't able to recover and the stream would not work, even with or without audio.sh.
So now, I've had to restart fresh with a new Raspbian Stretch image, and have to reconfigure everything. Back to the drawing board...
boatbod
Member
Bummer.
If it's any consolation I did implement a (rather crude) audio gain control/pcm scaler that you can set from the command line. It appears to work satisfactorily enough, but if you set the gain too high you will clip the samples and distort the audio.
The new feature is accessible from both rx.py and audio.py using the "-x" parameter with a floating point number as an argument.
e.g. "-x 1.0" results in unity gain, "-x 2.0" multiplies by two, "-x 0.5" cuts things in half.
You'll need to 'git pull' to get the changes (or maybe not if you are re-imaging) but the changes are only in python code so no recompilation is necessary.
Wow ! Thanks Boatbod ! You're the best !
Was able to redo everything after a couple of hours, but did not get the updated code. I'll do the git pull tonight and will post back results. I owe you a couple of beers !
Did some tests and is working nicely ! I was able to apply up to 10X without distorting things much. Does the job well, thanks so much for that
In a update f my situation, got authorized to stream on Broadcastify the audio of the local D-Star repeater. The audio of the C4FM/Fusion local repeater was already setup and working nicely.
Since both repeaters were 2,17 MHz apart (144,95 and 147,12), I wanted to use multi_rx.py so that I could use only one RTL-SDR dongle to receive both signals, since a normal dongle usually has a 2,4 MHz bandwidth. And I already had one spare dongle, so I figured that I would not have to buy another dongle.
The json file for multi_rx.py had all parameters for both signals, and the "device" frequency set right in the middle between both receiving frequencies (at 146.035 MHz). Both signals were set to use loop0 and loop1 loopback audio devices, and separate cfg files + service were made for Darkice, as per Boatbod's instructions in the 1st post of the present topic. Separate audio.sh were used with the -2, -O loop(x) and -x parameters.
When I tried streaming both audio streams at the same time, I got an error message stating that sockaudio was already in use. So I figure both instances of audio.sh cannot be used at the same time, like I want to do in my setup. Also, when checking the status of the op25 service, I was getting mssages for the reception of ysf signals, but not for any reception of d-star signals (there was activity on both frequencies at the same time)
Questions:
- is multi_rx.py capable of achieving what I want to do (receive and decode 2 signals at the same time that are encoded with different protools (ysf and D-Star in my case) ?
- can 2 instances of audio.sh / sockaudio.py be ran at the same time , on the same machine ?
Thanks
Since both repeaters were 2,17 MHz apart (144,95 and 147,12), I wanted to use multi_rx.py so that I could use only one RTL-SDR dongle to receive both signals, since a normal dongle usually has a 2,4 MHz bandwidth. And I already had one spare dongle, so I figured that I would not have to buy another dongle.
The json file for multi_rx.py had all parameters for both signals, and the "device" frequency set right in the middle between both receiving frequencies (at 146.035 MHz). Both signals were set to use loop0 and loop1 loopback audio devices, and separate cfg files + service were made for Darkice, as per Boatbod's instructions in the 1st post of the present topic. Separate audio.sh were used with the -2, -O loop(x) and -x parameters.
When I tried streaming both audio streams at the same time, I got an error message stating that sockaudio was already in use. So I figure both instances of audio.sh cannot be used at the same time, like I want to do in my setup. Also, when checking the status of the op25 service, I was getting mssages for the reception of ysf signals, but not for any reception of d-star signals (there was activity on both frequencies at the same time)
Questions:
- is multi_rx.py capable of achieving what I want to do (receive and decode 2 signals at the same time that are encoded with different protools (ysf and D-Star in my case) ?
- can 2 instances of audio.sh / sockaudio.py be ran at the same time , on the same machine ?
Thanks
boatbod
Member
To run two instances of audio.py you'll need to override the udp port from it's default (23456) because only one application can open a single port at any given time.
e.g.
./audio.py -w 23456 -O loop0
./audio.py -w 23460 -O loop1
You'll also need to make corresponding configuration edits to cfg.json to make sure that the second decoder destination is the port which you want audio.py to listen on.
e.g.
"destination": "udp://127.0.0.1:23456",
"destination": "udp://127.0.0.1:23460",
Thanks, that part is working now. Everything was already configured as such, but only had to change the udp port for the 2nd stream for 23460 instead of 23458
As for the reception and decoding of 2 signals at the same time that are encoded with different protocols (ysf and D-Star) with only one dongle using multi_rx, should I consider getting a 2nd dongle and just use 2 sessions of rx.py instead ?
Last edited:
boatbod
Member
I can't really answer about the capabilities of multi_rx since I've not spent any time using or experimenting with it. Theoretically I believe it can do what you are trying to do, but two dongles and two separate instances of op25 are undoubtedly going to work wheres what you have now is more of an experiment.
ETA: although ysf and d-star both share the demod type (fsk4) it appears they use a different filter_type (rrc vs gmsk) so could be an explanation for the difficulty getting both to work on the same dongle at the same time.
By the way, I avoided port 23458 because that's where the second timeslot of a DMR system will appear if the first timeslot comes out on 23456.
Last edited:
Yesterday, had to order something on Amazon for my youngest son (some figurine we can't find locally), and have decided to order a NooElect dongle at the same time, so that I can use 2 instances of rx.py instead of multi_rx.py, since it's probably the different filter_type needed for both modes that causes me problems. Audio works on the ysf stream, but not on the D-Star one, with multi_rx.
I've checked the arguments needed for D-Star with rx.py for filter_type, but I'm not sure about this. Is it the -V for vocoder (rrc / gmsk) ?
I think for both modes, I'll have to use -D fsk4 ; but for filter_type, is it -V rrc for YSF, and -V gmsk for D-Star ?
In the help text file, I can't see what's the options argument for filter_type.
Also, is excess=bw needed for D-Star decoding ?
Thanks for all your help
I've checked the arguments needed for D-Star with rx.py for filter_type, but I'm not sure about this. Is it the -V for vocoder (rrc / gmsk) ?
I think for both modes, I'll have to use -D fsk4 ; but for filter_type, is it -V rrc for YSF, and -V gmsk for D-Star ?
In the help text file, I can't see what's the options argument for filter_type.
Also, is excess=bw needed for D-Star decoding ?
Thanks for all your help
boatbod
Member
rx.py only supports P25 (conventional and trunked). You'll still have to use multi_rx for anything else.
KA1RBI
Member
sorry you had this trouble, d-star currently has a known issue on rx. Once that's fixed you should be able to receive two separate channels at the same time (with a single sdr) provided of course the two frequencies both fit within the scan band of the sdr. Since each channel sets the demod and filter modes independently, there is no problem if two (or more) separate channels use different demod parameters...
Max
Thanks for the update, Max. Any ETA on that fix ?
I've configured a 2nd dongle for the reception of the D-Star local repeater with multi_rx.py. But I've tried several parameters in the json file, and cannot make it decode D-Star. I know there is a bug in D-Star decoding in op25, as KA1RBI stated, but does somebody know what is the nature of that bug ? If D-Star decoding is doable even what that bug, any ideas on the needed arguments in the json file to make that work (besides rrc and gmsk) ?
Thanks
Thanks
Last edited:
boatbod
Member
I don't know that it will necessarily help, but you should try using the osmocom "max" branch version of op25 if you want to be sure you have the latest multi_rx codebase. The downside is you won't have quite the same sockaudio support (or P25 trunking features) but maybe it's a way to get D-Star working sooner?
- Status
