Winamp stops playing after more than 24 hours of running

[Rafcio]

This seems like a resource leak problem and it's been there always (3.x.x? first version I tried). Here is the detailed description.

Host: Windows 7 x64 SP1
Guest: Windows XP Pro SP3

Winamp (latest version 5.621, much older version 5.24 tried with the same result) is configured for mp3 streaming (however with streaming turned off the same problem exists) using Icecast2 (v2.3.2) and Edcast (3.1.21). The mp3 files that Winamp plays are shared through VBox shared folder from the host. The audio is muted (it's meant for network streaming) and without a network traffic (streaming turned off for testing) the same problem happens. The problem is that after some time (AT LEAST 24 hours of continuous playing, but usually less than 48 hours) Winamp stops playing. It seems to respond to shut down (window closes), but it reamins in the task list and has to be killed. Restarting Winamp doesn't fix the problem. Winamp starts up, but it won't play anything at all. The VM (guest) has to be rebooted to clear the problem.

It seems to be a problem with a resource leak of some sort or some other limit reached (shared folder reaching transmission limit ;) ). It doesn't seem to be a problem with audio resources (because sound it is muted by Winamp) or a network resource limit (with or without network traffic same problem). Actually on the same host there is another XP guest running P2P client, transmitting copious amount of data daily and there is no problem whatsoever with that one. So networking issue can be safely excluded.

A physical box with almost identical configuration (with more stuff installed on the physical box) has no problem. Winamp streams mp3 music for weeks at at time without being touched at all. This proves that the configuration I have is sound (I've been streaming music for many years already) and the problem (whatever it is) is on the VBox side. Winamp is not to be blamed here.

[Rafcio]

Log file from the VM with a problem

[vasily Levchenko]

Do you see the same effect if you loop the single track stored in vm image?

[Rafcio]

I haven't tried that, but I can just about any test, because I can't put this system in "production". I will report on the test outcome, meanwhile it is not the shared folder issue I think. When Winamp stops playing I can still copy mp3 files from the shared folder into "local" folder using Windows Explorer.

[vasily Levchenko]

Replying to Rafcio:

I haven't tried that, but I can just about any test, because I can't put this system in "production". I will report on the test outcome, meanwhile it is not the shared folder issue I think. When Winamp stops playing I can still copy mp3 files from the shared folder into "local" folder using Windows Explorer.

It would be better to remove any dependencies (e.g. shred folders), to simplify the picture. Just single file looped in winamp.

[Rafcio]

A limited testing with single local looping file shows so far that it makes no difference. However, this testing reminded me about one very important piece of information that I forgot to mention at the beginning.
Winamp does not suddenly stops playing. It gradually progresses from good to unusable. On the server side there is one important phase before it stops playing. Still, it usually needs more than 24 hours to get to this phase, but its behavior may shed some light on what the problem may be.
During that phase before it fails Winamp plays files at about 4x the normal speed, therefore indicating it loses its timings, whatever those timings are. This phase lasts several hours at least.
On the server side this is about all I observed, but on the client side (with streaming enabled) there are more phases, so I will list them, but I'm not sure if this information will be helpful.
Client phase 1. Everything normal.
Client phase 2. Re-buffering occurs at the beginning of each song.
Client phase 3. Occasional breaks in the middle of the songs, but the playback continues.
Client phase 4. Playback is short (1-2 minutes or less) and then it stops. Has to be manually restarted and the cycle continues, cannot be sustained. This phase corresponds to the sped up playback on the server.
Client phase 5. Client is unable to connect to the stream. This corresponds to the phase where Winamp stops playing obviously.

[Rafcio]

The results of the testing with a single local track being looped indicate that Winamp continues to play beyond the usual time it died (usually less than 48 hours), which possibly indicates the problem is with the shared folder. However, I was still able to copy songs from the shared folder into local folder using Explorer after Winamp refused to play them. So, the issue is more obscure than I initially thought.

[vasily Levchenko]

Thanks for reporting, I've tried similar test (locally looped soundtrack in Winamp) but on Mac host and have got result you posted initially no sound on the guest after (~24h), but it looks like differ from observation you've made when the guest play music on Windows host. Have you stopped your last test (locally looped), and could you check that sound won't affected after yet another 24 h?

[Rafcio]

A test with looping a local track (a long one, about 70 minutes) is still going. I did upgrade the host to the version 4.1.4 in the meantime, but I doubt that this has a fix for the problem. I'm testing the local looping with streaming now. A previous test where Winamp was playing shared songs, but was subsequently switched to local track while it was still good (less than 24 hrs after starting playback) showed that the playback died within its usual time. That's why I said that limited testing with local track didn't make any difference. However, when local track is looped after rebooting the VM the playback still continues and it's been more than 3 days already. I'm not sure what you asked me to test this time? Stop the playback for 24 hours and resume after that time to see if it will be playing? Also, should I resume with the local track or shared tracks? I'm not clear about the test to perform, so could you explain your request?

[vasily Levchenko]

Replying to Rafcio: the reason of the local looped test is to identify location of the problem is it in our audio device emulation or in shared folders. As I understand in your case locally looped sample plays fine more then 48hrs, when on shared folder sources it dies in ~24h, right?

[Rafcio]

Correct. If the local song is played exclusively in Winamp it will play possibly indefinitely. It's been about 4 days and the local song is still playing. However, if first shared songs are played and then switched to local song while Winamp is still OK, it will play initially fine, but it will stop playing within 48 hours. Strange. I believe that the audio device emulation should have nothing to do with the problem, because the sound is muted for the entire time.

[Frank Mehnert]

Does anything change if you use the PIIX3 chipset (not the ICH9 one)?

[Rafcio]

Nope, the same result. I did some more testing comparing apples to apples this time. With one (long) track being looped it doesn't matter if the track is local or shared through VirtualBox folder. It will play indefinitely, which would indicate a problem inside the VM and not the shared folder. Previously I never tested looping one track from shared folder, so it was assumed that it is the same as playing many tracks. It turns out not to be the case. So, it takes more than one track to have Winamp fail after about of day of playing. Why is that different than playing one track continuously? I don't know. I also tested multiple tracks shared though Windows shared folder (as opposed to VirtualBox shared folder) and the outcome was the same - Winamp stops playing. So this proves that it doesn't matter what the source is, after a little more than a day of playing multiple tracks Winamp will fail to play until the VM is rebooted. I think the important thing to pay attention to is the fact that before Winamp completely stops playing, it plays for couple of hours at vastly (about 4x) increased speed, which would indicate it has trouble with timing. At that time it still can read the music from the source (whatever it is), but cannot play correctly. For me that symptom would be something to troubleshoot.

[Rafcio]

Any progress on this issue? Any additional tests that I can do? Actually, you have far more experience and tools at your disposal to nail this bug if you recreated the problem in your environment, but I'd still like to help to speed up the resolution of this issue. The latest release of VirtualBox isn't any better, in fact there may be some regression as it seems to me that the clients start to experience issues described previously as phase 2 and 3 sooner after the VM is rebooted than previously. This isn't a hard fact, rather a loose observation, but I'd like to report it anyway.

[Frank Mehnert]

I have no update but in the meantime there were some VirtualBox releases. Could you try if you still can reproduce this problem with the latest release (4.1.22 or 4.2.0)?

[Rafcio]

Unfortunately, there is no progress, actually there is some sort of a regression. I tested under both 4.1.22 and 4.2.0 version. To send the stream from Winamp to Icecast streaming server an intermediate agent software is used. It is called oddcast/edcast and it's function is to encode the stream, in i.e. mp3 format. Different formats and encoding schemes/speeds can be used. I use a constant bit rate mp3 stream. Edcast shows the actual encoding (transfer) rate, which usually is the set rate or just 1 Kbps less than the set rate. I don't know in which version this got broken, because I wasn't testing for the last few months, but in 4.1.22 the encoder cannot keep the timing properly (I guess), so the transfer rate varies wildly (from about half the set rate to about four time the set rate). I don't know why this happens, but I've seen this inability to keep the proper rate on the physical hardware too, but it was long time ago on a very slow (think Pentium III 1 GHz) processor. It did not happen when I first started using VirtualBox, so it is a regression introduced some time ago. It is somewhat better in 4.2.0, but it also happens initially, but later the rate seems to stabilize. It is very characteristic in the sense that the rate does not randomly jump, but follows a sinusoidal pattern. For example, the rate will start at 64 Kbps (the set rate) and will start falling to maybe 40 Kbps then start raising until it reaches about 220 Kbps and start falling again to about 40 Kbps and the cycle starts over. Winamp will still freeze after some time, so there is no improvement there. Of course the "variable" transfer rate makes it impossible for the clients to maintain a connection with the server, so streaming now is hardly possible with 4.2.0 and impossible with 4.1.22, even for short period of time. In short it is now worse than it used to be.

[Rafcio]

I'm not sure if what I observed is related to the original issue, but some symptoms are very similar, therefore I decided to mention this here. On an unrelated client (still XP, but not set to stream music and the host was RHEL 6) and the latest VBox (4.2.6) I was playing music using Winamp. The playback died just a few minutes after it was started. Winamp seemed frozen, just like with the streaming solution after some time, and same as with streaming solution the Winamp window could be closed, but the app was still running and had to be killed from the Task Manager. Upon restart Winamp wouldn't even start playing music exactly the same way as in the streaming solution. On this client I also had VLC Media Player installed, so I decided to see if that player was affected too. It was. It would "start" playing, that means that the song's elapsed time kept increasing, but there was no sound. I opened Sound and Audio Devices applet from the Control Panel and tried to play a simple sound, like Asterisk. It wouldn't play. The play button changed to stop button and eventually it would "time out" and return to play, but that took a long time. This wasn't a first time when an audio playback would die in a client, actually it is a fairly frequent event, but I wasn't paying too much attention to it before as the other instances of sound playback issues were with "streaming" sound from Internet in Firefox and I believe the embedded player involved was Flash based. I blamed it on Firefox and Flash issues, but now I believe that the issue is the whole media playback in Windows is messed up and it is not any individual player that is affected. This maybe the reason why in my streaming solution the media playback dies in a while and as I've already noticed there seems to be a serious regression in the media playback ability compared to the earlier versions of VBox I've tested on. Also, client reboot is required in order to restore sound once it dies.

[Rafcio]

I'm pretty sure that the problem is with sound card emulation. After switching to Sound Blaster sound card in the client configuration and installing the necessary driver in the client the sound doesn't die anymore. Winamp keeps playing for days without any noticeable issues (so far). However, there is one issue with Sound Blaster emulation. When booting the client there is a continuous clicking sound between the time the machine is booted (I assume sound support activated in the client) and the time some other sound is played. When Winamp starts "playing" (the sound is really muted, but the streaming starts) the clicking sound stops. Everything seems OK after that.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.