next »

[qwer1304]

Hi,

This is my 1st post - I absolutely LOVE XMplay and have been using it for ages.

I currently use the latest version 3.4.2.1, but the problem I'm reporting about occurs with earlier versions as well.

It seems that XMplay is somewhat less robust with respect to emptying its buffer.

I'm running a mms stream (mms://stream.msn.co.il/glz-stream). Occasionally there's an interrupt in the stream and XMplay re-buffers and continues.

I tried different settings of buffer size which had no effect on the rate of interruptions - obviously the bigger the buffer was the longer it took to re-fill it, so it seems that the issue is NOT starvation of the buffer, but something else.

I tried the same stream with other players - Winamp, VLC work the same as XMplay, but RealPlayer(!) is much more robust (no interrupts).

I didn't find any means to generate logs out of XMplay to see what's happening (I wish I could), but I did get and am attaching the logs from VLC:
main warning: buffer is 42643 in advance, triggering downsampling
main warning: resampling stopped after 3521461 usec (drift: 32246)
main warning: buffer is 41167 in advance, triggering downsampling
main warning: output date isn't PTS date, requesting resampling (-40124)
main warning: resampling stopped after 2162003 usec (drift: 59648)
main warning: buffer is 59649 in advance, triggering downsampling
main warning: output date isn't PTS date, requesting resampling (-40653)
main warning: timing screwed, stopping resampling
main warning: buffer is 93095 in advance, triggering downsampling
main warning: output date isn't PTS date, requesting resampling (-40910)
main warning: audio drift is too big (-135658), clearing out
main warning: timing screwed, stopping resampling
main warning: mixer start isn't output start (-28442)
main debug: audio output is starving (163513), playing silence

Hope one can figure out what's going on and how XMplay can be made more robust.

D

[Ian @ un4seen]

XMPlay doesn't actually download WMA/MMS streams itself (the Windows Media modules do), so I'm not sure there's much that XMPlay can do about it. But here's an update to try, which'll tell the Windows Media stuff to prebuffer for the "Internet streaming / Prebuf" length...

   www.un4seen.com/stuff/xmp-wma.dll

Let me know if playing with the "Prebuf" setting makes any difference, beyond making you wait longer for the music

[qwer1304]

Hi Ian,

Thanx for the prompt response. I'm trying it out and will report my findings.

In the meanwhile, could you please explain how the new XMplay Internet streaming settings work:
- Timeout
- Buffer
- Prebuf

Also, what do you mean by "... to prebuffer for the "Internet streaming / Prebuf" length..."? Are you referring to the aforementioned Prebuf parameter?

Thx,
D

[Ian @ un4seen]

Yep, that is the "Prebuf" option that you should play around with in the update above. Besides that, the "Timeout" setting is the only other "Internet streaming" option to have effect on WMA streams.

[nwo.idaho]

I have also found this same problem with Stream The World's direct connect links to all the CBS Radio stations in mp3 format, while playing in XMPlay.

http://provisioning.streamtheworld.com/pls/KLSXFM.pls

This is the direct stream address to KLSX/97.1 Free-FM/Los Angeles. This stream shows the same behavior as explained in the beginning of this thread. It's plays but it sounds too fast and just kicks out the audio too fast, buffers and lags out.

The service provider tells me not to use 3rd party applications but yet provides backdoor .pls links to different users. 

[qwer1304]

Hi,

Here're some feedbacks:

First of all, turns out that the mms:// key does not specify exactly what protocol will be used: it could be any of mmsu, mmst, rtspu, rtspt or http.

Since, as Ian explained, XMplay uses WMP to decode mms streams, I used WMP and its View|Statistics|Advanced function to get an insight into what was going on (it'd be great if XMplay provided the same info internally).

I learned that the problematic stream was actually an RTSP stream, so I experimented with it using both the UDP and the TCP transports. Here are the results:

1.UDP (rtspu)
The stream showed occasional Recovered and Lost packets that roughly correlated to clicks and other audible interruptions. It also seemed that Lost events resulted in re-buffering.

2.TCP (rtspt)
The Recovered and Lost packets counters were zero, but there were audible interruptions. Perhaps this is a pecularity of TCP that handles restransmissions (recovery) internally.

So it seems that (i) the stream does have some problems, and (ii) the handling of those events (e.g., Recovery and Loss) results in audible (very unpleasant) interruptions.

It seems that RealPlayer does a better job at handling those events.

Let me know if there's anything else that would be helpful.

BR,
D