Re: alsa on Atmel at91

Re: alsa on Atmel at91

[Michel Benoit]

I put this problem aside for a while but I have now managed to narrow
it down a little

I'm trying to build alsa-lib 1.0.13 for a at91sam9260 target
(arm926ej-s).  I'm using gcc 4.1.2 built with buildroot (uclibc).  I
seem to be having a problem passing in arguments to some libasound
functions.

I have added some printfs to the following lib function (src/pcm.c):


int snd_pcm_hw_params_get_period_size(const snd_pcm_hw_params_t
*params, snd_pcm_uframes_t *val, int *dir)
{
       unsigned long _val;

       printf("get_period_size() %lu %lu %08x %08x %08x \n", _val,
*val, val, dir, params );

       int err = snd_pcm_hw_param_get(params, SND_PCM_HW_PARAM_PERIOD_SIZE,
&_val, NULL);
       if (err >= 0)
               *val = _val;

       printf("get_period_size() %lu %lu %08x %08x %08x %d\n", _val,
*val, val, dir, params, err );

       return err;
}


as well as to the program that calls the lib function (test/pcm.c):


       printf("period_size=%lu %08x dir=%d %08x params %08x \n",
size, &size, dir, &dir, params);
       err = snd_pcm_hw_params_get_period_size(params, &size, NULL);
       if (err < 0) {
               printf("Unable to get period size for playback: %s\n",
snd_strerror(err));
               return err;
       }
       period_size = size;
       printf("period_size=%lu %08x dir=%d %08x params %08x \n",
size, &size, dir, &dir, params);


When I run the program I get the following output

# pcm
Playback device is plughw:0,0
Stream parameters are 44100Hz, S16_LE, 1 channels
Sine wave rate is 440.0000Hz
Using transfer method: write
period_size=49572 bec48954 dir=0 bec48950 params bec489e4
get_period_size() 1073758756 3200551252 bec48924 bec48954 bec489e4
get_period_size() 1248 1248  bec48924 bec48954 bec489e4 0
period_size=49572 bec48954 dir=0 bec48950 params bec489e4

which shows that the pointers to 'params' is ok but that the pointer
to 'val' is incorrect (bec48924 instead of bec48954) and the pointer
to 'dir' is also wrong (bec48954 instead of  bec48950 = the pointer to
val).

What could be the cause of this kind of error?  Somehow the arguments
passed to  snd_pcm_hw_params_get_period_size() are getting mangled.

I have tried removing all optimisations, using other versions of gcc
(4.0.4 and 3.4.6) and using EABI instead of OABI.  I always get the
same result.

Any tips on how I can proceed in debugging this problem?

Are there any compiler or linker flags that could be responsible ?


Michel



On 4/18/07, Michel Benoit <murpme@gmail.com> wrote:
> > >
> > > It seems that that alsa lib is not returning the correct values.  Is
> > > this typical of the gcc bug?
> >
> > Iirc, some pcm refinements were being broken by this bug. So it could be
> > causing the period size = 0.
>
> I've now tried it with no -O option and it still returns period_size
> of 0.  The bug seemed to go away according to the bugzilla report when
> optimization is disabled.
>
> > >
> > > What gcc version are you using?
> >
> > 4.1.1
>
> The bug is also marked as fixed in 4.1.2.
>
> > > Can you also send me the parameters you use with ./configure to setup
> > > the cross-compilation?
> > >
> > > I use the following:
> > >
> > > CFLAGS="-Wall -O1" \
> > > CXXFLAGS="-Wall -O1" \
> > > CC=arm-linux-gcc ./configure \
> > >     --host=arm-linux\
> > >     --prefix=$HOME/bsp/rootfs/buildroot/build_arm/root/usr\
> > >     --with-softfloat\
> > >     --with-debug=yes
> > >
> >
> > The OE recipe used to build alsa-lib for OE is here (although, it needs
> > updating):-
> >
> > http://www.openembedded.org/repo/org.openembedded.dev/packages/alsa/alsa-lib_1.0.13.bb
> >
> > Btw, have you tried any other tests or aplay ?
>
> I run speaker_test from alsa-utils and get exactly the same result.
>
> > What about aplay -Dhw:0.0 file.wav (this should rule out missing conf
> > files that buildroot has not installed)
>
> I will try aplay.
>

Re: alsa on Atmel at91

[Michel Benoit]

After digging through the assembler files it seems that its
__old_snd_pcm_hw_params_get_period_size that is called.



sub	r3, fp, #28
	sub	r2, fp, #32
	ldr	r0, [fp, #-40]
	mov	r1, r3
	bl	snd_pcm_hw_params_get_period_size
	mov	r3, r0
	str	r3, [fp, #-20]

Re: alsa on Atmel at91

[Liam Girdwood]

On Thu, 2007-05-10 at 13:29 +0200, Michel Benoit wrote:
> I put this problem aside for a while but I have now managed to narrow
> it down a little
> 
> I'm trying to build alsa-lib 1.0.13 for a at91sam9260 target
> (arm926ej-s).  I'm using gcc 4.1.2 built with buildroot (uclibc).  I
> seem to be having a problem passing in arguments to some libasound
> functions.
> 

Iirc, the compiler bug also showed up on the dummy alsa device. Does the
same thing happen when playing to the ALSA dummy device on AT91 ?

> I have added some printfs to the following lib function (src/pcm.c):
> 
> 
> int snd_pcm_hw_params_get_period_size(const snd_pcm_hw_params_t
> *params, snd_pcm_uframes_t *val, int *dir)
> {
>        unsigned long _val;
> 
>        printf("get_period_size() %lu %lu %08x %08x %08x \n", _val,
> *val, val, dir, params );
> 
>        int err = snd_pcm_hw_param_get(params, SND_PCM_HW_PARAM_PERIOD_SIZE,
> &_val, NULL);
>        if (err >= 0)
>                *val = _val;
> 
>        printf("get_period_size() %lu %lu %08x %08x %08x %d\n", _val,
> *val, val, dir, params, err );
> 
>        return err;
> }
> 
> 
> as well as to the program that calls the lib function (test/pcm.c):
> 
> 
>        printf("period_size=%lu %08x dir=%d %08x params %08x \n",
> size, &size, dir, &dir, params);
>        err = snd_pcm_hw_params_get_period_size(params, &size, NULL);
>        if (err < 0) {
>                printf("Unable to get period size for playback: %s\n",
> snd_strerror(err));
>                return err;
>        }
>        period_size = size;
>        printf("period_size=%lu %08x dir=%d %08x params %08x \n",
> size, &size, dir, &dir, params);
> 
> 
> When I run the program I get the following output
> 
> # pcm
> Playback device is plughw:0,0

It's best to change this to hw:0,0 to help rule out any AT91 driver
issues. 

> Stream parameters are 44100Hz, S16_LE, 1 channels
> Sine wave rate is 440.0000Hz
> Using transfer method: write
> period_size=49572 bec48954 dir=0 bec48950 params bec489e4
> get_period_size() 1073758756 3200551252 bec48924 bec48954 bec489e4
> get_period_size() 1248 1248  bec48924 bec48954 bec489e4 0
> period_size=49572 bec48954 dir=0 bec48950 params bec489e4
> 
> which shows that the pointers to 'params' is ok but that the pointer
> to 'val' is incorrect (bec48924 instead of bec48954) and the pointer
> to 'dir' is also wrong (bec48954 instead of  bec48950 = the pointer to
> val).
> 
> What could be the cause of this kind of error?  Somehow the arguments
> passed to  snd_pcm_hw_params_get_period_size() are getting mangled.
> 
> I have tried removing all optimisations, using other versions of gcc
> (4.0.4 and 3.4.6) and using EABI instead of OABI.  I always get the
> same result.
> 
> Any tips on how I can proceed in debugging this problem?
> 
> Are there any compiler or linker flags that could be responsible ?
> 

Did you build any of the toolchains with OE ? I've not had any audio gcc
problems on ARM with OE toolchains since the cse bug.

Liam 

Re: alsa on Atmel at91

[Michel Benoit]

After digging through the assembler files it seems that for some
reason a function  called
__old_snd_pcm_hw_params_get_period_size that uses another procedure
calling standard is used.


Here is the code in libasound:

.symver __snd_pcm_hw_params_get_period_size,snd_pcm_hw_params_get_period_size@@ALSA_0.9.0rc4
	.symver __old_snd_pcm_hw_params_get_period_size,snd_pcm_hw_params_get_period_size@ALSA_0.9

	.align	2
	.global	__snd_pcm_hw_params_get_period_size
	.type	__snd_pcm_hw_params_get_period_size, %function
__snd_pcm_hw_params_get_period_size:
	@ args = 0, pretend = 0, frame = 4
	@ frame_needed = 0, uses_anonymous_args = 0
	stmfd	sp!, {r4, lr}
	sub	sp, sp, #4
	mov	r3, r2
	mov	r4, r1
	mov	r2, sp
	mov	r1, #13
	bl	snd_pcm_hw_param_get(PLT)
	cmp	r0, #0
	ldrge	r3, [sp, #0]
	strge	r3, [r4, #0]
	add	sp, sp, #4
	ldmfd	sp!, {r4, pc}
	.size	__snd_pcm_hw_params_get_period_size,
.-__snd_pcm_hw_params_get_period_size
	.align	2
	.global	__old_snd_pcm_hw_params_get_period_size
	.type	__old_snd_pcm_hw_params_get_period_size, %function
__old_snd_pcm_hw_params_get_period_size:
	@ args = 0, pretend = 0, frame = 4
	@ frame_needed = 0, uses_anonymous_args = 0
	str	lr, [sp, #-4]!
	sub	sp, sp, #4
	mov	r2, r1
	mov	r1, sp
	bl	__snd_pcm_hw_params_get_period_size(PLT)
	mov	r3, #0
	cmp	r0, r3
	ldrge	r3, [sp, #0]
	mov	r0, r3
	add	sp, sp, #4
	ldmfd	sp!, {pc}
	.size	__old_snd_pcm_hw_params_get_period_size,
.-__old_snd_pcm_hw_params_get_period_size

	
And here is the code that calls the lib function:

       sub     r3, fp, #28
       sub     r2, fp, #32
       ldr     r0, [fp, #-40]
       mov     r1, r3
       bl      snd_pcm_hw_params_get_period_size
       mov     r3, r0
       str     r3, [fp, #-20]


Clearly if __old_snd_pwm_hw_params_get_period_size() is called then
'dir' gets 'val's address and the 'val' is some irrelevant data from
the stack.  Calling __snd_pwm_hw_params_get_period_size() directly
should work.

What is __old_snd_pwm_hw_params_get_period_size()  and how do I get rid of it?
What does @ALSA_0.9 mean?

Michel

Re: alsa on Atmel at91

[Michel Benoit]

After reading up on .symvers it seems that there is a version number
used to select which function to link against.

If I look in the file src/Versions it seems that there is no
definition for ALSA_1.0.13.  Could this be the problem?  I'm still
trying to figure out how and where the version ALSA_X.X.X is passed in
to the linker.

Michel

Re: alsa on Atmel at91

[Michel Benoit]

> After reading up on .symvers it seems that there is a version number
> used to select which function to link against.
>
> If I look in the file src/Versions it seems that there is no
> definition for ALSA_1.0.13.  Could this be the problem?  I'm still
> trying to figure out how and where the version ALSA_X.X.X is passed in
> to the linker.

More research reveals that the symbol defined with @@ is the default
symbol taht is used when no version is given.  In my case the symbols
defined in pcm.c are:

.symver __snd_pcm_hw_params_get_period_size,snd_pcm_hw_params_get_period_size@@ALSA_0.9.0rc4
.symver __old_snd_pcm_hw_params_get_period_size,snd_pcm_hw_params_get_period_size@ALSA_0.9


and the __old version of the function should only be called if version
ALSA_0.9 is explicitely set by the app or somehow the default version
is being disabled or ignored.

Does anyone know how an application defines which version of symbols
it wants to use from a library?

Is there a way to disable symbol versioning in a lib?

Is any of this done explicitely as part of the alsa-lib and alsa-utils
build procedures?

Michel

Re: alsa on Atmel at91

[Michel Benoit]

For anyone who has been following this thread, setting the configure
option "with-versioned=no" for alsa-lib solves the problem.

I still don't understand why the wrong version of the symbols was
being used but that is irrelevant on our embedded system.

Re: alsa on Atmel at91

[Frank Mandarino]

Michel Benoit wrote:
> For anyone who has been following this thread, setting the configure
> option "with-versioned=no" for alsa-lib solves the problem.
> 
> I still don't understand why the wrong version of the symbols was
> being used but that is irrelevant on our embedded system.

Michel,

It works!  Well done.  Until now I have had to statically link aplay to
get it to work.  Linking dynamically saves me 1.5MB of precious NAND
filesystem space.

Thanks for your determined effort for solve this.

Regards,
../fam
-- 
Frank Mandarino                                fmandarino(a)endrelia.com
Endrelia Technologies Inc.
Toronto, Ontario, Canada

Re: alsa on Atmel at91

[Matthieu CASTET]

Hi,

Michel Benoit <murpme <at> gmail.com> writes:

> 
> For anyone who has been following this thread, setting the configure
> option "with-versioned=no" for alsa-lib solves the problem.
> 
> I still don't understand why the wrong version of the symbols was
> being used but that is irrelevant on our embedded system.
> 

I hit the same problem (arm EABI platform), and "with-versioned=no" solve it.

Is there plan to investigate on this


Matthieu

Re: alsa on Atmel at91

[Takashi Iwai]

At Mon, 11 Jun 2007 09:58:26 +0000 (UTC),
Matthieu CASTET wrote:
> 
> Hi,
> 
> Michel Benoit <murpme <at> gmail.com> writes:
> 
> > 
> > For anyone who has been following this thread, setting the configure
> > option "with-versioned=no" for alsa-lib solves the problem.
> > 
> > I still don't understand why the wrong version of the symbols was
> > being used but that is irrelevant on our embedded system.
> > 
> 
> I hit the same problem (arm EABI platform), and "with-versioned=no" solve it.
> 
> Is there plan to investigate on this

No plan but patches will be appreciated :)

Since the same versioned symbol works for other architectures, it can
be an ARM-specific issue...


Takashi