Open cfc62 opened 10 months ago
Note: this happens on Airspy as well as RSP1A, and on both the 6 MSPS Airspy as well as the 10 MSPS Airspy.
There's a good demonstration of this issue in this clip at around 3 seconds into the clip: https://www.youtube.com/clip/UgkxFBiPfuboBEZ3R7Ev4LgZzeoW4Oge-1Hi
The response from the dispatcher on ISP Dist 3 Prim
("629...") plays on the right channel before the initial call from unit 629 that prompted it ("Control, 629...") plays on the left channel.
I'm guessing the original motivation behind this design decision to queue up traffic on one audio channel was to make things easier to listen to, but on a very busy system it all sort of breaks and results in calls being played out of order, which in my opinion should never be allowed to happen.
sdrtrunk Version Seen on both the new beta as well as beta 2 (v0.6.0)
Describe the bug When listening directly on SDRTrunk (not using rdio-scanner or similar), at times overflow audio is not played on the right hand channel but is queued up on the left channel and plays after the initial audio stops.
As an example, lets say TG/frequency A starts being received and audio heard on the left channel. Then, some time later TG/frequency B starts being received, the audio is not heard immediately on the right hand channel, but rather is heard on the left channel after the transmission on A completes.
To Reproduce Easy to reproduce, simply listen to a system with parallel TG traffic and or 2 FM channels with overlapping traffic.
Expected behavior TG B should be heard on the right channel as soon as it is received and not queued on the left channel.
Bottom line, the right channel is not used as much as it has in previous versions. In some cases some transmissions are heard out of order.
Assigning priorities was of limited effect, while the issue may have declined somewhat, it still occurred.