[MPlayer-users] error compiling: libao2: missing AFMT_U* defines

[Walter Haidinger]

On Tue, 28 Dec 2004, Reimar Döffinger wrote:

> Hi,

Hi! Thanks for your reply!

> > I'm unable to compile MPlayer-1.0pre6 and the most recent CVS version 
> > unter SuSE 9.1 with vanilla 2.6.10 kernel and commercial OSS 3.99.1i 
> > drivers.
> 
> In current CVS this problem only exists with OSS output.
> Normally missing formats are defined in afmt.h, but we assumed that
> everyone specifying the signed variant would also specify the unsigned.

Yes. The only source of AFMT_* defines is in soundcard.h which comes with 
OSS.
 
> > The OSS developers think it is a mplayer bug. 
> > I've appended their reply below.
> 
> [...]
> 
> > PPS: Here's the response of the OSS developers regarding the bug.
> >      Hope that helps too!
> > 
> > Hi,
> > 
> > This is definitely a bug in mplayer.
> 
> And there are people that tell me only MPlayer developers are so
> arrogant as to make such statements... Well...

Well, I don't consider the OSS developers being arrogant. Their support is 
exceptional good and very quick. Really nothing to complain about.

And no, I was _not_ my intension to raise some bad feelings about OSS.
Instead, this should have helped to narrow the bug, i.e. it is not a bug 
in the OSS drivers.
 
> > The only unsigned format being used by any hardware is AFMT_U8. The 16 and
> > 24 bit formats supported by the sound cards are always signed ones. So
> > trying to use formats like AFMT_U32_LE doesn't make any sense.
> > 
> > I don't know where the authors of mplayer have found formats like
> > AFMT_U32_LE but they don't exist in OSS and they will not be added to it
> > in the future.
> 
> Where we found it? Well it can be easily found in files or as the result
> of decompression. Also the fact that no soundcard _now_ supports these
> formats says nothing about the future...

The only thing the OSS people are saying is, that they only provide 
defines for formats they support. Any application that require other (like 
mplayer) should bring its own. Makes sense me, or not?

> The only thing that might be considered a bug in our code is that anyone
> who defines AFMT_S<something> will also define AFMT_U<something>.
> And I think it is a bug in the commercial OSS headers not only because it
> works with anything else but also that it is nonsense to call a format
> explicitly "signed" if there is no and never will be a "unsigned" variant
> (the linux kernel defines AFMT_U16_LE btw).

IMHO, you cannot expect to have formats defined in a driver header file 
which are neither used nor supported by the driver. Having defines which 
*might* be supported anywhere in the future would be just confusing.

And yes, AFMT_U16* and AFMT_S16* are defined in the kernel headers but not 
AFMT_U24 and AFMT_U32.

> Not to mention that adding a few defines just for consistency's sake is
> not much of a problem.

(Warning: don't read the next line if you can't stand the fire! ;-)
Then why are they missing in mplayer? 

No, seriously now. I don't want to start a flame war about this but as I 
said above, it should be mplayer to provide defines for "own" or 
"internal" (say, not supported by the driver) formats IMHO.

> Ah, isn't it a nice state of things when everyone can confidently claim
> it's the other one's fault? ;-)

Isn't that human? ;-)

> Anyway, after latest changes to CVS the problem is confined to ao_oss.c
> and should be easily fixable with a few #ifdefs. Feel free to provide a
> patch or wait until somebody else does.

Yes, compilation aborts with undeclared identifiers in libao2/ao_oss.c in 
the most recent CVS checkout.

I'd be glad to provide a patch. However, _where_ do I find the correct 
values for AFMT_U24_LE, AFMT_U24_BE, AFMT_U32_LE and AFMT_U32_BE?
They're neither in the kernel nor in the mplayer sources (obviously).
I'd really appreciate a hint where to look! 

Regards and Happy New Year, everybody (*)
Walter

(*) yes, I know, I'm a day too early but I don't know if I manage
    to read the mailing list _this_ year yet... ;-)