[MPlayer-dev-eng] MPEG to S/PDIF passthrough

[Ilkka Karvinen]

On Friday 07 March 2008 02:20, Ulion wrote:
> 2008/3/7, Ilkka Karvinen <kartsan at gmail.com>:
> > On Thursday 06 March 2008 13:57, Ulion wrote:
> >  > 2008/3/6, Ulion <ulion2002 at gmail.com>:
> >  > > 2008/3/5, Ilkka Karvinen <kartsan at gmail.com>:
> >  > > > There have been no comments on this patch. I'm wondering if there
> >  > > > could be
> >  > > >
> >  > >  >  people around here who have a home theater amplifier which
> >  > >  > supports MPEG audio? It would be interesting to hear if this
> >  > >  > feature works with your hardware. Especially if you are running
> >  > >  > mplayer on a bigendian machine since I can't currently test this
> >  > >  > code on a such machine.
> >  > >  >
> >  > >  >  If your amplifier supports AC3/DTM decoding, its DSP may also
> >  > >  > support MPEG audio. My old Harman Kardon amplifier uses Cirrus
> >  > >  > Logic's DSP which supports it and that was my initial reason to
> >  > >  > start investigating this stuff.
> >  > >  >
> >  > >  >  I send attached diff that Ulion made for me if you would like to
> >  > >  > give a try to this feature. It adds new codec hwmp3 which
> >  > >  > redirects the MPEG frames to hardware via S/PDIF.
> >  > >  >
> >  > >  >  I have tested it and it works with mp3 audio files and video
> >  > >  > files with mp3 audio track. However, some mp3 files do not work
> >  > >  > and I don't know why. My guess is that their frames are not
> >  > >  > recognised by my hardware. There are no similarities with the
> >  > >  > failing samples. Another sample with equal parameters (header
> >  > >  > bits are the same) may work flawlessly.
> >  > >
> >  > > found some problem about this patch:
> >  > >
> >  > >  in decode_audio():
> >  > >  +  uint16_t *buf16 = (uint16_t *)buf;
> >  > >
> >  > >  should this be put into the while loop and looks like this:
> >  > >
> >  > >  +  uint16_t *buf16 = (uint16_t *)(buf + toc);
> >  >
> >  > I mean:
> >  > +  uint16_t *buf16 = (uint16_t *)(buf + tot);
> >
> > What is the problem?
> >
> >  > and there's another type value for 'MPEG-2 with extension' it should
> >  > be 6 instead of 5.
> >  > there's also a type value for 'MPEG-2 layer-3 low sampling frequency'
> >  > referred by IEC 61937-4.
> >  > should these two type be handled in the code?
> >
> > Those MPEG-2 types were so rare that I didn't put them there. Actually
> >  there was type 4 in my original implementation which is MPEG-1 layer-1
> >  but even that I've never seen so I dropped it. I can add them to this
> > codec to make sure. I'm pretty sure that the documentation of the DSP in
> > my amplifier said it supports only MPEG-1 layer 3 so those formats were
> > unknown for it anyway...
>
> so what about MPEG-2 with extension? is there a flag in mp3 header to
> indicate it? if there is, we should use it with proper type value.
> and the buf16 code problem I metioned earlier, is your problem with
> some mp3 files resolved after fix it?

Yes, there is a flag in the header which indicates
MPEG version but mplayer's mp_get_mp3_header function in 
libmpdemux/mp3_hdr.c does not return it to the caller, only layer. 
So I suppose I must dig it from the header myself. I take a look at these
now.

And yes, that line should be inside while loop. It was my oops. However,
I didn't notice much difference to failing samples. The problem existed
also with the old standalone C-code which was quite anal in keeping track
of the frames.

Ilkka