[alsa-devel] Problems with alsa on ARM
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.
Alan
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
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
On Thursday 17 July 2008 11:01, you wrote:
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.
Liam, Takashi, thanks for your quick replies on this thread a while ago. My collegue did finally nail this issue, which I will explain for anyone following this thread or in the archives.
We are currently using the Buildroot system which uses the uClibc libraries. Simply, uClibc does not support versioned symbols. Therefore it is necessary to override the ALSA-lib default by adding --with-versioned=no to the build. Aplay, Alsamixer etc run without problems.
I think the gcc optimisation bug may be fixed on recent gcc versions; it didn't in the end turn out to be causing us any problems.
We also noticed that it would be easy to accidentally build kernel and libs with different settings of -mabi, which would also cause problems.
Regards
Alan
participants (3)
-
Alan Horstmann -
Liam Girdwood -
Takashi Iwai