[MPlayer-users] possible race condition in audio processing

[trixter aka Bret McDanel]

I have noticed what appears to be a race condition.  I do not know where
it is, and it may or may not be an mplayer issue, but I have noticed it
while using mplayer.

This is probably way more info than needed, but its been my experience
that letting others filter what is unimportant is better than having
them request info later on.

I have a USB drive shared via NFS off a rather slow system connected via
ethernet to a wireless access point.  On the other end I have a
multicore laptop connected via WPA to the access point mounting the
share.  

When I play files over the NFS mount occasionally audio becomes out of
phase.  That is the best way I can describe it, its like when you are
tuning a radio and are slightly off the actual carrier frequency.  The
severity of this varies, as does the frequency it occurs.

Pausing or skipping ahead/back will fix this and audio will continue
normally until at some apparently random time in the future it will
occur again.  The randomness of it makes me think its a race
condition.  

If I copy the file to the local disk, it will play perfectly, implying
that the file is not corrupt and that NFS is not corrupting the data.
Less rare I will see a mpeg4 decoder error saying that the frame is bad,
I think this is related to the same problem.  Generally video is played
back without hiccup, sometimes it will stutter when the audio problem
occurs.

I have heard similar audio distortions in mp3 files that contain bad
frames.  This makes me think that its with the mp3 decoding parts of
mplayer, where the data going in is not correct.  

The files are all AVI files, and all have mp3 audio encoded into them.  

My mplayer version where this happened is r26940.

What I think is going on is that whatever is reading the file and
sending it to the mp3 decoding routines is returning "short data"
blocks, for whatever reason.  

There are 2 scenarios that I can think of that would cause this.  One
would be an mplayer or mplayer dependency issue, the other would be
kernel related.  Detecting what is actually causing this and applying
corrective action would be a good thing.

Scenario 1 is the kernel part - just to get it out of the way.
Basically due to the latency of the USB drive, the read() is returning
before all the data is pushed across the network.  I think this is less
likely, but do not want to rule it out just in case this is the real
problem.  The reason that I think this is less likely is because of the
way that memory is copied in the kernel for a read() call, if it returns
less data the return value should indicate that properly.

Scenario 2 is that there are multiple threads in mplayer, one for mp3
decoding and one to fill the buffer.  The buffer isnt large enough and a
race between the two threads is causing it to read memory that has old
or invalid data causing decoding errors.  I have not made any attempts
to look at the code to see if this is even close to what is going on.

Again if the file is copied from NFS to the local disk and played then
it does not have any of these problems, its only when the NFS drive is
used, which implies its a latency related issue.


-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
Belfast +44 28 9099 6461        US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!