At Thu, 06 Sep 2007 12:56:05 +0100,
James Pearson wrote:
>
> Takashi Iwai wrote:
> >
> > You shouldn't use --enable-static for the dynamic library.
> > Yes, usually it's OK, but alsa-lib has some special handling for
> > static binding, so it cannot be built with dynamic lib together.
> >
> > Thus, for 64bit version,
> >
> > % ./configure --datadir=/etc --libdir=/usr/lib64
> >
> > for 32bit version,
> >
> > % ./configure --datadir=/etc
> >
> > And make sure that all sound apps are killed once (otherwise the old
> > configured dmix instance may remain undead and conflict with the new
> > setting).
> >
> >>Does building alsa-lib depend on the alsa-driver version installed? - as
> >>I built the 32 bit version on a 'stock' CentOS4/RHEL4 install that
> >>didn't have the alsa-driver 1.0.15rc1 installed - would this make a
> >>difference?
> >
> >
> > alsa-lib has backward compatibility, so it should work with the older
> > drivers. The kernel ABI is usually kept, but some exceptional cases
> > like this timer ioctl changes can be supported only by the newer
> > alsa-lib. But, in principle, it's safer to update both alsa-driver
> > and alsa-lib.
> >
> > Also, it's recommended to keep the same version for both 32 and 64bit
> > alsa-lib, too, especially about dmix stuff.
>
> Rebuilt alsa-lib 1.0.15rc1 for both 32 and 64 bit as above, installed
> and rebooted - however, I still can't get it to play with 32 bit apps -
> I still get:
>
> % aplay test.wav
> Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> aplay: pcm_write:1268: write error: Invalid argument
>
> dmesg:
>
> ioctl32(aplay:5957): Unknown cmd fd(3) cmd(40045402){00} arg(ffffacb8)
> on /dev/snd/timer
> ioctl32(aplay:5957): Unknown cmd fd(5) cmd(c008551a){00} arg(0807a140)
> on /dev/snd/controlC0
> ioctl32(aplay:5957): Unknown cmd fd(5) cmd(c008551b){00} arg(0807a140)
> on /dev/snd/controlC0
> ioctl32(aplay:5957): Unknown cmd fd(3) cmd(000054a0){00} arg(00000325)
> on /dev/snd/timer
Ah, I see the point.
With ALSA 1.0.15rc1, we can safely uncomment #if 0 .. #endif in
timer32_new.c and timer32_old.c. These no longer conflict with
existing ioctls. I forgot about it.
The patch is below.
Takashi
diff -r adfe4179d670 acore/ioctl32/timer32_new.c
--- a/acore/ioctl32/timer32_new.c Fri Aug 31 12:22:35 2007 +0200
+++ b/acore/ioctl32/timer32_new.c Thu Sep 06 14:06:40 2007 +0200
@@ -88,18 +88,11 @@ struct ioctl32_mapper timer_mappers[] =
{ SNDRV_TIMER_IOCTL_INFO32, AP(timer_info) },
MAP_COMPAT(SNDRV_TIMER_IOCTL_PARAMS),
{ SNDRV_TIMER_IOCTL_STATUS32, AP(timer_status) },
-#if 0
- /* ** FIXME **
- * The following four entries are disabled because they conflict
- * with the TCOC* definitions.
- * Unfortunately, the current ioctl32 wrapper uses a single
- * hash table for all devices. Once when the wrapper is fixed
- * with the table based on devices, they'll be back again.
- */
+ /* The ioctls are changed, so we can enable them again */
+ /* The old ioctls conflict with TIOC_* definitions */
MAP_COMPAT(SNDRV_TIMER_IOCTL_START),
MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP),
MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE),
MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE),
-#endif
{ 0 },
};
diff -r adfe4179d670 acore/ioctl32/timer32_old.c
--- a/acore/ioctl32/timer32_old.c Fri Aug 31 12:22:35 2007 +0200
+++ b/acore/ioctl32/timer32_old.c Thu Sep 06 14:06:40 2007 +0200
@@ -88,18 +88,11 @@ struct ioctl32_mapper timer_mappers[] =
{ SNDRV_TIMER_IOCTL_INFO32, AP(timer_info) },
MAP_COMPAT(SNDRV_TIMER_IOCTL_PARAMS),
{ SNDRV_TIMER_IOCTL_STATUS32, AP(timer_status) },
-#if 0
- /* ** FIXME **
- * The following four entries are disabled because they conflict
- * with the TCOC* definitions.
- * Unfortunately, the current ioctl32 wrapper uses a single
- * hash table for all devices. Once when the wrapper is fixed
- * with the table based on devices, they'll be back again.
- */
+ /* The ioctls are changed, so we can enable them again */
+ /* The old ioctls conflict with TIOC_* definitions */
MAP_COMPAT(SNDRV_TIMER_IOCTL_START),
MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP),
MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE),
MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE),
-#endif
{ 0 },
};
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
