Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Configuring Opus for remote broadcasts? (Read 3965 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Configuring Opus for remote broadcasts?

(I'm seeking comments and advice, perhaps about what I may have overlooked or don't know about the opus codec.)

I've been working with a Windows program that recently switched from using the Apt-X codec to the Opus codec. My use for this program is transmitting (via the Internet) audio and voice from a laptop at a remote location to a PC at an AM radio station.

My goal is to eliminate or at least minimize "content loss", which are "drop outs" (audible losses of audio, resulting in brief moments of silence) or "edits" (sounds like someone "bumped the turntable",  e.g., a syllable or word is lost while the announcer is speaking).

Somehow we had acceptable results with the Apt-X codec for a year or two on a pair of low-power XP laptops, but now less so with the Opus codec. One variable that's been introduced is I was given two new Windows 8 laptops to deploy, which are better than the laptops used with Apt-X, but neither old nor the new PCs initially yielded loss-free results with this new version.

My first step in eliminating possible causal factors was to tune the computers to where they pass test programs popular with DAW users and audiophiles. DPCLAT is one such program (not compatible with W8, though)

I then ran some long tests using the new W8 PCs on my LAN to see if any content loss occurs. Opus on both PCs was set to a Sample Rate of 24KHz, Bit rate of 32kbs, and SWB, using UDP and then TCP.  These systems passed all tests so now I'm ready to subject them to the outside world.

I run TamoSoft's Throughput Test to verify that the connection between the remote location and the station can pass a TCP and UDP VOIP test.  If that test passes I figure I've done all I can do except change Opus settings.

While AM radio imposes its own fidelity limitations it's the opinion of station personnel that there is an audible difference when I switch from 24kHz and 16Khz sample rate and from 32kbs to 16kbs. Given my understanding of the "Quality" setting, SWB is appropriate for 24kHz and WB is for 16kHz. Based on previous experiences I'm not sure that those changes have much impact on whether content loss occurs anyway.

Mono audio is all that's needed for this application.

If you think that a lower sample rate or bit rate might help reduce content loss, please tell me.

In terms of other configuration options available to me, I'm left with:

* increasing the buffer size in the PC at the station (my experience with increasing the buffer seems to reduce drop outs but not "edits", although I can't swear to that.)
* reducing Packet Group size (default is 4, meaning "4 chunks of audio are assembled into a single UDP datagram"; a setting of 2, for example, "increases bandwidth usage but packet loss and jitter will be less noticeable").
* switching from using UDP to TCP (my brief tests of TCP yielded no improvement when content loss is evident, which is a surprise. A conversation with a tech at the mfr of JamLink -- a hardware device that offers similar capabilities -- indicates that TCP is preferable to UDP for minimizing loss)

Any suggestions?

Configuring Opus for remote broadcasts?

Reply #1 –
Quote from: twdal on
* switching from using UDP to TCP (my brief tests of TCP yielded no improvement when content loss is evident, which is a surprise. A conversation with a tech at the mfr of JamLink -- a hardware device that offers similar capabilities -- indicates that TCP is preferable to UDP for minimizing loss)

Any suggestions?



I don't have any experience with this directly, but I'd imagine you want to be using TCP rather than UDP in this usecase. None of this has anything to do with the codec, but rather that TCP guarantees that each packet reaches the destination, though it may take a while to do so,  whereas  UDP will silently drop lost packets and carry on regardless . This is why VoIP systems generally use UDP -  on a congested network audio over UDP will have odd drop outs which are suboptimal but acceptable for realtime conversation - preferable to a long pause whilst TCP tries to resend and reassemble a broken stream. Audio over TCP with a reasonable buffer should eliminate this, so see if you can increase that. I would also look to reduce network congestion by whatever means possible - across all levels of the OSI model, wired connections, good switches, using a private subnet or VLAN if possible, reducing or eliminating noisy protocols (big file transfers, downloads or streaming etc on the same subnet), no unnecesssary programs running on the PCs at either end etc.

I would expect Opus to be able to sound better than Apt-X, but if it requires resources that you don't have, consider going back to the acceptable results from Apt-X until you can improve the network.

Configuring Opus for remote broadcasts?

Reply #2 –
Even though you passed the throughput test that you chose. It seems, by your description, that you still have a network problem. It might not be a continuous problem, but a problem that spikes at different times of the day.

A sudden rise in latency (lag spike), too much jitter, and packets that arrive out of order (or lost entirely) can all cause problems. TCP is more resilient than UDP, but if it takes more time than your buffer to "recover" the lost packets, you will still get an interruption of the stream.

My guess is that a combination of TCP and higher buffer, should overcome the issue.

Test the network as best as you can. I like to use the tools on speedtest.net AND pingtest.net

I see that you already tested the setup on the LAN. So that should indicate that in fact it is the remote network causing the problem.

Out of curiosity, is there any use of wireless involved?

Configuring Opus for remote broadcasts?

Reply #3 –
Thank you to Makaki and Lozenge. Both of your replies are appreciated and helpful.

To help make this post more useful to future readers I'm adding the following, which is a direct reply from one of the authors of the Opus RFC6716.

Quote
As you indicate, the problems you report (drops and edits) may be caused by the decoder not having a packet available when it needs it.  That packet was either lost, hasn't arrived yet, or there is a bug in the jitter buffer that stores packets and feeds them to the decoder. 

There is also a possibility that the audio player isn't able to provide audio data in time when the OS needs it.  In this case your decoder/playout application may need a larger audio buffer towards to OS.  And check that your CPU load on both sender and receiver side is no more than ~50%, for the core that runs the process.  These problems could cause what you call drops, but not edits.

For the best possible streaming, I'd recommend to:
- Use TCP, and make sure retransmission is enabled.  Sometimes VoIP applications use TCP without retransmission just to deal with certain firewalls, but this doesn't help in the your case.
- To benefit from TCP's retransmission you'll need a large buffer size in the receiver.  The reason is that it takes time to figure out a packet was lost, request a new one, send it over, etc. Use a buffer size of at least 10x a typical roundtrip time.  (Or just use a buffer of 10 seconds or so, if your application is ok with this kind of delay.)
- Make sure that your jitter buffer can handle packet reordering (some don't).  Packets get naturally delivered out of order once in a while, and any TCP retransmission would also reorder packets.
- With TCP and a long enough buffer you should be able to avoid all lost packets.  So you might as well combine as many audio frames as possible in a packet (high packet groups size).


To answer Makaki's question: no PC-to-network wi-fi is involved the equation, but the station is connected to the Internet via a WISP, supposedly giving the station an 18Mb Down/2Mb Up connection.  And to clarify, after having problems with all PCs, new and old, after switching to the new Opus-based program, I decided to start over. First, I ensured that the PCs are not a factor. Now it's time test some likely WAN connections. I am going to the WISP's office and will run my initial tests from there, to minimize variables. I will remove every LAN connection to the station's router except for the "receiving PC", to eliminate all competing local traffic. It's about as unrealistic a test scenario as can be but I'd like to start with the best scenario first. Maybe there will be no content loss, but the purpose of this post was to settle on what "knobs I can turn" if content loss does occur. And it sounds like reducing the Packet Groups or switching to TCP are the only adjustments available to me.