All times are UTC+02:00




Post new topic  Reply to topic  [ 7 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: 25
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: 11262
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
   
PostPosted: Mon Jul 22, 2024 3:52 pm 

Joined: Sun Mar 14, 2021 10:43 am
Posts: 42
We are running our infill site on 4G at the moment while the normal ADSL connection has an intermittent fault - I know from experience it takes Openreach months to solve these sorts of problems. Like you we run it over a VPN (Tailscale - free)

It runs really solid - maybe the odd dropout of few seconds every few days - but they tend to be in the early hours of the morning when no one is listening anyway.

Big question in my mind is how good is your 4G signal? We are using a Microtik outdoor 4G router to try and maximise signal. The way 4G (and 5G) works, the better you can make the radio conditions of the cellular link the more reliable signal you will get (ie not only peak throughput, but enhanced reliability). This is because the scheduler in the base station recognises how good your link is and thus schedules you more often because you are less "taxing" than users in poorer radio environments - you essentially get an "unfair advantage" over everyone else, even if the cell site is congested! Ideally you want to get 5 bar +++ coverage so that you can use the highest possible modulation scheme on the cellular link (that said we only have 3-4 bars!). It also helps if your 4G modem equipment is a "high category" which means it has the higher modulation schemes and tricks to improve throughputs. Cat 3 is the lowest you can get, Cat 6 is ancient, something like Cat 12 or above is where to aim. If you get a 5G device it is likely to have higher 4G category by default. I'm waiting for our ZTE MC7010 to arrive which looks like it should be about the best you can possibly buy! https://www.amazon.co.uk/Outdoor-Router ... S22GF?th=1


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 7 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