Package: mpg321
Version: 0.2.10.4
Severity: normal
Tags: patch
Tags: etch

mpg321 appears to have dead upstream and orphaned in Debian, but I'm
filing this anyway if someone likes to pick it up.

Background:

I'm streaming mp3's over sshfs and using cplay to play them. cplay is a
nice python script and uses mpg321 and other players to actually decode.
Without thinking too much I installed mpg321 for mp3 playback even when
mpg123 is now free and available. This bug appears in both etch and sid,
though I have a faint recollection of seeing this in sarge and woody too.

Problem:

Playing most ogg's and mp3's works like a charm, but some files seem to
start playing only after they have been downloaded completely. So much 
for the streaming experience.

Debugging:

Here is strace output with a problematic mp3 file, note the jump in time 
stamps:

1222280348.402663 fstat64(4, {st_mode=S_IFREG|0644, st_size=5433202, ...}) = 0 
<0.000013>
1222280348.402771 lseek(4, -128, SEEK_END) = 5433074 <0.000013>
1222280348.402836 read(4, "TAG"..., 3)  = 3 <0.000018>
1222280348.402912 mmap2(NULL, 5433074, PROT_READ, MAP_SHARED, 4, 0) = 
0xb745a000 <0.000021>
1222280352.341758 munmap(0xb745a000, 5433074) = 0 <0.000394>
^^^^^^^^^^^^^^^^^ what did mpg321 do these four seconds, it for sure didn't 
                  play any music
1222280352.342253 close(4)              = 0 <0.000078>
1222280352.342402 brk(0x957a000)        = 0x957a000 <0.000019>
1222280352.342483 mmap2(NULL, 5433074, PROT_READ, MAP_SHARED, 3, 0) = 
0xb745a000 <0.000023>
1222280352.342561 close(3)              = 0 <0.000082>

For reference, here is the same strace output with an mp3 file which works in 
'streaming mode':

1222280330.498432 fstat64(4, {st_mode=S_IFREG|0644, st_size=4053943, ...}) = 0 <
0.000013>
1222280330.498541 lseek(4, -128, SEEK_END) = 4053815 <0.000012>
1222280330.498603 read(4, "\377\377\377"..., 3) = 3 <0.000015>
1222280330.498679 mmap2(NULL, 4053943, PROT_READ, MAP_SHARED, 4, 0) = 0xb7514000
 <0.000019>
1222280330.498806 munmap(0xb7514000, 4053943) = 0 <0.000032>
1222280330.498887 close(4)              = 0 <0.000139>

Since it finds a "TAG", mpg321 does a full file scan for mp3 length 
information before starting playback of this file. Source file mad.c, 
function scan comments this with:

    /* There are three ways of calculating the length of an mp3:
      1) Constant bitrate: One frame can provide the information
         needed: # of frames and duration. Just see how long it
         is and do the division.
      2) Variable bitrate: Xing tag. It provides the number of
         frames. Each frame has the same number of samples, so
         just use that.
      3) All: Count up the frames and duration of each frames
         by decoding each one. We do this if we've no other
         choice, i.e. if it's a VBR file with no Xing tag.
    */

Ok, it appears to have no choice, but totem and mpg123 don't do this.

Fix:

One solution is to just stop doing this file scan after some magic value. 
I'm riding with the --quiet or -q option, since cplay calls mpg321 with it, 
and it seems like the best choice of the existing command line options.
Adding an option like --nolenscan is possible, but that would require
changes in the scripts using mpg321, like cplay.

So I came up with this. 

--- mpg321-0.2.10.4/mad.c       2002-03-24 07:49:31.000000000 +0200
+++ mpg321-0.2.10.4-mcf/mad.c   2008-09-25 00:02:48.000000000 +0300
@@ -444,6 +444,14 @@
         {   
             break;
         }
+
+       /* In quiet mode, don't scan the whole file for length since
+           it takes so long on slow file systems like sshfs. cplay
+           calls mpg321 for playback in quiet mode. */
+        if ((options.opt & MPG321_QUIET_PLAY) && (buf->num_frames > 20))
+        {
+            break;
+        }

         mad_timer_add(&buf->duration, header.duration);
     }


It appears to have no negative effect on playback. Songs play as the did 
before, just not without the long delay in the beginning.

Workaround:

cplay likes mpg123 more than mpg321, so just install mpg123 which doesn't
suffer from this bug. Perhaps mpg321, if unmaintained and dead upstream,
should be dropped from Debian. And mpg123 could perhaps provide mpg321.
How funny is that, considering why mpg321 was once created?

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mpg321 depends on:
ii  libao2                 0.8.8-4           Cross Platform Audio Output Librar
ii  libc6                  2.7-13            GNU C Library: Shared libraries
ii  libid3tag0             0.15.1b-10        ID3 tag reading library from the M
ii  libmad0                0.15.1b-3         MPEG audio decoder library
ii  zlib1g                 1:1.2.3.3.dfsg-12 compression library - runtime

mpg321 recommends no packages.

mpg321 suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to