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.6k stars 256 forks source link

Streaming - Audio stutter? #110

Closed chudgoo closed 7 years ago

chudgoo commented 7 years ago

So while streaming to broadcastify, I've noticed that when there is a short burst of voice like "copy that" or the like, it is often repeated a couple times. It seems like the shorter the clip is, the more repetitions are played. Also if another call happens immediately after a short call, the preceding call doesn't repeat.

I recorded a quick video of this phenomenon. https://www.youtube.com/watch?v=kfyMpcKCQ9I

DSheirer commented 7 years ago

It looks/sounds like the entire call snippet is being repeated. Can you check your alias list and see if you have the same broadcast channel listed twice for any of the aliases?

chudgoo commented 7 years ago

screen shot 2017-01-14 at 1 08 03 pm

screen shot 2017-01-14 at 1 10 55 pm

Here's what I am currently working with. There's only one broadcast channel set up

DSheirer commented 7 years ago

I'm scratching my head on this one :-)

Could you please test/answer two more things for me:

1)Do you have more than 1 channel decoding the same call/channel when this happens?

2)Can you listen to the stream with another client, like a cell phone or another desktop streaming client, at the same time you're using the streaming client from the youtube video, to see if both clients are producing the same audio with the same stutters.

Thanks for your help in tracking this down.

Denny

chudgoo commented 7 years ago

Crud! Sorry! I figured this might be a "oh! that. oops. fixed" type thing...

1) Yes, as of yesterday I had three control channels enabled... Which is kind interesting... The most repeats I heard for any given call was three. I had been listening for several hours and never heard more than three. I just attempted enabling all five control channels, (only one active at a time, obviously) and heard four repeats on calls. I changed it to only have the one active control channel enabled and heard NO repeats...

Another thing is that I'm using two tuners. The local P25 system starts at 406MHz, so I have one centered on 407MHz and another on 408MHz.

13:35:23.286 INFO source.tuner.TunerManager - usb device [0BDA:2838] LOADED: RTL2832 SDR/R820T 00000001 13:35:24.899 INFO source.tuner.TunerManager - usb device [0BDA:2838] LOADED: RTL2832 SDR/R820T 00000001

2) I listened with another laptop with the "HTML5 web player" on the broadcastify site, an iPhone using the iOS Broadcastify app and the local audio coming from the source laptop.

In what I've tested, it seems to be related to the number of control channels that are enabled.

DSheirer commented 7 years ago

Right now there's nothing that will de-duplicate audio when the same call occurs across multiple sites, in situations where you have multiple control channels/sites enabled for the same system.

Do you agree/think that is probably what is happening? The same call is being multi-cast across multiple sites/control channels?

chudgoo commented 7 years ago

Hmmm... not sure. So on this particular P25 system here, there are two transmitter towers (LSM/simulcast), one "site" and only one active control channel at a time. When only the active control channel is enabled, things seem to be stable and repeat-free. I could set you up for VNC to this machine if you think of anything else that you'd like to check out.

DSheirer commented 7 years ago

Earlier you said that you're seeing the audio stuttering/repeats when you have multiple control channels enabled. I guess I assumed that these other control channels were for other sites that are all part of the same system and that the duplicate audio was from the same call being transmitted at each of the different sites. With LSM, you can have multiple towers as all part of the same site to expand the site's coverage area.

If that's not the case, when you have multiple control channels enabled, how are all of the control channels related to each other, if at all?

chudgoo commented 7 years ago

The additional control channels being enabled was my way of not losing the CC when they do their periodic CC frequency rotation. It's only one "site", consisting of two transmitter towers. There are no other sites involved. When I was using SDRTrunk > Soundflower > B.U.T.T., I didn't see this type of issue.

Do you think this issue would settle itself if control channel following were added so that multiple CCs didn't need to be enabled?

DSheirer commented 7 years ago

Yes, I think the control channel following enhancement would solve the issue.

Your previous streaming arrangement with soundflower and BUTT was using the audio output as the feed source and that was limiting audio playback to just one call, even though multiple instances of the call may have been decoded. The new streaming feature allows all calls from all channels to be queued for streaming - but there is no code to check for duplicate calls prior to streaming.

My suspicion is that one of the alternate control channels that you had enabled was for the same frequency as was allocated for the voice/traffic call, which would have resulted in the alternate control channel decoding the call while the primary control channel caused an additional traffic channel to be allocated on the same frequency to decode the same call, producing twice the audio. Do you think this is plausible with what you were seeing?

chudgoo commented 7 years ago

Actually that sounds very plausible. I'm watching the event log and it's kind of surprising to see just how many times the other CC freqs are reused. The majority of calls happen ~1Mhz higher than where the CCs live, but there are a fair number that happen on the (unused at the time) CC freqs. When a call comes in on an unused CC, it lights up blue at the top where the idle CCs are AND at the bottom as its own call. I'm guess that control channel following would probably be easier to implement than audio dupe checking... is that a fair assumption?

DSheirer commented 7 years ago

Will address issue of rolling control channels in issue #61

Rylvir commented 7 years ago

I am getting the same issue on an Icecast stream, with some calls (generally short responses) repeated once. The issue only surfaced when I started using the native streaming in SDRTrunk. Prior to streaming natively I had used SDRTrunk > darkice > icecast for months and had never heard any repeated traffic (same playlist minus streaming options) So I don't think its a playlist issue, but I'll start there. I'll dig into my playlist tonight and try to catch it in action. Also the control channel rarely has changed on this system but I'll check into that as well. Cheers

CGUTH commented 7 years ago

I'm having the same issue using Icecast, same issue as @Rylvir I only have one control channel enabled and the audio on the computer running SDRTrunk sounds fine but the stream starts having doubles and then the queue builds up due to it. When I use butt to stream to my icecast server it does not have this issue.

Update: It seems to only do it if I have more than one stream enabled at a time. A single stream is fine.

DSheirer commented 7 years ago

@CGUTH can you capture the call event log from the control channel when this duplicate audio streaming occurs and let me know if you see more than 1 call event for the call/talkgroup, possibly occurring on different frequencies?

CGUTH commented 7 years ago

Every time it has happened there was only one call active on that talk group /frequency. It seems to only really happen when I have more than one stream going.

Every now and then (very rare) while only one stream is running I will still hear a double for a very short call.

I can duplicate the issue every time I try to do more than one stream.

What I was trying to do was a West Police stream, a Phoenix Regional Fire stream and a Misc TG stream for the members of the radio club I am part of. I am streaming only to my personal Icecast server.

DSheirer commented 7 years ago

Ok, I just went through the code again and I think I may have found what's causing the issue. I hope to get this fixed this week.

CGUTH commented 7 years ago

Thx Denny!

DSheirer commented 7 years ago

Duplicate streaming audio problem resolved under issue #176 with commit #182