Knowledge Base

How can I have sound on my VintageVPS?

We know, we know. Having sound for games, music and other uses of the time was important, wasn't it?

That's why C-Servers offers something never seen before: sound on our VPSes. Specifically, on our Windows 9x operating system (Windows Me), and on some of our Linux offers (Mandrake Linux and Fedora).

For Linux distros

For Linux, simply connect via RDP to rdesktop (using a competent .rpm package from that time, or obtaining a compressed one) or any other protocol, e.g. NX, that supports sound. Mandrake Linux is from April 2002, Fedora Core 1 is from November 2003, and at those times, rdesktop did already exist; even xrdp may potentially work, despite being launched in 2004, if the dependencies are correctly handled.

SuSE Linux 8.2 (April 2003) and Conectiva Linux 7.0 (2000) do not support sound by default; however, you may be able to configure AC97 on them.

For Windows systems

For Windows Me, drivers are included for sound by default; and our images have preconfigured a open-source, discontinued tool, which was used a lot back in the "old days": Edcast. Combined with the open-source power of Ogg Vorbis, including some special configuration to optimize speed and latency for all Internet connections, this tool does one simple thing: you have a tab on your browser for the video (via noVNC), and the audio of your VPS plays on the background in another tab and in real-time, as if you were standing in the front of a normal computer. 

This way, you'll be able to have and process older media content from that time, hear sound from music, games, and pretty much everything else, all with the stability of today's Internet.

If you don't want to spend extra RAM on a browser tab, you also have the possibility of inserting this on any player that supports playing an Ogg audio file from any website address, of which VLC will be the highest example.

How does this work on Windows?

• By default, Edcast launches minimized on the Windows Me system. A simple click on "edcast" at the Taskbar brings the software up - quite a simple software, already preconfigured for the best results and to stream the audio that comes from the VPS as "Stereo Mix".
• This works in a very similar way to radio broadcasting, which started precisely on Windows 9x systems in 1998/1999 with Shoutcast and Icecast servers. The main difference is that, over the years, the protocols have become more resilient; our implementation is from 2008, based on Icecast2 for minimal latency and on Ogg Vorbis to support open-source protocols of a great format, broadcasting at 96 Kbps by default, which is quite transparent for the audio quality of the time.
• You have two ways of operating your C-Servers Internal Audio Service: with or without a domain.
  
  
  • Without a domain, you need to: open a port at the Domain Forwarding option according to a non-selected port by another customer; define the port on Edcast (configured by default at a given port merely as a placeholder), click OK, and start the encoding process. After that, the audio will be automatically forwarded to the correspondent port, and you will need to access its port on any compatible browser or player. By default, Edcast was configured at port 5xxxx, which should be useful to configure this aspect.
    
    Suppose you define port 52800 to broadcast your audio (both at Domain Forwarding and Edcast), you'll go to your website bar and access your audio directly, writing e.g. http://204.182.102.1:52800/audio.ogg, where "204.182.102.1" is your external server's public IP, "52800" is the port opened on Domain Forwarding and Edcast, and "/audio.ogg" is the file location. For security reasons, port forwarding is closed by default; if you don't intend to use audio on your VPS, you should close the port you've opened.
    
    
  • With a domain, you need to: simply confirm that the domain is well inserted in your Client Area, our server system, and that the external IP is well inserted in your domain registrar; configure a port at the Domain Forwarding pointing to the specific domain name and pointing to port 80; configure Edcast to broadcast at port 80 instead of the standard 5xxxx; and lastly access your direct stream writing on any browser/player e.g. http://sampledomain.net/audio.ogg.
    
    It has to be HTTP, not HTTPS, because the libraries for Icecast2 do not support HTTPS over this configuration; some systems do not support IPs for configuration, need to have domains, and this way you have a cleaner, more easily usable solution for older systems.
• Do not change the sampling rate or the bitrate unless strictly relevant to what you're doing. 96 Kbps is plenty for an excellent sound quality, equivalent to a standard 128 Kbps MP3, which doesn't stress resources of any of the parties involved (your VintageVPS, the destination PC and the browser/player) and allows for lower recieving latencies; the same for 44.1 kHz sampling rate, a gold standard on the audio market. Changing sampling rates will create additional latency due to Nyquist's law; increasing bitrates will also increase latency due to additional processing resources being needed, and is undesirable.
  
  The sole situation where increasing bitrates and sampling rates will be useful to you is if you have audio gear that absolutely benefits from that increase, handles it quite well on the fly, and you wish to passthrough your VPS audio to those systems (e.g. hi-fidelity systems). Bear in mind though, that usually such an audio gear creates additional "checkpoints" and analog/digital conversions, which will increase latency in unpredictable ways.
  
  For most uses, our predefined configuration is great.
• Do not change the audio format unless strictly relevant to wherever you're outputting the audio. Ogg Vorbis is natively supported in Linux, MacOSX and Windows (since Windows 10 and September 2019), and natively supported at browser-level since 2008. It has also been suported forever on the VLC Media Player. If you desperately need to stream on MP3, bear in mind you will add an aditional 100ms of delay at the bare minimum; and you'll need to include the lame_enc.dll file necessary to stream such files. The same occurs for AAC. 
  
  As we said, it's optimized from the start.

What is the expected latency on Windows?

It will depend on several technical aspects: your physical distance to the server, packet loss existing at any given moment and your internet stability. (CPU load is actually irrelevant for this purpose since the systems have more than capability to emulate audio today).

By default, our server is located in Paris, France, which is central Europe, and substantially optimized for these services (e.g. after disconnection, attempts to resend the stream after 1 second instead of the usual 10).

This allows for global European reach of under 30ms (two-way), which then needs to include:
- potential browser/player buffer (if you experience a relevant delay, ensure your player has no buffer - no need to have one in 2024 with Gigabit connections for a 96k stream...)
- packet loss (if your internet or the VPS's internet experience packet loss, the audio will delay due to the TCP protocol, increasing latency; a simple way of resolving this is to simply... reload the stream/page);
- internet stability (bad Wifi signal on your recieving end, bad Internet providers, QoS or Traffic Shaping negatively affecting the protocol, can interfere with the audio stability and quality especially on the 20:00-00:00 hours);
- your physical distance to the server (customers further from Europe will have added delay, and it can't be corrected due to nature and physics - the faster ping times you have to Europe, the faster you will be able to recieve the audio).

C-Servers assumes no responsibility for any of these external factors.

Ping response times interfere directly with the audio, and can be categorized/tiered in the following way:
- Under 150ms response times: great experience, imperceptible delay or, if perceptible, very very minimal and comfortable delay. All users in Europe, Middle East, North of Africa are within these response times, as long as they are not routed via Cogent Atlas in Europe (as of September 17th, 2024); North America users are also within these response times on the East Coast, as long as routing is reliable and their technology is 4.5G/5G, fiber optic or cable;
- 151 to 350ms response times: nice experience, with detectable delay, but still perfectly usable. The rest of the world is usually under these times, with some punctual exceptions;
- 351 to 450ms response times: reasonable experience, not that great for games, but otherwise reasonably usable. Some African and Australian/Northern Zealand users, especially due to lack of routes at a given ISP provider or on our server datacenter's end meaning that traffic has to travel much longer than usual.
- 451+ms response times: usually synonymous with packet loss and/or very old technologies combined with high distances (e.g. dial-up, EDGE/2.5G, 3G/HSDPA/HSPA+, old end-of-borough DSL lines, in America or Asia). For these, the experience will be nearly unusable for games, and audio should be considered as only providing ambiance.

Usually, 99.9% of customers will have sub-150ms or at least sub-300ms response times, making for a very nice experience with these VPS servers.