[alsa-devel] snd_pcm_hw_params_get_period_size points to __old_ symbol
Hi,
With alsa-lib and alsa-utils cross-compiled for ARM by buildroot (currently version 1.0.19, but earlier versions seem to be equally affected), I encounter the effect that snd_pcm_hw_params_get_period_size() does not write the expected value to the given snd_pcm_uframes_t pointer. In fact, this variable is not written at all. This makes aplay calculate 0 for chunk_bytes in set_params() and then exit with the bogus error message "Not enough memory". I did some tracing and found out that the function called for snd_pcm_hw_params_get_period_size() is in fact __old_snd_pcm_hw_params_get_period_size() which has a different footprint and hence the pointer given to it is leaved untouched.
As I don't fully understand all the system behind the symbol names remapping, I'm stuck here. Can anybody reproduce this bug?
Daniel
On Sun, 2009-02-22 at 22:35 +0100, Daniel Mack wrote:
Hi,
With alsa-lib and alsa-utils cross-compiled for ARM by buildroot (currently version 1.0.19, but earlier versions seem to be equally affected), I encounter the effect that snd_pcm_hw_params_get_period_size() does not write the expected value to the given snd_pcm_uframes_t pointer. In fact, this variable is not written at all. This makes aplay calculate 0 for chunk_bytes in set_params() and then exit with the bogus error message "Not enough memory". I did some tracing and found out that the function called for snd_pcm_hw_params_get_period_size() is in fact __old_snd_pcm_hw_params_get_period_size() which has a different footprint and hence the pointer given to it is leaved untouched.
As I don't fully understand all the system behind the symbol names remapping, I'm stuck here. Can anybody reproduce this bug?
AFAICT, buildroot builds a broken ALSA ARM userspace. I've had driver bug reports from numerous users for about 2 years now due to buildoot building a faulty ARM ALSA userspace. I've also asked each bug reporter to report this to buildroot bugzilla. Seems it's not fixed yet.
Please either build alsa-lib natively or with OpenEmbedded.
Liam
Hi Liam,
On Sun, Feb 22, 2009 at 10:07:57PM +0000, Liam Girdwood wrote:
I'm currently implementing support for a board based on a PXA300 with an I2S codec (CS4270) next to it. Things do work in general, including the setup of the SSP engine and clocks, and when using the OSS compat layer, I can see data on the bus. With the native ALSA API, however, the DMA pointer does not move forward but is stuck at position 8. ALSA's core calls pxa2xx_pcm_pointer() a couple of times and eventually gives up on it. Unfortunately, I don't have a Zylonite board for cross-check; could anyone verify that things are not currently broken in a general way?
My code base is up-to-date to sound-2.6.git/for-2.6.30.
Can't test on my zylonite atm, but static DMA pointers usually mean data is not being clocked out of the SSP FIFO. Can you check you are supplying a BCLK and LRC to the SSP port (if codec is BCLK/LRC master) or have enabled the PXA SSP master mode (if codec slave).
All the clocks are there, they're only driven by the Codec, and they look fine. And thus, the CPU DAI is set to SND_SOC_DAIFMT_CBM_CFM.
What puzzles me is that the whole system works when I cat /dev/urandom to /dev/dsp (the DMA pointer is moving forward just as expected), only when using aplay it doesn't do anything.
Thanks, Daniel
On Sun, Feb 22, 2009 at 10:15:56PM +0000, Liam Girdwood wrote:
With alsa-lib and alsa-utils cross-compiled for ARM by buildroot (currently version 1.0.19, but earlier versions seem to be equally affected), I encounter the effect that snd_pcm_hw_params_get_period_size() does not write the expected value to the given snd_pcm_uframes_t pointer. In fact, this variable is not written at all. This makes aplay calculate 0 for chunk_bytes in set_params() and then exit with the bogus error message "Not enough memory". I did some tracing and found out that the function called for snd_pcm_hw_params_get_period_size() is in fact __old_snd_pcm_hw_params_get_period_size() which has a different footprint and hence the pointer given to it is leaved untouched.
As I don't fully understand all the system behind the symbol names remapping, I'm stuck here. Can anybody reproduce this bug?
AFAICT, buildroot builds a broken ALSA ARM userspace. I've had driver bug reports from numerous users for about 2 years now due to buildoot building a faulty ARM ALSA userspace. I've also asked each bug reporter to report this to buildroot bugzilla. Seems it's not fixed yet.
Interesting, thanks for pointing that out.
Please either build alsa-lib natively or with OpenEmbedded.
This is rather unpracticable for us as we build the whole system with buildroot. Hence, I'd rather go and fix it. Any hint about what could possibily go wrong during the build phase which would explain that bug to happen? A missing/wrong define, bogus configure arguments?
Daniel
On Sun, 2009-02-22 at 23:22 +0100, Daniel Mack wrote:
On Sun, Feb 22, 2009 at 10:15:56PM +0000, Liam Girdwood wrote:
Please either build alsa-lib natively or with OpenEmbedded.
This is rather unpracticable for us as we build the whole system with buildroot. Hence, I'd rather go and fix it. Any hint about what could possibily go wrong during the build phase which would explain that bug to happen? A missing/wrong define, bogus configure arguments?
Probably best to check against OE alsa-lib config arguments. They have gitweb now for easy browsing.
Thanks
Liam
On Sun, Feb 22, 2009 at 10:24:48PM +0000, Liam Girdwood wrote:
Please either build alsa-lib natively or with OpenEmbedded.
This is rather unpracticable for us as we build the whole system with buildroot. Hence, I'd rather go and fix it. Any hint about what could possibily go wrong during the build phase which would explain that bug to happen? A missing/wrong define, bogus configure arguments?
Probably best to check against OE alsa-lib config arguments. They have gitweb now for easy browsing.
Ok, will do and let you know. So probably both my questions would have the same root cause, which would be great :)
Thanks, Daniel
On Sun, 2009-02-22 at 23:27 +0100, Daniel Mack wrote:
On Sun, Feb 22, 2009 at 10:24:48PM +0000, Liam Girdwood wrote:
Please either build alsa-lib natively or with OpenEmbedded.
This is rather unpracticable for us as we build the whole system with buildroot. Hence, I'd rather go and fix it. Any hint about what could possibily go wrong during the build phase which would explain that bug to happen? A missing/wrong define, bogus configure arguments?
Probably best to check against OE alsa-lib config arguments. They have gitweb now for easy browsing.
Ok, will do and let you know. So probably both my questions would have the same root cause, which would be great :)
Hopefully :)
The only other major ARM alsa-lib PITA is gcc 4.1.1. It would optimise out PCM refinement. Although OE patched their gcc years ago so probably not an issue anymore.
Liam
On Sunday 22 February 2009 22:22, Daniel Mack wrote:
On Sun, Feb 22, 2009 at 10:15:56PM +0000, Liam Girdwood wrote:
With alsa-lib and alsa-utils cross-compiled for ARM by buildroot (currently version 1.0.19, but earlier versions seem to be equally affected), I encounter the effect that snd_pcm_hw_params_get_period_size() does not write the expected value to the given snd_pcm_uframes_t pointer. In fact, this variable is not written at all. This makes aplay calculate 0 for chunk_bytes in set_params() and then exit with the bogus error message "Not enough memory". I did some tracing and found out that the function called for snd_pcm_hw_params_get_period_size() is in fact __old_snd_pcm_hw_params_get_period_size() which has a different footprint and hence the pointer given to it is leaved untouched.
As I don't fully understand all the system behind the symbol names remapping, I'm stuck here. Can anybody reproduce this bug?
AFAICT, buildroot builds a broken ALSA ARM userspace. I've had driver bug reports from numerous users for about 2 years now due to buildoot building a faulty ARM ALSA userspace. I've also asked each bug reporter to report this to buildroot bugzilla. Seems it's not fixed yet.
Interesting, thanks for pointing that out.
Please either build alsa-lib natively or with OpenEmbedded.
This is rather unpracticable for us as we build the whole system with buildroot. Hence, I'd rather go and fix it. Any hint about what could possibily go wrong during the build phase which would explain that bug to happen? A missing/wrong define, bogus configure arguments?
Just thought I would chip in from the sidelines here; we have successfully built for ARM (AT91 though) using Buildroot.
Looking back to my posting on devel list dated 12.08.08, one problem was:
"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. "
Just in case that is any help.
Alan
On Mon, Feb 23, 2009 at 11:52:39AM +0000, Alan Horstmann wrote:
This is rather unpracticable for us as we build the whole system with buildroot. Hence, I'd rather go and fix it. Any hint about what could possibily go wrong during the build phase which would explain that bug to happen? A missing/wrong define, bogus configure arguments?
Just thought I would chip in from the sidelines here; we have successfully built for ARM (AT91 though) using Buildroot.
Looking back to my posting on devel list dated 12.08.08, one problem was:
"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.
Yes, as discussed on the buildroot mailing list in the last few hours, this is what makes it work for me, too. There will be a fix for buildroot to make it add this configure option.
Unfortunately, this does not solve the other "pxassp pointer not moving" issue, but I will follow up on this in the other thread.
Thanks for the help on this one to anyone who jumped in!
Daniel
On Monday 23 February 2009 11:32, you wrote:
On Mon, Feb 23, 2009 at 11:52:39AM +0000, Alan Horstmann wrote:
Looking back to my posting on devel list dated 12.08.08, one problem was:
"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.
Yes, as discussed on the buildroot mailing list in the last few hours, this is what makes it work for me, too. There will be a fix for buildroot to make it add this configure option.
It's frustrating, as my collegue pointed that out on that list in July 08:
http://lists.busybox.net/pipermail/buildroot/2008-July/009884.html
Alan
participants (4)
-
Alan Horstmann -
Daniel Mack -
Liam Girdwood -
Liam Girdwood