OP25 Setting up op25 to stream to broadcastify

[slicerwizard]

the original dsd author was gone (thanks to dsd plus)

So dsdauthor last posted here in February 2013 and the first sighting of DSD+ was Christmas 2013, therefore DSD+ drove off dsdauthor. You guys are hilarious.

 

[KA1RBI]

So dsdauthor last posted here in February 2013 and the first sighting of DSD+ was Christmas 2013, therefore DSD+ drove off dsdauthor. You guys are hilarious.

There is sufficient evidence to support this. Bruce Perens (a founder of the Open Source Initiative) contacted the original dsdauthor who had several interesting things to say; some of which were mentioned in his "AMBE exposed" paper (available online via search)

* The “mbelib” developers created a D-STAR decoder
called “DSD” and published it, with “mbelib”, under the
BSD license.

* Another anonymous developer created a proprietary fork
called “DSD+” and declined to share his source code
with the original developers.

* The original developers know better now, and will put
their future work under GPL instead of BSD, but they
probably aren't going to do more work that helps DSD+.

* Mbelib has remained at release 1.0 for more than a year

Another perspective, from the same paper

* Recently, another closed-source DSD fork has
appeared called DSD Plus. [...] It greatly annoys me
that these improvements are locked out and
unavailable to people who want to make further
improvements. It annoys me even more that people
on the forums keep defending the choice of the
DSDPlus author to keep the software closed.

* I think the real pain for this developer of “mbelib”
was when he got a public “screw you” from what
was really his user community.

also I have personally heard through the grapevine that DSDPlus constantly lives in fear of DVSI and as well of NXDN's trunking patents...

Max

 

[Night_Watchman]

Yes, this absolutely is possible and just requires the correct setup in asound.conf. The advantage over trying to monitor your own stream via broadcastify is far less delay (it's instantaneous).

rx.py needs to output to "mout0" device
darkice.cfg needs to receive from "loop0" device

(code snipped)

Boatbod,
Will this allow me to monitor my stream through the HDMI port on a Raspberry Pi or would it need to be modified?

 

[boatbod]

Boatbod,
Will this allow me to monitor my stream through the HDMI port on a Raspberry Pi or would it need to be modified?

The only modification would be to change hw:0,0 to whatever values are needed to select the HDMI port. Perhaps "hw:1,0"?

 

[Night_Watchman]

The only modification would be to change hw:0,0 to whatever values are needed to select the HDMI port. Perhaps "hw:1,0"?

That was a quick reply! Thanks!

Edited to add: Just tried it on my backup Pi. Works like a charm, although HDMI port turned out to be hw:0,1.

 

[slicerwizard]

* The “mbelib” developers created a D-STAR decoder
called “DSD” and published it, with “mbelib”, under the
BSD license.

* Another anonymous developer created a proprietary fork
called “DSD+” and declined to share his source code
with the original developers.


When DSD was released, it did not do anything useful with D-Star (certainly no voice decoding) so it wasn't "a D-STAR decoder" and when DSD+ showed up, neither it nor the current version of DSD did anything with D-Star.

So your source isn't particularly reliable, for starters.

 

[KA1RBI]

well in the end I can't and don't speak for DSDAuthor, he must do so for himself, if and when he should so choose.

Nonetheless, here are some facts:

Fact: there are two success reports from OP25 users monitoring dstar, right in this thread.

Fact: some of the code in OP25 that decodes dstar originated in DSD (and was duly credited).

Fact: one hundred percent of the OP25 code is published under an open source license. The dstar modules from DSD retain the original BSD license and the remainder is licensed under the GPL V3.

Fact: I know of other open source projects that have borrowed code and various designs and logic from OP25 (I'm delighted); also we've received many code contributions and bug fixes, all that would have been impossible had the source been withheld.

Fact: the OP25 authors made the decision long ago to go with free/open source under the GPL. I fully share the annoyance voiced in the following quote:

* Recently, another closed-source DSD fork has
appeared called DSD Plus. [...] It greatly annoys me
that these improvements are locked out and
unavailable to people who want to make further
improvements. It annoys me even more that people
on the forums keep defending the choice of the
DSDPlus author to keep the software closed.

There is every reason to believe this is an honest representation of the sentiments of DSDAuthor. Otherwise his decision to release the original DSD as source code would make no sense...

Max

 

[kb9mwr]

So dsdauthor last posted here in February 2013 and the first sighting of DSD+ was Christmas 2013, therefore DSD+ drove off dsdauthor. You guys are hilarious.

Well it was mostly an assumption on my part. I am not much of a coder, but know my way around a Linux system. I'd venture to say most people who write things with the sources available do so, so that others can learn/tinker and benefit from their work (if they so choose), rather than just be an end user.

If I were dsdauthor, and someone else came along with a similar software and were not sharing how they made improvements to the same concepts, I'd feel slighted.

Anyway I am glad a few like Max are carrying on in that sharing spirit. It makes a whole lot more sense to me than effectively forcing the next guy to start from square one.

 

[telvana]

What would be the easiest way to pipe the audio from a tinkerboard running dietpi to a local client?

 

[boatbod]

What would be the easiest way to pipe the audio from a tinkerboard running dietpi to a local client?

Several ways to do this assuming you are talking about running op25 on the tinkerboard.

i. Use op25's native capability to send raw udp audio frames over the network, then use the included audio.py app on the local machine to receive and play the audio. Local machine will need to be running some sort of linux distro.

ii. Set up an icecast client on the tinkerboard much like you would if you were streaming to broadcastify, but have it send the stream to a local ices server. This would allow you access to the stream from any local machine with a compliant web browser. Downside is of course the complexity of setting everything up.

 

[Atlantauser]

Intel NUC?

I was having a ton of trouble making the NUC's audio work. Ultimately found this link that had a different way of loading aloop.
https://stackoverflow.com/questions...ror-could-not-insert-snd-aloop-no-such-device

had to use this line in /etc/modprobe.d/hda-intel.conf

options snd slots=snd-hda-intel,snd-hda-intel,snd-aloop

The aloop loaded correctly. And then all the work to connect darkice and op25 worked together.



There's still some things I like about SDRTrunk better though. So far it doesn't seem that easy to tell if I'm catching all the traffic, and if I am, is it then making it to darkice properly... Need more instrumentation to diagnose problems easier.

 

[jhaab]

I am also trying to stream out to IceCast2 server (stream0) and to have local audio out the 3.5mm or USB port. My OP25.sh is set to the following but cannot seem to get it to work with anything I try. Any suggestions or things I am missing from this or things I should check?
#!/bin/bash
mypath='realpath $0'
cd 'dirname $mypath'
pwd
./rx.py --nocrypt --args "rtl=0" --gains 'lna:35' -O 'loop0' -S 960000 -d 0 -v 1 -q 0 -2 -U -T star-trunk.tsv 2> stderr.stream0.2

 

[boatbod]

If you want the audio to stream to a loopback device and a local sound card you'll need to modify your asound.conf to include a dsnoop to clone the pcm stream. I posted an example in this forum a while back which you can probably adapt and modify.

 

[jhaab]

Boatbod, thanks for info. I was able to get the audio out the 3.5mm after your advise. I am actually now going to feed into a Shoutcast2 Server from Darkice. Is there a way to test to make sure Darkice is receiving the stream or attempting to send it back out to the Shoutcast server. I am not sure if I am dealing with Darkice problems or Shoutcast through my provider.

 

[boatbod]

Boatbod, thanks for info. I was able to get the audio out the 3.5mm after your advise. I am actually now going to feed into a Shoutcast2 Server from Darkice. Is there a way to test to make sure Darkice is receiving the stream or attempting to send it back out to the Shoutcast server. I am not sure if I am dealing with Darkice problems or Shoutcast through my provider.

I set up a local ices2 server and stream in to that to test darkice.

 

[jhaab]

I want to thank Boatbod and the people that has provided some assistance along the way for this project and learning a lot. I have OP25 on Raspberry Pi setup with (1) SDR and (1) stream (/stream0) feeding to IceCast2 successfully. I was looking to take the next step and get a 2nd stream out of that same SDR for a different talk group via a wl and feed that into IceCast2 as stream/1. From all the things I have read, It looks like that is possible unless I am mis-reading something. Based on that, I have my asound.conf currently set to the following shown below. Am I correct that I would setup another Darkice config file (Example /darkice-stream1.cfg) and then another OP25.sh script (Example OP25-stream1.sh) and direct that to reference the appropriate ALSA loopback? (Example: loop1) I would then create another service for both the OP25 and Darkice. They would then reference OP25-stream1 and darkice-stream1. If I am on the proper path, I am just trying to figure out the proper method of setting up the asound.conf or running into issues with that but sure I am overlooking something along the way..

# output device
pcm.loopout0 {
type dmix
ipc_key 328211
slave.pcm "hw:Loopback,0,0"
}

# input device
pcm.loopin0 {
type dsnoop
ipc_key 686592
slave.pcm "hw:Loopback,1,0"
}

# duplex plug device
pcm.loop0 {
type plug
slave {
pcm {
type asym
playback.pcm "loopout0"
capture.pcm "loopin0"
}
}
}

pcm.mout0 {
type plug
slave.pcm mdev0
route_policy "duplicate"
}

pcm.mdev0 {
type multi

slaves.a.pcm "hw:Loopback,0,0"
slaves.a.channels 2
slaves.b.pcm "hw:0,0"
slaves.b.channels 2

bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
}

 

[boatbod]

To make a second stream you need:
- a second rtl device
- a second instance of op25
- a second instance of darkice (or your streaming software of choice)

Basically you make additional config files and ensure that neither the op25 audio device, udp port or log file conflict then let it run in parallel.

 

[dMonies327]

Ive got op25 and darkice working fine on an rpi3b+ for a single mono feed, but would like to seperate fire and law. Would it be possible to use this setup / darkice to use two instances of op25 (and dual rtls) to a single stereo feed?

 

[boatbod]

Ive got op25 and darkice working fine for a single mono feed, but would like to seperate fire and law. Would it be possible to use this setup / darkice to use two instances of op25 (and dual rtls) to a single stereo feed?

Theoretically yes. The configuration is considerably more complex because you have to turn off the built-in audio decoder (remove -U option) from both op25 instances, then configure each appropriately to send udp audio over different port numbers and finally run a copy of audio.py with the appropriate options to pick up the two udp streams and send them to a single stereo alsa device.

./rx.py --args "rtl=0" --gains 'lna:36' -S 960000 -T trunk-fire.tsv -V -2 -w -W 127.0.0.1 -u 23456 -U 2> stderr-fire.2
./rx.py --args "rtl=1" --gains 'lna:36' -S 960000 -T trunk-leo.tsv -V -2 -w -W 127.0.0.1 -u 23458 -U 2> stderr-leo.2

./audio.py -O loop0 -u 23456 --two-channel

The important consideration is to set the wireshark udp ports (-u) so they are at "X" and "X+2" respectively, otherwise two channel audio mode won't work correctly.

By the way, how do you configure a single instance of darkice to split a stereo feed into two separate streams?

 

[dMonies327]

By the way, how do you configure a single instance of darkice to split a stereo feed into two separate streams?

Dont think I'm following you there, or there's a miscommunication somewhere.
I'm currently streaming several of the talk groups on our p25ph2 system to a single feed, and it's quite busy.
Rather than split them on completely seperate streams, I'd like to be able to have two instances of op25 running (One for the Leo's and the other for fire) and put both of those on one stream but in seperate (L/R) channels.