Community
Can't get reliable sound capture
Links used in this discussion
- https://www.remoteutilities.com/solutions/self-hosted-server.php
- https://www.remoteutilities.com/download/beta.php
- https://www.remoteutilities.com/product/release-notes.php
- https://www.remoteutilities.com/support/kb/what-is-a-direct-connection/
- https://www.remoteutilities.com/support/kb/what-is-an-internet-id-connection/
I'm trialling RU 6.8.0.1 for a small non-profit organisation who used to use [censored] with sound capture to listen to 1-2 minute snippets of audio through an app.
Connections are over the internet ADSL speeds using Windows 7 hosts.
I'm really impressed with the great range of features RU provides, and whilst I am disappointed screen responsiveness isn't quite as good as [censored] in my initial tests, what I am struggling with is the sound capture.
On an internal LAN it works pretty well with only about 2 second delay which is fine for our needs, but over the internet (where it's primary use will be), it is either horribly delayed by a minute or more or not even working at all, even for system sounds.
The hosts uses a Behringer USB sound device and I wonder if it is part of the problem? Are there any "under the hood" tweaks I can change to give RU sound packets a higher priority and see if that helps? Changing the settings to try and increase throughput doesn't seem to help in the case of audio.
We are looking at getting a better router and QoS but it's some time away, and I'm not that keen just yet to spend time configuring RDP because it messes with screen resolution which makes the audio app unhappy.
I hope you have some advice!
As Cristian has mentioned, using the self-hosted server (specifically, the relay server role) can significantly improve connection speed and performance.
However, I also recommend that you try out version 6.9 beta. In this new version we implemented some changes to screen capture as well as authorization mechanism for slower connections. This is from our release notes:
Thanks!The remote screen transfer speed of dynamically changing content (e.g. videos) over slow connections has been increased.
Firstly, I tried the Beta as suggested and whilst the screen updates were noticeably better, audio was the same.
I also tried port forwarding and callback for testing direct connection (which I believe is the same as setting up RU Server), and sound was slightly improved but nowhere near usable. Even Windows system sounds were non-existent.
Of a minute's worth of MP3 audio, sometimes I would get a few seconds worth, delayed about 15 seconds after the audio should have started. Sometimes I got seemingly nothing, so stopped playback and left the computer idle and patchy sound would come through a couple of minutes later. Sometimes, while playback was stopped, previous audio would randomly "repeat" like a buffered block was being retransmitted.
I suspect RU just doesn't do sound very well over slow connections. Whilst we are on ADSL, it is a very congested network and I'm only getting 0.4Mbps upload despite having a 1Mbps sync speed. I also have a 1920x1080 resolution which is unchangeable so there's little more I can do to reduce the data.
I like RU so far, but competitor products handle audio very well in comparison. They use UDP whereas RU appears to only use TCP according to knowledgebase, and I think is why audio is better on the same host. I suspect audio packets are getting lost over the bad connection and are having to be retransmitted, but RU is prioritizing sending screen packets first? This is why I wondered if there were any tweaks I could apply, as I would prefer that audio get priority particularly when very little is happening on screen. Low quality audio should consume relatively little bandwidth and is why I am surprised it's behaving this way.
I'm confident with a better connection I'll have no issue in recommending RU for our site, but a better connection is some time away and audio has some weight in our product choice until then :(
I very much appreciate any other thoughts you might have.
Thanks for the details.
Technically, direct connection is not exactly the same as setting up RU Server. Basically, there are two connection types:I also tried port forwarding and callback for testing direct connection (which I believe is the same as setting up RU Server), and sound was slightly improved but nowhere near usable. Even Windows system sounds were non-existent.
Direct connection
Internet-ID connection
An Internet-ID connection, in turn, can be set up using either our public servers (default option) or your self-hosted server. If your self-hosted server is located on your premises - e.g. in the same network as the Viewer - then the performance of an Internet-ID connection becomes almost as good as that of a direct connection. This is because it takes the network packets very little time to travel between your Viewer and self-hosted server so the only significant part of the route is that between self-hosted server and Hosts.
I can recommend that you enable the "economy mode" and see if it makes a difference. It's in connection properties, the Network tab/section.I suspect RU just doesn't do sound very well over slow connections. Whilst we are on ADSL, it is a very congested network and I'm only getting 0.4Mbps upload despite having a 1Mbps sync speed. I also have a 1920x1080 resolution which is unchangeable so there's little more I can do to reduce the data.
I've tried all kinds of combinations for colour, FPS, and economy etc but there's very little if any difference.
Sorry, I probably should have explained that I understand how a RU Server would benefit, but I was just testing for raw performance and a direct connection through a port forward would be the same as a local RU server with Internet-ID (please correct me if I am wrong).
I did some performance monitoring on 6.8.0.1 on the host in question and noted the following in Windows Resource Monitor during audio capture:
- During normal activity, network interface traffic was averaging about 50Kbps
Begin playing a local MP3 file, the interface traffic jumps 10x to between 400Kbps and 800Kbps (to me seems a lot)
During this time, no audio comes through
Stop the MP3, about 15 seconds later, no audio still, traffic still high and remains high
Eventually some audio will come through in bursts, and complete in around 1 or 2 minutes.
When the last of the 15 seconds of audio is finished playing, the interface traffic drops back down to "normal"
Since my uplink is only around 400Kbps, I'm assuming either the line is getting saturated, or the RU service is topping out at the maximum available speed, which is not enough to sustain the throughput. I don't know what audio quality is trying to be sent, but maybe there needs to be an option to transmit low quality (eg 22Khz) or UDP be used.
To verify, I run the same test with "capture sound" off, and interface traffic does not jump. Turn it on while audio is playing and traffic jumps, and the symptoms above are the same, but I can't turn off the capture until the transmission of the audio is completed
Anyway, I grabbed a screen recording to help demonstrate and I would be very happy to supply any additional logs to you to help improve the next beta!
With direct connection performance is better by definition. However, if RU Server is located very close to either side of connection (Viewer or Host) the difference should be unnoticeable.Sorry, I probably should have explained that I understand how a RU Server would benefit, but I was just testing for raw performance and a direct connection through a port forward would be the same as a local RU server with Internet-ID (please correct me if I am wrong).
As for improving the sound capture performance, we'll see what we can do and we can implement any improvements in this beta.
Thanks!
* Website time zone: America/New_York (UTC -5)