snd_pcm_hw_params_get_period_size points to __old_ symbol

snd_pcm_hw_params_get_period_size points to __old_ symbol

[Daniel Mack]

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

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Liam Girdwood]

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 

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Daniel Mack]

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

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Daniel Mack]

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

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Liam Girdwood]

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

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Daniel Mack]

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

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Liam Girdwood]

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

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Alan Horstmann]

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

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Daniel Mack]

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

Re: snd_pcm_hw_params_get_period_size points to __old_ symbol

[Alan Horstmann]

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