Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#165 closed defect (fixed)

Short WAV files not played till EOF

Reported by: pub_br_mplayerhq.hu@… Owned by: alex@…
Priority: normal Component: ao
Version: HEAD Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

Short files in WAV format are not completely played, the
last one or two seconds are missing.

I noticed that bug because I had configured Mozilla Firefox
to use MPlayer to play WAV files for the Merriam Webster
Dictionary, which uses WAV files for the pronounciation
hints.

Try to play this:

http://www.m-w.com/cgi-bin/audio.pl?motorc03.wav=motorcycle

(or any other pronounciation WAV file from there) with both
wavplay and MPlayer:

wavplay says "motorcycle" (correct)
MPlayer says "mo" (too short)

Playing with "-nocache" and "-abs" doesn't help.

This bug is in MPlayer since ages (and no reports yet in the
list of known bugs), so I haven't tried the CVS version.

Maybe this bug applies not only to short WAV files, but also
to long WAV files, but I don't have proper test files to try
that.

The bug seems to be kernel version independent (currently
using 2.4.27).

Attachments (1)

aos_wait.diff (2.5 KB) - added by reimar 13 years ago.
fix some aos

Download all attachments as: .zip

Change History (11)

comment:1 Changed 13 years ago by compn

i think its related to the ao, dsound plays 'mo' while -ao win32 plays 'motorcycle' on windows...

comment:2 Changed 13 years ago by compn

  • op_sys changed from Linux to All
  • Version changed from 1.0pre3 to CVS

btw, i tested with cvs, so i will chang OS to ALL.. and cvs version.

Changed 13 years ago by reimar

fix some aos

comment:3 Changed 13 years ago by reimar

Not all aos respect the immed flag. Currently working should be OSS,
polypaudio, sun and win32. The attached patch should fix alsa, dsound, nas, sdl
and sgi, but only alsa and sdl are tested and the fix for sdl is ugly.
If you can, please test the others.
All others are broken (although some the other way round, not stopping audio
immediately when you quit MPlayer).

comment:4 Changed 13 years ago by pub_br_mplayerhq.hu@…

Due to the reported security issues, I upgraded directly to
1.0pre5try2 - works perfectly with OSS, thank you!

Next time, I'll add that I'm using OSS, sorry. :-}

comment:5 Changed 13 years ago by reimar

sorry, but that can't be the reason as try2 does not change anything except
security fixes, and they can't really make a diffrence here.

comment:6 Changed 13 years ago by pub_br_mplayerhq.hu@…

Just wanted to narrow down the issue by recompiling
1.0pre3, but I cannot do so anymore. A clean
./configure && make gives tons of linker errors:

[...]
libavcodec/libavcodec.a(dsputil_mmx.o)(.text+0x1be09): In function
`put_no_rnd_qpel8_mc22_3dnow':
: undefined reference to `ff_pw_20'
[...]

1.0pre5try2 compiles just fine with a pure ./configure && make.

Anyway, the bug, although there for a long time, suddenly
and mystically disappeared, and I am happy. :-} But if you
are nevertheless interested in narrowing it down, let me
know, maybe we can find out.

Annotation: I removed my ~/.mplayer and /etc/mplayer, and
the behavior is still the same: 1.0pre3 truncates the WAV
output while 1.0pre5try2 doesn't. 1.0pre5 works, too.

comment:7 Changed 13 years ago by reimar

(In reply to comment #6)

Just wanted to narrow down the issue by recompiling
1.0pre3, but I cannot do so anymore. A clean

Sorry, I was assuming you compared pre5 with pre5try2...
That can of course be, I think the immed uninit flag (telling whether to play
any buffered sound to the end or not) was added after this...

Anyway, the bug, although there for a long time, suddenly
and mystically disappeared, and I am happy. :-} But if you
are nevertheless interested in narrowing it down, let me
know, maybe we can find out.

No, I think the cause is mostly clear in this case. Although there are similar
problems with some windows bnary codecs which are not yet fixed.

comment:8 Changed 13 years ago by dominik@…

  • Resolution set to fixed
  • Status changed from new to closed
  • Version changed from CVS to 1.0pre3

So this was a bug in 1.0pre3, not any later version? Closing as fixed then.

comment:9 Changed 13 years ago by reimar

  • Component changed from core to ao
  • rep_platform changed from PC (x86 with 3D Now) to All
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 1.0pre3 to CVS

Actually no. With pre5 and later it seems to work with some aos, but some are
still broken. Changed component to ao, version to CVS and Hardware to all.

comment:10 Changed 13 years ago by reimar

  • Resolution set to fixed
  • Status changed from reopened to closed

I applied the patch, it should be fixed now for this case (raw wav). A similar
problem still seems to exist with (some?) files that need binary windows codecs.

Note: See TracTickets for help on using tickets.