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

[Reimar Döffinger]

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.

I was complaining a bit about that "definitly". Things aren't quite that
simple IMHO...

> > > 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?

Not really. It leads to ifdef hell, where every application using it
needs hundreds of ifdefs if it wants to support all features that some
version has.

> > 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.

Well and my opinion is that who says signed should say unsigned too ;-)

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

Yes, but they don't define AFMT_S24 and AFMT_S32 either. I misunderstood
the reply and though that they didn't define AFMT_U16, which would have
been very bad...

> > 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? 

They _are_ there, but they need to have #ifdefs in case they are already
defined. In other words: MPlayer defined e.g. AFMT_U24_LE, AFMT_U24_BE,
AFMT_S24_LE and AFMT_S24_BE if and only if AFMT_S24_LE isn't already
defined. Of course it would have been possible to add an ifdef around
every single definition, but we expected that either all of those
formats for a certain "bitdepth" would be already defined or none...

> said above, it should be mplayer to provide defines for "own" or 
> "internal" (say, not supported by the driver) formats IMHO.

My main point is that it needs a lot of #ifdefs when the header is free
to defines whatever formats it wants - a certain an easy to check scheme
would be more helpful.

> > 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! 

They aren't needed for anything internal so when OSS doesn't support
them in the header there is no reason to define them - just don't
compile the parts that try to use them (so e.g. put a
#ifdef AFMT_U24_LE/#endif block around every place that uses
AFMT_U24_LE).

Greetings,
Reimar Döffinger