• Registered: 2025-07-16
  • Posts: 21

Topic: Media Clock Dropouts with 1620

Hey new to RME units.
This might be a switch problem, but when we use a 1620 (internal clock) to feed some L-acoustics devices (LA12X, LA7, P1) 1we get Media Clock drop outs every few minutes.

If we use a talker of a different brand (say our L-acoustics P1) we do not get these errors.6,

I saw a previous post from a year ago about problems using the Media Clock Stream, could this still be a problem?

Before I go to crazy with checking on my Netgear switch settings has anyone seen or tested anything similar?

  • From: Haimhausen
  • Registered: 2012-04-02
  • Posts: 379

Re: Media Clock Dropouts with 1620

Have you updated to the latest firmware?

Regards,
Audio AG Support

Audio AG Support's Website

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

Yes latest firmware.
I believe the webgui prompts me if there is a newer firmware, and it has not done so lately.

  • From: Haimhausen
  • Registered: 2012-04-02
  • Posts: 379

Re: Media Clock Dropouts with 1620

Can you please send an email to support@audioag.com with a screenshot of Hive with the errors, and a copy of the syslog after the errors have happened.The syslog can be copied from <ip-adres 1620>/syslog

Regards,
Audio AG Support

Audio AG Support's Website

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

Email with Logs sent

  • Marc S
  • RME Developer
  • Offline
  • Registered: 2019-06-11
  • Posts: 151

Re: Media Clock Dropouts with 1620

Hi,

I did a couple of tests today in my lab with a P1, Netgear M4250 and a 12Mic (AVB stack identical to M-1620). I was able to clock the P1 from the 12Mic just fine, had it running over an hour without any issues.

Generally, L'Acoustics and RME are cooperating quite closely regarding AVB, which means the devices are tested and used together a lot. I'm confident we will be able to figure this one out.

Two questions regarding your setup: Are you using redundancy or single-port? Who is the gPTP grandmaster? (for example shown in Hive or Milan Manager)

And can you do a couple of brief tests:
1. Switch off two L'Acoustic devices, does the problem persist?
2. Clock the M-1620 from the P1, does this work?
3. If possible, replace the Netgear with another switch, e.g. Luminex or a LS-10.
3b. If you don't have another AVB switch at hand, can you try to set everything up and disconnect the switch, directly connecting M-1620 and P1? You can connect a PC to the secondary port of either device (or both with a normal switch), to check the counters in Hive.

This will help immensely to narrow down possible sources of this issue!

Thanks
Marc

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

And can you do a couple of brief tests:
1. Switch off two L'Acoustic devices, does the problem persist?
not sure what you mean here? we have a problem if we just go with 1 1620 to 1 P1, there is nothing else to switch off

2. Clock the M-1620 from the P1, does this work?
yes

3. If possible, replace the Netgear with another switch, e.g. Luminex or a LS-10.
yes, we tried with an LS10, still a problem. we now have the 1620 connected diretly to an LS10, with some L-acoustics LA7.16 as listeners and the problem persists. The netgear is still in the loop, but only for control and it is still the gTPT master.

3b. If you don't have another AVB switch at hand, can you try to set everything up and disconnect the switch, directly connecting M-1620 and P1? You can connect a PC to the secondary port of either device (or both with a normal switch), to check the counters in Hive.

To further add: the gPTP master is the 1 netgear switch.
We are testing with redundancy. i do not see an option to NOT have the 1620 in redundant mode.

And I suggest you run the test for at least 24 hours.
Our initial tests also found things stable for an hour, but if left on over the weekend, things stopped working.

So far we have found: P1 to P1 or LA7.16 good
1620 to P1 or LA7.16 not stable over time
P1 to 1620 good, but we did not test over time.
1620 to 1620 good for 24 hours.

  • Marc S
  • RME Developer
  • Offline
  • Registered: 2019-06-11
  • Posts: 151

Re: Media Clock Dropouts with 1620

Hi Jon,

thanks for doing the tests and your reply! There has been some overlap with emails through our support team, which explains some of the confusion, but the picture gets clearer now which is good.

jonrat wrote:

3. If possible, replace the Netgear with another switch, e.g. Luminex or a LS-10.
yes, we tried with an LS10, still a problem. we now have the 1620 connected diretly to an LS10, with some L-acoustics LA7.16 as listeners and the problem persists. The netgear is still in the loop, but only for control and it is still the gTPT master.

You tried the LS10 without the Netgear first, correct? So it also happens with only the LS10, which then is grandmaster?

jonrat wrote:

We are testing with redundancy. i do not see an option to NOT have the 1620 in redundant mode.

This is a test to narrow down the scope of possible causes. Just unplug the secondary port of the 1620 and leave everything else as is. If this solves the problem we know where to look next!

Thanks
Marc

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

OK, I will be back in front of it all tomorrow.

I will set it up LS10 only, no secondary, LS10 as gPTP master.

1620 feeding a P1.

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

OK, well 1 1620 feeding a P1 with an LS10 switch ran fine with no errors for about 24 hours.

So now I will add the secondary to that equation and see if it can run for a day or so without errors.

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

1620 feeding P1 with redundancy and LS10 switches has been stable for several hours now.

I guess the next step will be to return to the Netgear M4250 Primary only and see what it all does.

Previously we had several amps on the network too, this time we will keep it simple just the 1620, P1, and the 1 switch.

The netgear will be the gPTP GM.

  • Marc S
  • RME Developer
  • Offline
  • Registered: 2019-06-11
  • Posts: 151

Re: Media Clock Dropouts with 1620

Hi Jon,

thanks for going through all those scenarios! Yesterday I've tested the following setup for a day:
M-1620 -> P1, primary via Netgear M4250, secondary via LS-10.
Both switches have been grandmaster on the respective network.

I had it running for roughly 14 hours (wasn't able to keep it set up longer), but there haven't been any issues at all.

Waiting for your feedback using Netgear switches on both networks, and/or LS-10 between the devices but the M4250 being grandmasters. I will continue testing in my lab as well.
Once we have a reproducible scenario, we should be able to find the root source pretty quickly.

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

Thanks for testing.
Yesterday I ran 1620 to P1 Primary only with a smaller M4250 for 24 hours no problem.

Our original problem, the one on which we had Netgear remote it to check out, was on a larger switch, so now I will test with the 1620 to P1 with a 24+port switch.

The larger switches do have different firmware, so perhaps it is just the larger ones with an issue.

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

OK, 24 hours of testing with the larger M4250 in redundant setup passed.

I will now try to put the 1620 in-situ in our setups, which also involve Dante running on the switch, and on which we run our Mac's with multiple interfaces and VLans into the switch. This is how we first encountered the problems.

Perhaps there is a problem not with the audio, but the AVB error reporting to the mac, etc? who know??

  • Marc S
  • RME Developer
  • Offline
  • Registered: 2019-06-11
  • Posts: 151

Re: Media Clock Dropouts with 1620

Hi Jon,

thanks for following up! Yeah, that's the thing with converged networks. They have the potential for enormous savings (cost, space, weight, setup time in touring environments), but each technology has their caveats and sometimes they combine in weird ways...

The good news is: our devices are pretty robust towards lost CRF packets (if it's only one or two in a row), and from talking to L-Acoustics engineers I'm pretty confident this is the case with their devices too. So why it's bothersome to see error counters go up, in most cases it's not audible.

That being said, it would really be good to get to the bottom of the issues you have been seeing. Do you remember which of the error counters went up? I think Milan Manager doesn't show all of them, maybe you can throw a Hive instance into your network, which is a bit better suited for this kind of troubleshooting.

Thanks
Marc

  • Registered: 2025-07-16
  • Posts: 21

Re: Media Clock Dropouts with 1620

I spoke too soon.
1620 to P1 with Netgear M4250-26 was fine for 24 hours. That was Friday. So I left it for the weekend.
On Friday we had a AVB error. On saturday we have a few more.
Now on Monday we have had several thousand errors. With a much greater frequency.

I have attached screenshots in the URL below.

I guess I need to go back to testing with an LS10 and run it for a longer test. To see if the length of time with the Netgear vs LS10 is the issue. Or if the length of time is a 1620 issue.

I know you say that the format is resilient. But we provide audio for high dollar live events. I simply cannot risk deploying anything that risks the confidence of our customers.


https://drive.google.com/file/d/1s-0k1y … sp=sharing

https://drive.google.com/file/d/1z3QbaS … sp=sharing