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: TCP output component (Read 1244 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TCP output component

Hi.

I'm writing an output component that sends the audio data through a TCP socket to a server of mine that outputs it on the local audio hardware. The code works perfectly when the server is on localhost or another machine that's reachable via copper. However, as soon as WiFi is involved I immediately get underflow, although only with some tracks. Looking at a trace, I can see that Foobar2000 is often calling get_latency() and update() as many as two times each for every ~3 ms of audio it sends through (which is quite bad with a 1-4 ms ping), even though get_latency() is begging for data and update() reports that it really can handle more.
What's even more frustrating is that a) for some tracks it magically works fine, and b) if I just don't bother with either get_latency() or update() and make them return 0 and true respectively always, and let the TCP stacks handle the waiting, everything works fine other than the GUI and the audio going completely out of sync.

So I guess my question would be, what is Foobar2000 doing, and is there any way to make it stop?

Thanks.