Is cat 5 the cause of my audio drops on cams.

[looney2ns]

I've had issue's with brief audio drops on security cams in BI almost since the beginning.
I've been trying to pin down what the issue may be of late.
When using UI3, I see numerous network delays in the stats for nerds app, at the same time see the frame rate drop from 15, where I have it set all the way down to zero at times for second or two.

I found that the Ethernet cable that runs from the camera poe switch, to the BI server is only cat 5, that I installed several years ago prior to IP cams. This is approximately 50ft. Plus two patch cables that are only cat 5.
The port on the switch and the computers nic shows they are running at 1gig.

I ran iperf3 multiple times, with my laptop plugged into poe switch as the client, and measured to the BI server. This is the results.
I ran this test with all the cams still connected to BI and recording.
So, my question is, even with these results is it worth replacing that length of cat5 with 5e or cat 6 that might help my issue?

 

[sebastiantombs]

What does BI show for a bit rate for the cameras? Unless it's close to that, 800+ MB, I don't think it would make much of a difference. On the otherhand if you're a "purist" about it 5E or 6 would be a better choice.

 

[Mike A.]

Yeah, the CAT5 spec is fine and tests look OK. You lose a little to overhead. That's probably not your problem. I see the same type of effect with UI3 even over CAT6 cable. Not sure what that reflects. I don't use audio much at all so likely wouldn't notice if there were drop-outs.

 

[CCTVCam]

Myabe some encoding issue. Perhaps Andy knows?

 

[tigerwillow1]

In this situation I'd make up a ~50 foot cat 6 cable and run it temporarily from the server to the switch and see if anything changes. My wife puts up with things like this if it isn't for more than a couple of days.

 

[samplenhold]

I know you know more about these things than I do, but in another thread I am pretty sure that @bp2008 stated that the Orange Clock of Death displayed in the UI3 interface was due to the computer that you are displaying on, running UI3, did not have enough resources or compute power to handle UI3. However, I might have misunderstood him on that.

 

[looney2ns]

What does BI show for a bit rate for the cameras? Unless it's close to that, 800+ MB, I don't think it would make much of a difference. On the otherhand if you're a "purist" about it 5E or 6 would be a better choice.

Not near 800MB,


See ping test results attached.

I'm going to try a factory made 100ft cat 6 patch cable temporarily.

 

[looney2ns]

I know you know more about these things than I do, but in another thread I am pretty sure that @bp2008 stated that the Orange Clock of Death displayed in the UI3 interface was due to the computer that you are displaying on, running UI3, did not have enough resources or compute power to handle UI3. However, I might have misunderstood him on that.

Thing is, I never get the orange clock.
I have the audio drops at the BI console as well, just not as bad as when in UI3.

 

[bp2008]

It isn't hard for small network interruptions to cause a cutout in UI3, which basically does nothing to buffer ahead the audio.

In the Stats for nerds panel, look at the audio buffer graph specifically. The graph updates at each video player progress update, which is relatively slow with the HTML5 player. You should switch to the JavaScript player temporarily to make the Stats for nerds panel update at each video frame.



This is pretty much an ideal situation right here, with the audio buffer being refilled very consistently and never getting too close to empty. But it is a very small amount of buffered audio, so even a very brief interruption in the stream can cause audio playback to stop and start again.

An interruption could be caused by any number of things. A faulty or congested network being one of them. Blue Iris might also slow down a little bit, for example when UPS just showed up to drop off a package, a bunch of cameras triggered and caused my audio buffer to empty out. The cam I was watching for its audio stream didn't even get triggered. But the streaming performance temporarily worsened enough to cause the audio buffer to run empty a couple of times, and there was noticeable video stuttering at the same time.

If you want to do more extensive network monitoring, get bp2008/pingtracer and put in all the addresses you want to monitor, separated by commas. Turn off Trace Route and Reverse DNS Lookup, and set the ping rate to 10 pings per second. This beats the heck out of Windows' built-in ping app and will show you synchronized graphs that make it easy to spot a network problem.

 

[bp2008]

Audio dropouts in Blue Iris's console could also be caused by network-related delays or by software issues with the audio processing threads. UI3 is another layer on top of that which would introduce new opportunities for an audio dropout while also being affected by audio dropouts that happened earlier in the chain.

Notably, recordings should play fine without dropouts in most cases even if the live stream had problems, as long as no data was actually lost (only delayed). Especially if you use a different video player like VLC or MPV, that generally is more laser-focused on doing smooth playback than Blue Iris ever was.

 

[Tinman]

While on this audio subject, what is the preferred Encode Mode to select in the camera's gui ? AAC or G.711A or what ?

 

[bp2008]

AAC should be substantially higher quality and better compression. That is what I choose.

G.711A is basically 50 year old telephone compression that is extremely simplistic.

 

[sebastiantombs]

You're going to be hard pressed to beat a 1ms ping time there, Looney. I don't think it's a network problem and lean more toward what Brian has mentioned.

 

[CCTVCam]

It's a pity they don't include either a larger buffer (ideal solution) in the order of something that can store 2-3 secs of audio, or a more lossy but efficient codec such as MP3. Whilst there's no doubt AAC is superior, I doubt most people would notice the difference between it and MP3 on cctv audio to the extent it would bother them, and conceivably the amount of audio that would fit into the buffer would be much larger as Mp3 for speach would be around 50kbs instead of 380kbs for AAC, or aorund 8 times as small = 8 times as much that could be buffered in the same size memory buffer which takes you to the 2.4 second mark looking at the 320ms above.

 

[bp2008]

@CCTVCam The reason buffers are so small is because buffering is literally adding a delay. Streaming delays are something we try to avoid as much as possible.