Yeah it's pretty fascinating what you can do with it. The other night I tried streaming the P25 system to my shoutcast server and it worked but seemed severely delayed and then eventually seemed to keep replaying the same thing on a loop.
There are several delays when listening with software like SDRTrunk. In a typical radio, designed to listen to P25 Phase I or P25 Phase II audio, you have a chip produced by Digital Voice System, Inc. that a digital stream, in either IMBE or AMBE2+ codec, is fed into it and analog audio comes out of it; a purpose-built chip that does all the processing for that function and that function only. It is a proprietary conversion process. In SDRTrunk, it uses a reverse-engineered method for decoding this stream using the processing power of your computer. This is a bit of a grey-area legally, which is why the program is not distributed as executable code, but the source code is downloaded separately and compiled on your machine before use. DVSINC charges manufacturers different prices, depending on how many devices they sell, but they make money off of each and every device. SDRTrunk, on the other hand, bypasses this process and is free. If you were to look at the source code for the software, you will see legal text regarding it being for "educational uses" and being not responsible for its use. Notwithstanding legal issues, using software to decode IMBE and AMBE2+ as opposed to a purpose-built chipset has its pros and cons. One pro is that you can initiate multiple instances of it at a time, meaning that as long as you have the computing power, you can simultaneously decode multiple audio streams. Some of the cons include that it is not as efficient and uses computing power of your main CPU and this processing power takes more time to complete than dedicated circuitry. Usually, this delay is only fractions of a second to a second or two, but it is a delay none-the-less over the proprietary chipset. Now, you want to feed this audio to a streaming service like Shoutcast, Icecast or Broadcastify... which typically receive the audio in an MP3 audio format. Now, this same computer is needing to convert the audio coming out of the software converter and run it through a lossy compression format, using even more CPU time. I forgot to mention that SDR in itself requires CPU processing to decode the many different transmissions it is watching simultaneously and tracking the control channel and choosing what bit of digital stream to send to the software decoder. After all this, there is network latency in getting it from the source computer to the stream server and then from the stream server to the streaming client listening. All of these steps add time and use computer resources.
It is because of the sheer amount of CPU processing that you need to have some decent computing power, which is why it really wouldn't work well on a Raspberry Pi or a 15+ year old computer. Depending on the system you are listening to and how you plan on sharing the audio can dictate how much processing power you will need.
In my case, I am using a dedicated machine to listen to and feed the City of Roseville system. I send a feed of police and fire to Broadcastify, in both their traditional method as well as their new Node Calls system. I also send all the police traffic in one stream and all the fire traffic to my Icecast server from this system. This computer uses a dual-core i3-540 CPU with 8 GB of RAM. This is just barely adequate for the Roseville system. I do not want to bog down the computer with other crap that isn't needed so I installed Ubuntu Server (currently 20.04.1) with a minimal GUI added (SDRTrunk requires a graphical user front-end). I only installed the absolute minimum to get it running.
