alsa support does not compile

[Ilya N. Golubev]

The patch does not work with my library version.  With it
`SND_LIB_VERSION' remains undefined.  It is defined in
'alsa/version.h', but this file is not included by the source,
directly or indirectly.


Why check library version explicitly instead of check for its
interface itself?  Always a library can appear that <is hybrid or
customized> (from <(autoconf) Introduction>) and does not obey the
assumed version conventions, but is still correct in that in one or
another way it is compatible with some original library version.  This
is exactly what autoconf is for.

If there is too many variants of library interface to write checks
for, that is, the library is that unstable, why use it at all?


When an "official" do-it-right header (the comment suggests it is
`alsa/asoundlib.h' in this case) is not included, the program thus
tries to rely on library internals and is always prone to failure.  In
my version `#include <alsa/version.h>' before other alsa ones works,
in other ones it may just not exist.  The comment also says why
`alsa/asoundlib.h' is not included.  Do alsa maintainers have a bug
report so that it is fixed in some next version?  Is there a published
copy of that report?

Redefining these preprocessor symbols by alsa headers is also
checkable.  If we know (from these checks) exactly what symbols it
tries to redefine, a workaround should be possible.  What about adding
both?

What is the alsa version that suffers from all of that?  With mine,
after wrote sole

#include <alsa/asoundlib.h>

do not getting any preprocessor symbol redefinition warnings.  Does
the broken version `#undef' them first, and that redefinition
(potentially) breaks other things?  If yes, what is broken?

Moreover, this way xemacs with alsa sound enabled builds normally.