Opened 19 years ago

Closed 19 years ago

Last modified 19 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: no Analyzed by developer: no

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 19 years ago.
fix some aos

Download all attachments as: .zip

Change History (11)

comment:1 by compn, 19 years ago

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

comment:2 by compn, 19 years ago

op_sys: LinuxAll
Version: 1.0pre3CVS

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

by reimar, 19 years ago

Attachment: aos_wait.diff added

fix some aos

comment:3 by reimar, 19 years ago

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 by pub_br_mplayerhq.hu@…, 19 years ago

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 by reimar, 19 years ago

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 by pub_br_mplayerhq.hu@…, 19 years ago

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 by reimar, 19 years ago

(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 by Dominik 'Rathann' Mierzejewski, 19 years ago

Resolution: fixed
Status: newclosed
Version: CVS1.0pre3

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

comment:9 by reimar, 19 years ago

Component: coreao
rep_platform: PC (x86 with 3D Now)All
Resolution: fixed
Status: closedreopened
Version: 1.0pre3CVS

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 by reimar, 19 years ago

Resolution: fixed
Status: reopenedclosed

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.