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 !Oops, yes multi_rx so what's important is the audio.sh command line.
Try this one:
./audio.sh -2 -O loop0
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.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:
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 !
Did a lot of experimentation today. Was not able to enable mixer control for the loopback device.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.
Bummer.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...
Wow ! Thanks Boatbod ! You're the best !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.
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 thatWow ! 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 !
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.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, 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 23458To 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.
./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.
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.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 ?
rx.py only supports P25 (conventional and trunked). You'll still have to use multi_rx for anything else.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
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...Y Audio works on the ysf stream, but not on the D-Star one, with multi_rx.
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?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) ?