DSheirer / sdrtrunk

A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR). Website:
GNU General Public License v3.0
1.55k stars 252 forks source link

Audio queuing issue #1702

Open cfc62 opened 10 months ago

cfc62 commented 10 months ago

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.

cfc62 commented 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.

ErikSwan commented 9 months ago

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.