All times are UTC+02:00




Post new topic  Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Wed May 08, 2024 10:05 pm 

Joined: Sun Jan 07, 2024 7:36 pm
Posts: 7
Hi,

We are testing MicroMPX at our FM transmitter site. Currently we have no other way than using a 4G modem. We built a VPN over it to the studio, and most of the time MicroMPX is running fine.
I have set the errorcorrection to 96/48 and a delay of 14 seconds to get a high level of correction. I also configured QoS on both networks (ST source and transmitter site) but we still get dropouts.
Every 1 or 2 hours MIcroMPX complains about 10-20s no packets. Is there some way to get the buffer high enough to get through this? It doesn't matter for us if the delay on the transmitter is 30-60s.

We also see shorter drops, and everytime we lose audio. Isn't it possible to let MicroMPX buffer more?

We use a 320k MP3 stream that's onair now through a DB Deva box, and that does not have the issue of dropping out.


Top
   
PostPosted: Thu May 09, 2024 6:53 pm 

Joined: Mon Dec 30, 2019 12:34 pm
Posts: 12
Let's think differently for a moment. What VPN are you using? When fiber to one of our transmitter sites was cut, we ran Wireguard over 4G and 32 recovery packets for each 32 packets (basically sending everything twice) on 5 seconds of delay, that worked like a charm.


Top
   
PostPosted: Tue May 21, 2024 10:23 pm 

Joined: Sun Jan 07, 2024 7:36 pm
Posts: 7
Great that it worked for you, but I have tried serveral VPN solutions now, and it still isn't stable. Tried VPN through the routers on both sites (IPSEC), and I recently built a Wireguard VPN directly between the Stereotool MicroMPX encoder (Windows 10) and decoder (Raspberry Pi), and we still have silences because of packets missing, or packets coming too late. Also getting errors of incoming packets are too slow / fast.

Isn't there a posibility to make this transport more reliable? It probably works great on stable links, but even with the 96/48 setting, it just isn't.
I will try 32/32, but this doubles the 320k bandwith right?


Top
   
PostPosted: Tue May 21, 2024 10:34 pm 

Joined: Mon Dec 30, 2019 12:34 pm
Posts: 12
Yeah. Sending everything twice was the only way we got it stable.


Top
   
PostPosted: Mon Jun 10, 2024 6:28 pm 
User avatar

Joined: Mon Nov 30, 2015 5:05 pm
Posts: 24
Hi Peter, had the same issue here. Worked flawlessly untill roughly the end of 2022. Something happened after that, because this issue occurred at our side too. After testing it out with two different providers, even in line of sight with the 4G tower, I got issues just like you describe. It can run without buffering for 20 minutes, sometimes 30, sometimes more than an hour, but after that random buffers of up to 20/30 seconds, but most of the times less. Tried several VPN configurations (TCP or UDP), but nothing seemed to resolve the issue. The providers cannot see the type of data, so they must be limiting on the raw amount of data your using. On the other hand I would expect some more continuity in the behavior, speedtests also show no limit in the amount of speed thats available.


Top
   
PostPosted: Mon Jun 10, 2024 6:47 pm 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11241
Strange. We do send UDP packets, so providers *can* drop those. But if anything the newer versions should be more stable, not less.

A few things:
  • 96/48 will handle dropouts up to about 300 ms. It doesn't help to increase the buffer size more, that won't be fixed. For maximum correction you can use 128/127 to fix dropouts up to 700 ms or so, but given the description that won't help either.
  • What you report seems to indicate that the whole connection disappears for 20-30 seconds. We send keyframes regularly. The newer builds use 0.5 seconds by default, which means that on average a dropout would be half of that, so 0.25 seconds. If your setting is higher you can reduce it, but it will only make the dropouts a bit shorter, not fix them.
  • You're using a VPN; VPN's will wrap our UDP packets. They might send them as UDP or as TCP, and, importantly, they might not include the QoS settings in that.
  • Based on your names and email addresses I'm guessing that you're both in the Netherlands. Not sure if this matters but maybe it does, there might be similarities in the network infrastucture. You're also both using 4G, are you using the same VPN? Maybe that VPN had an update that changed something.

Do you know if the DEVA uses TCP or UDP? Was that going through the VPN as well?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 6 posts ] 

All times are UTC+02:00


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited