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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
