At Thu, 17 Jul 2008 10:56:24 +0100, Liam Girdwood wrote:
On Wed, 2008-07-16 at 21:22 +0100, Alan Horstmann wrote:
Hi,
I am trying to assist a collegue, we're working on ARM (AT91), and having probs with alsa stuff.
Can anyone help interpret this strace from aplay -v -Dhw:0 ourfile.wav? I am comparing it to the same operation on a desktop PC. After all sorts of pre-amble, it gets down to accessing snd devices:
open("/dev/snd/controlC0", O_RDONLY) = 3 close(3) = 0 open("/dev/snd/controlC0", O_RDWR) = 3 ioctl(3, USBDEVFS_CONTROL, 0xbecd36ac) = 0 ioctl(3, 0x40045532, 0xbecd36b4) = 0 open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 4 close(3) = 0 ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0xbecd34f8) = 0 fcntl(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) ioctl(4, AGPIOC_INFO, 0xbecd36a4) = 0 ioctl(4, AGPIOC_RELEASE or APM_IOC_SUSPEND, 0xbecd369c) = 0 mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000) = -1 ENXIO (No such device or address) ioctl(4, 0xc0844123, 0xbecd3618) = 0 fcntl(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) fcntl(4, F_SETFL, O_RDWR) = 0 ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0xbecd398c) = 0
The first failure is from mmap2(..). Exactly the same line (and values) is successful on PC, but I don't know what it is doing or why it might fail.
There are no other negative returns at all, but after opening the wav file, the playback info is written out, and set_params begins:
ioctl(4, 0xc25c4110, 0xbecd3628) = 0 ioctl(4, 0xc25c4110, 0xbecd3628) = 0 ioctl(4, 0xc25c4110, 0xbecd3628) = 0 ioctl(4, 0xc25c4110, 0xbecd3628) = 0 ioctl(4, 0xc25c4111, 0xbecd3628) = 0 ioctl(4, 0xc0844123, 0x1c210) = 0 ioctl(4, 0xc0684113, 0xbecd3528) = 0 ioctl(4, 0x4140, 0) = 0 ioctl(4, 0xc0844123, 0x1c210) = 0 write(2, "aplay", 5aplay) = 5 write(2, ": ", 2: ) = 2 write(2, "set_params", 10set_params) = 10 write(2, ":", 1:) = 1 write(2, "1012", 41012) = 4 write(2, ": ", 2: ) = 2 write(2, "unable to install sw params:", 28unable to install sw params:) = 28
All seems to go OK with hw_params, but sw_params must return error (not seen) as the error check fails. The values printed out show xfer_align = 3201120484 which looks suspicious to me.
Any clues on either of these would be greatly appreciated.
This sounds similar to a recent gcc optimisation bug with ALSA on ARM.
I remember a similar problem due to toolchain, too.
Note that the failure of mmap calls is OK. The driver returns the error intentionally because no status/control record mmap is supported on ARM.
thanks,
Takashi