Results 1 to 14 of 14

Thread: Audio Dropouts -- am I doing something wrong?

  1. #1
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21

    Audio Dropouts -- am I doing something wrong?

    Hi,

    Last weekend I handled the broadcast booth at a local music festival for a community radio station. The guys backstage gave me an audio feed of the board mix via NDI, which we received at our booth using NDI Studio Monitor. We mix in announcer voices, and send the audio to the radio station over the Internet using Icecast to be broadcast over the airwaves.

    Sitting at the booth, I noted very brief but very frequent audio dropouts coming from the stage. Not bad enough to call it a bad job, but I noticed.

    Back home here, I duplicated the problem on my home LAN. I have three computers here, all set up with Test Pattern and Studio Monitor. If I turn on Test Pattern on machine #1 and use Studio Monitor on that same machine (via localhost) I hear the same dropouts with the 1kHz test tone. Recording the received audio with a DAW and viewing the captured waveform, I can see that the dropouts are about 40ms in duration. The pattern of dropouts appears to be random, occurring a few times to many times per minute.

    The same thing happens when I use Test Pattern on any of the other machines, and with Studio Monitor on any or all of the other machines. It does not seem to be dependent on which machine is generating the test tone, or which machine is receiving it. Same thing every way.

    The machines here are:

    Dell XPS 13 with Windows 10, 64-bit Core i5-7200 @ 2.50GHZ / 8GB RAM
    Dell Latitude e6420 with Windows 7 Enterprise, 64-bit Core i5 @ 2.5ghz, 4GB RAM
    Lenovo Yoga 2 11 with Win 7 Home Premium, 64-bit, Core i3 - 4 GB RAM

    I note that when cpu saturates on a Studio Monitor machine audio cuts out, but I guess that's to be expected unless there is some way to have Studio Monitor's audio stuff prioritized over all. However, the glitches I am hearing are not associated with cpu saturation, at least not as far as Windows' Resource Monitor shows.

    Any guesses about what I am dealing with here?

  2. #2
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21
    Any guesses where I should start looking. Oh, update: the guy who was giving me the NDI source feed at the event said maybe I should try OBS Studio with the NDI plugin to monitor the stream. It's worse: even at the audio-only setting, the dropouts are frequent and sometimes last for seconds. Somethin' ain't right. I just need a solid way to monitor the audio of an NDI stream, video is incidental.

  3. #3
    What is your network setup? Everything running at gigabit speeds (and verified they are running at gigabit)?
    Kane Peterson
    Key Accounts Sales Engineer
    NewTek, Inc.

  4. #4
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21
    Thanks Kane. Windows Resource Monitor shows that this static test pattern + audio is using less than 4Mbps. Why does such a dinky little stream needs a gigabit connection?

  5. #5
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21
    Okay, I've re-set my networking for this test. All NICs and router are Gigabit, all connections are wired. Test Pattern is running on Lenovo Yoga 2 11 laptop, Win10. Router is TL-WR1043ND. Studio Monitor is running on Dell Latitude core i5 laptop. I have the test tone playing from the Studio Monitor and the dropouts are still there, and no better nor worse then when I was running wirelessly (see above). All machine specs are in the OP.

    Studio Monitor machine's Resource Monitor shows the same 4Mbps that I saw wirelessly -- this is not a demanding stream unless there is some kind of overhead or handshaking or something going on that requires massive brief bandwidth spikes. Task Manager shows LAN at less than 0.5%. CPU is running at 9%.

    I honestly don't think the lan is the issue here.

    I have to take the Test Pattern machine out of the equation because this exact problem occurred at the last music festival when I was getting my feed from the a/v producer who knows a lot more about this stuff than I and had a metric buttload of computers and devices all NDI'd together.

    Is it the Studio Monitor computer? Well, I have the same exact issue with a second machine running SM: a Dell XPS.

    I also have to reject the idea that this is a Newtek thing else there'd be a lot of other folks with the same issue. Oh -- I'm running Tools 3.5

    What should I try next?

  6. #6
    Gigabit is what NDI is designed to run on, anything less is use at your own risk, WiFi in particular is very 'burstly' in how it operates. NDI isn't buffering (to keep the latency low) so if packets don't arrive in time there is nothing to play. NDI|HX devices (like the Spark and PTZ1 camera) do support WiFi if that is required for your workflow.

    If you run NDI Test Patterns and receive it with NDI Studio Monitor on the same computer is everything okay? That would let you know if is a network issue or a computer issue.
    Last edited by kanep; 07-09-2018 at 04:57 PM.
    Kane Peterson
    Key Accounts Sales Engineer
    NewTek, Inc.

  7. #7
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21
    Localhost? Yeah, I should-a thought of that myself. Thank, Kane - I'm not as smart as I wish I was!

    So the idea is to throw the packets out onto the network as they are encoded, then at the receiving side, get them and use them w/o buffering, and since we want latency to be as low as possible, there's no TCP/IP re-sending of lost packets. If the network gets even slightly bogged down doing other things, then a packet may not reach the destination in time to be used. Tthe actual stream bitrate isn't high but the timing requirements are tight. Since the receiving end doesn't have anything to use where the packet is missing, it plays silence. Is that kind of a dummy's version?

    The dropouts are about 40ms -- does that seem about right for a single errant packet?

    Here's the thing: All the dropouts I'm hearing are the same duration. Localhost or gigabit copper or wifi -- the same. If it were a crummy network thing then I'd expect some to be longer, some shorter depending on network load.

    Anyway, yes, on the Dell Latitude e6420 with TP and SM routed through localhost the dropouts are still there, at about the same severity.
    Same on the Lenovo Yoga.
    Same on the Dell XPS.

    This ain't a network issue, and unless I am very unlucky fellow, not a computer issue.

    Have you tried this? Just pop up a Test Pattern and a Studio Monitor and let it run for a while with a speaker on? Not too loud or you'll cut a permanent notch in your hearing at 1kHz, just loud enough to hear. Let it go for a while. Little clicky dropouts, several a minute.

  8. #8
    It depends on the version of NDI as to how error checking is handled.

    With NDI v3.0 and older (or whenever a NDI 3.0 device in being used), TCP is the method of communication. In this case a dropped packet is resent, but you network latency has to be low enough to be able to resend in time. On gigabit, this typically isn't a problem, with anything less than a gigabit network, then it might or might not work, since network performance is on the edge of what is needed for NDI to work.

    With NDI v3.5 devices on both ends, UDP with forward error correction is used. In this case, if a packet is dropped, you are okay as the error correction information will be able to regenerate the missing information. Latency isn't as much of a problem in this case, but you do have to be getting the packet though in time still, if something is holding and buffering the data, then you have to figure out what that is.

    The localhost lookback is a good way to test to determine if the issue is in the computer or in the network. I'm running NDI Test Patterns right now into NDI Studio Monitor as I write this on the same computer, but have not noticed any drops or clicks in the audio.
    Kane Peterson
    Key Accounts Sales Engineer
    NewTek, Inc.

  9. #9
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21
    Thanks, Kane. I don't know what to do now. This doesn't appear to be network-related since it behaves exactly the same on localhost, on gigabit copper, and on wifi. It doesn't appear to be computer-related because it's behaving exactly the same on all three machines. It doesn't appear to be locale-dependent because it occurred at the last music festival I got the NDI Source feed from. Yet I'm the only one with the problem. it baffles science.

    Is there a way to roll back to v3.0 for test purposes?

  10. #10
    Registered User
    Join Date
    Apr 2008
    Location
    Racine
    Posts
    1,237
    I'll just add to make sure the network on all PCs is set to Private or Work, and not Public as that will seriously mess with NDI throughput.

    Thanks
    Jeff Pulera
    Streaming Broadcast Solutions - Newtek Elite

    TriCasters: Mini with AE, TC1
    Camera: Sony PMW-X70 4K
    Controllers: All variety of XKeys
    PTZ: Newtek NDIHX-PTZ1

  11. #11
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21
    Thanks, Jeff. Even with local loopback on localhost? Anyway, I'm set up with Private networking at the moment on all three of the test machines.

  12. #12
    Do these systems have 3rd party anti-virus suites or firewall systems? If they do, try disabling them or uninstall them.
    Kane Peterson
    Key Accounts Sales Engineer
    NewTek, Inc.

  13. #13
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21
    Naw, they got nothing like that. I'm walking wire without a net here. I like to keep system "noise" (background processes) to a minimum when I'm doing real time broadcasting. Last thing a fellow needs is some rude malware scanner waking up in the middle of a show and saturate the cpu and disk drive. As you can see from the computers I'm running, this ain't high-end hardware so I have to work with this level of hardware. KPOV is a community radio station (means, no advertising dollars, no government funding, donations only) so we have an annual budget of about $1 for equipment. Computers come from donated hardware.

  14. #14
    Registered User
    Join Date
    May 2018
    Location
    bend, oregon, usa
    Posts
    21
    Well shoot. I had a friend set up TP & SM on his machine and, like everyone else, he's not hearing any problems. I got three different machines here exhibiting the same exact problem. Regardless of whether using localhost, wifi, or Ethernet gigabit, they all have frequent 40ms dropouts, and when running via localhost, even with all network adapters disabled. Blindfolded, I'd not be able to tell which machine was which just by listening, the symptoms are exactly the same on all three. It's not a network issue, and if it was, one would not expect all the dropouts to be uniformly 40ms, but vary according to network load.

    Is there a path to revert back to NDI Tools v3.0? I'd like to see if the problem persists that-a-ways.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •