5:32 p.m.
On 2006/03/27 17:40:58 +0 you committed changes in cvs head. After
that compilation fails as follows.
alsaplay.c: In function `set_volume':
alsaplay.c:231: error: void value not ignored as it ought to be
alsaplay.c:254: error: `SND_MIXER_SCHN_REAR_CENTER' undeclared (first use in this
function)
alsaplay.c:254: error: (Each undeclared identifier is reported only once
alsaplay.c:254: error: for each function it appears in.)
alsaplay.c:262: error: `SND_MIXER_SCHN_SIDE_LEFT' undeclared (first use in this
function)
alsaplay.c:266: error: `SND_MIXER_SCHN_SIDE_RIGHT' undeclared (first use in this
function)
alsaplay.c: In function `reset_volume':
alsaplay.c:298: error: `SND_MIXER_SCHN_REAR_CENTER' undeclared (first use in this
function)
alsaplay.c:306: error: `SND_MIXER_SCHN_SIDE_LEFT' undeclared (first use in this
function)
alsaplay.c:310: error: `SND_MIXER_SCHN_SIDE_RIGHT' undeclared (first use in this
function)
make[2]: *** [alsaplay.o] Error 1
In `libalsa2-devel-1.0.2-3mdk' binary package
`snd_mixer_selem_get_playback_volume_range' return type is `void'.
Please add checks both for that and for possibly missing
`snd_mixer_selem_channel_id_t' enum items. In this version both this
type enum is defined and `snd_mixer_selem_get_playback_volume_range'
is declared in `<alsa/mixer.h>', and the following include set is
enough to compile.
#include <sys/types.h>
#include <alsa/mixer.h>
Or at least please determine the lowest required `libalsa' version and
document it in `INSTALL'.
7:13 p.m.
Ilya,
"Ilya N. Golubev" <gin(a)mo.msk.ru> wrote:
On 2006/03/27 17:40:58 +0 you committed changes in cvs head. After
that compilation fails as follows.
I owe you an apology. You *did* send this to xemacs-beta. It just took
a long time to get from there to me, and I didn't notice the CC on the
version in my personal inbox. I'll be more careful next time.
Regards,
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
5:17 p.m.
Ilya,
"Ilya N. Golubev" <gin(a)mo.msk.ru> wrote:
In `libalsa2-devel-1.0.2-3mdk' binary package
`snd_mixer_selem_get_playback_volume_range' return type is `void'.
Please add checks both for that and for possibly missing
`snd_mixer_selem_channel_id_t' enum items. In this version both this
type enum is defined and `snd_mixer_selem_get_playback_volume_range'
is declared in `<alsa/mixer.h>', and the following include set is
enough to compile.
#include <sys/types.h>
#include <alsa/mixer.h>
Does the following patch fix the build for you?
Index: alsaplay.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/alsaplay.c,v
retrieving revision 1.1
diff -d -u -r1.1 alsaplay.c
--- alsaplay.c 2006/03/27 17:40:58 1.1
+++ alsaplay.c 2006/04/07 16:16:10
＠＠ -41,6 +41,8 ＠＠
#include <alsa/control.h>
#include <alsa/mixer.h>
+#define ALSA_VERSION(major,minor,sub) (((major)<<16) | ((minor)<<8)| (sub))
+
struct mixer_state
{
snd_mixer_t *mixer;
＠＠ -51,22 +53,26 ＠＠
int reset_front_center;
int reset_front_right;
int reset_rear_left;
- int reset_rear_center;
int reset_rear_right;
+ int reset_woofer;
+#if SND_LIB_VERSION >= ALSA_VERSION (1, 0, 10)
+ int reset_rear_center;
int reset_side_left;
int reset_side_right;
- int reset_woofer;
+#endif
/* Old volumes for the channels */
long front_left_vol;
long front_center_vol;
long front_right_vol;
long rear_left_vol;
- long rear_center_vol;
long rear_right_vol;
+ long woofer_vol;
+#if SND_LIB_VERSION >= ALSA_VERSION (1, 0, 10)
+ long rear_center_vol;
long side_left_vol;
long side_right_vol;
- long woofer_vol;
+#endif
};
/* Assemble a machine half-word in little-endian order */
＠＠ -227,9 +233,13 ＠＠
}
/* Translate the Lisp volume range to the device volume range */
+#if SND_LIB_VERSION < ALSA_VERSION (1, 0, 10)
+ snd_mixer_selem_get_playback_volume_range (mix->vol_ctl, &min_vol,
&max_vol);
+#else
if (snd_mixer_selem_get_playback_volume_range (mix->vol_ctl, &min_vol,
&max_vol) < 0)
return;
+#endif
dev_vol = volume * (max_vol - min_vol) / 100 + min_vol;
＠＠ -251,24 +261,26 ＠＠
mix->reset_rear_left = 1;
if (snd_mixer_selem_get_playback_volume
- (mix->vol_ctl, SND_MIXER_SCHN_REAR_CENTER, &mix->rear_center_vol) >=
0)
- mix->reset_rear_center = 1;
-
- if (snd_mixer_selem_get_playback_volume
(mix->vol_ctl, SND_MIXER_SCHN_REAR_RIGHT, &mix->rear_right_vol) >= 0)
mix->reset_rear_right = 1;
if (snd_mixer_selem_get_playback_volume
+ (mix->vol_ctl, SND_MIXER_SCHN_WOOFER, &mix->woofer_vol) >= 0)
+ mix->reset_woofer = 1;
+
+#if SND_LIB_VERSION >= ALSA_VERSION (1, 0, 10)
+ if (snd_mixer_selem_get_playback_volume
+ (mix->vol_ctl, SND_MIXER_SCHN_REAR_CENTER, &mix->rear_center_vol) >=
0)
+ mix->reset_rear_center = 1;
+
+ if (snd_mixer_selem_get_playback_volume
(mix->vol_ctl, SND_MIXER_SCHN_SIDE_LEFT, &mix->side_left_vol) >= 0)
mix->reset_side_left = 1;
if (snd_mixer_selem_get_playback_volume
(mix->vol_ctl, SND_MIXER_SCHN_SIDE_RIGHT, &mix->side_right_vol) >= 0)
mix->reset_side_right = 1;
-
- if (snd_mixer_selem_get_playback_volume
- (mix->vol_ctl, SND_MIXER_SCHN_WOOFER, &mix->woofer_vol) >= 0)
- mix->reset_woofer = 1;
+#endif
/* Set the volume */
snd_mixer_selem_set_playback_volume_all (mix->vol_ctl, dev_vol);
＠＠ -293,14 +305,19 ＠＠
snd_mixer_selem_set_playback_volume
(mix->vol_ctl, SND_MIXER_SCHN_REAR_LEFT, mix->rear_left_vol);
- if (mix->reset_rear_center)
- snd_mixer_selem_set_playback_volume
- (mix->vol_ctl, SND_MIXER_SCHN_REAR_CENTER, mix->rear_center_vol);
-
if (mix->reset_rear_right)
snd_mixer_selem_set_playback_volume
(mix->vol_ctl, SND_MIXER_SCHN_REAR_RIGHT, mix->rear_right_vol);
+ if (mix->reset_woofer)
+ snd_mixer_selem_set_playback_volume
+ (mix->vol_ctl, SND_MIXER_SCHN_WOOFER, mix->woofer_vol);
+
+#if SND_LIB_VERSION >= ALSA_VERSION (1, 0, 10)
+ if (mix->reset_rear_center)
+ snd_mixer_selem_set_playback_volume
+ (mix->vol_ctl, SND_MIXER_SCHN_REAR_CENTER, mix->rear_center_vol);
+
if (mix->reset_side_left)
snd_mixer_selem_set_playback_volume
(mix->vol_ctl, SND_MIXER_SCHN_SIDE_LEFT, mix->side_left_vol);
＠＠ -308,10 +325,7 ＠＠
if (mix->reset_side_right)
snd_mixer_selem_set_playback_volume
(mix->vol_ctl, SND_MIXER_SCHN_SIDE_RIGHT, mix->side_right_vol);
-
- if (mix->reset_woofer)
- snd_mixer_selem_set_playback_volume
- (mix->vol_ctl, SND_MIXER_SCHN_WOOFER, mix->woofer_vol);
+#endif
snd_mixer_close (mix->mixer);
}
Thanks,
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
7:34 p.m.
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.
6:07 p.m.
"Ilya N. Golubev" <gin(a)mo.msk.ru> wrote:
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.
Unfortunately, we had a temporary mailing list outage, so I didn't get
this reply until after committing the other patch. No matter. This is
easily fixed.
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.
Yes, but this is still experimental code. That's why it is on the beta
branch, after all. A recent message tells me that the mixer code is
inappropriate, for example, so I'll have to find a replacement for it.
Note that some of the version-specific code is in there. Also, I have
one machine on which it works great, but I have found another machine
where I am constantly getting "interrupted system call" errors when
attempting to play sounds. I need to track that down. I want to see if
introducing asynchrony is possible. This code is going to remain fluid
for some time until all of these issues are addressed. Until that time,
I don't see the point in spending time writing autoconf checks that
might get discarded when a simple version test will do.
Once the code has settled down and appears stable, migrating to autoconf
checks is the right thing to do for exactly the reasons you list here.
It is just premature right now, in my judgment.
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?
There are 2 variants. Is that too many? And I don't understand what
the number of variants has to do with instability of a library, either.
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?
The header file alsa/asoundlib.h in version 1.0.10 of the library
includes the system <assert.h>. Since we define our own assert macro,
and the glibc 2.4 assert.h, at least, doesn't check whether assert has
already been defined, this leads to a compile error. We cannot just
#undef assert before #include <alsa/asoundlib.h>, because we want our
assert macro, not the system one.
But you are overstating the case. The documentation says that
asoundlib.h is provided as a convenience. It is not documented to be
the sole header file that should be included in all cases. At least, I
fail to see such a statement anywhere in the documentation. Do you? It
can't be anyway, since there are header files in /usr/include/alsa that
are not included by asoundlib.h, nor by anything it includes (e.g.,
pcm_plugin.h for me, version.h for you).
In this case, asoundlib.h is NOT convenient because of the conflicting
assert macros. Therefore, I chose not to use it. This is not an ALSA
bug, so there is no report.
I will fix the version symbol problem in CVS.
Regards,
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
6605
days inactive
6624
days old
4 comments
2 participants
participants (2)
-
Ilya N. Golubev -
Jerry James