To better understand, do you want to specify a TG and follow that TG exclusively for the audio output on a specific decoder channel?
Is the reason behind the tuner-talkgroup lock because you have a directional antenna on specific dongle?
If you could pool your tuners, using one of them as the control channel decoder and the others chasing traffic channels, with specific talkgroups each directed to their own audio output, would that also work?
Yes. The underlying reason behind this is to get a specific sets of TGs on a P25 system routed to specific virtual audio cables to DSD. Basically I used to provide feeds for my town and a neighboring town using old cheap scanners. My town changed to P25 first a couple years ago, and forced me to buy a P25 scanner for my own use.. I originally was not going to dedicate a $400 scanner to my feed, but it turned out to be a little easier for myself if I did. So I put my town feed back up with my Pro 197.
The neighboring town up till a few months ago was still on a Motorola II system, but has since switched onto the P25. I am absolutely not going to buy a second P25 scanner for that feed, but if I can do it via SDR, I don't mind. I bought a dozen RTL dongles to play with a while back, but SDR# was a nightmare, and it bogged my system down.. So I shelved them.
When Unitrunker added native support for the RTL and no longer required SDR#, I thought it was the perfect solution.. However when I set it up, I learned that if you have more than one voice dongle, they just act as "overflow" receivers - that is, all it does is route simultaneous transmissions to the next available voice receiver. That's neat and it works really well (even better than a scanner in fact) if you're just listening, but it's useless for streaming a feed.
What I need (and like I said if you can do this, it will open up a whole new realm of P25 feed availability) is the ability for the control software to route specific TGs to specific voice dongles all the time, like this:
Dongle#
1: Control Channel
2: TG 1234, 5678, 9098, and 7654, outputting to VAC1 -> DSD1.exe -> VAC4 -> Stream1
3: TG 4321, 5432, 4567, and 0098, outputting to VAC2 -> DSD2.exe -> VAC5 -> Stream2
4: TG 2345, 9345, outputting to VAC3 -> DSD3.exe -> VAC6 -> Stream3
All other TGs can be ignored/not routed.
This would allow me to have one machine streaming three separate agencies, using four dongles and a single instance of the trunking control program..
KD0TAZ & dw2872,
You should be able to do what you want by running multiple copies of UT. Yes native support will be cool, but I don't think you need to wait.
Say you have 4 sdr sticks
Stick 1 Will be your trunk source
Stick 2 Will only track TG's Dispatch 1 & 2
Stick 3 Will only track TG's TAC 1,2,3
Stick 4 Will track everything else
First Copy of UT
Stick 1 as Source (but have the audio output to set to a free Virtual Audio Cable source) and mute unchecked.
Stick 2 as Voice follow like normal.
All other talk groups will be locked except (Disp 1 and Disp 2)
Second Copy of UT
Source input will be Discriminator with the audio input of the VAC you set as the output in the first copy of UT
Stick 3 as Voice like normal
All other talk groups will be locked except (Tac 1,2,3)
Third copy of UT
Source input will be Discriminator with the audio input of the VAC you set as the output in the first copy of UT
Stick 4 as Voice like normal
Then just lock out Disp 1, 2, TAC 1,2,3
**Each copy of UT will need to run from its own data folder
Dylan
Yeah considering this would be used to provide feed streams, and would need to run unattended and be able to recover itself in the case of a reboot, that's not an option. The more things can be done natively by one program the better. It's already still kludgy having to open an instance of DSD+ for each dongle in order to decode the audio, having to run multiple instances of the trunking control program just makes things even messier.