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.
http://gcc.gnu.org/ml/gcc/2006-04/msg00578.html
Best to check your toolchain and userspace as AT91 audio is quite
mature.
Fwiw, Open Embedded builds a good cross toolchain and userspace for ALSA
on ARM (I use it).
Liam
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
