On Sun, 2007-04-15 at 21:38 +0200, Michel Benoit wrote:

Hello

I am trying to run alsa on an ARM based target AT91SAM9260 based board. The cpu is connected over i2s (atmel's ssc) to a PCM1725 chip. I modifed the AT73C213 driver available in the latest experimental patches from www.at91.com to behave correctly for the PCM1725 chip.

You may be interested in the AT91xxxx support in alsa-kernel Hg (sound/soc/at91). It currently supports the AT91xxxx audio DMA and ssc controller for I2S audio. All that is probably needed for you machine is a driver for your codec and some glue code.

HTH

Liam

On Tue, 2007-04-17 at 14:03 +0200, Michel Benoit wrote:

Hi Liam

Yes of course, I am very interested in getting my hands on a working driver for the at91 ssc controller. Where can I get a copy of the at91-ssc code?

The easiest way to get a copy is to clone the alsa-kernel Hg repository here :-

http://hg-mirror.alsa-project.org/alsa-kernel

Instructions for cloning can be found here :-

http://alsa-project.org/download.php

Liam

On Tue, 2007-04-17 at 17:57 +0200, Michel Benoit wrote:

Thanks. I got the code, included all the ASoc stuff in my local tree and rebuilt the kernel. If i understand the docs correctly I have to write a codec driver for my audio chip and some machine code to set up the particulars for my board (clocks, io pins etc.).

Your correct, you will need a codec driver and a machine driver to glue the codec to the AT91 SSC and do any machine specific config.

Fwiw, all the development is done here on the dev branch:-

http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-aso...

Am I missing something?

The codec we use has no control functions (no i2c/spi comm) it simply plays back the samples it reads on the i2s bus. This should thus translate to a simple codec driver. Is there a codec driver that uses i2s on the at91 that I can use as a base for my driver?

Frank has written a codec driver for a dumb BT codec (attached and link below). This could be renamed and with a little string changes could be used as a generic dumb codec driver.

http://opensource.wolfsonmicro.com/~lg/tmp/asoc-codec-bluecore.patch

I haven't really understood yet how to include the machine code. Should this be done in the same way as the other platform drivers in arch/arm/mach-at91rm9200/board-xxx.c? Is there some sample code that I can use as a model?

I would use the eti_b1_wm8731.c as an example machine driver for your board. You will need to replace any WM8731 references and add your boards own specific clocks, gpio's etc.

Liam

On Wed, 2007-04-18 at 11:18 +0200, Michel Benoit wrote:

Hello again Liam,

...

Frank has written a codec driver for a dumb BT codec (attached and link below). This could be renamed and with a little string changes could be used as a generic dumb codec driver.

http://opensource.wolfsonmicro.com/~lg/tmp/asoc-codec-bluecore.patch

...

I would use the eti_b1_wm8731.c as an example machine driver for your board. You will need to replace any WM8731 references and add your boards own specific clocks, gpio's etc.

I am able to build a soc driver for my hardware using the bluecore codec driver and et1_b1_wm8731 machine code as examples.

The driver gets recognized by alsa at startup. The ssc registers are set correctly but my original problem still remains. I can play random noise with test/pcm_min but with test/pcm the alsa lib returns a period_size of 0, despite the fact I set period_time to 100000.

This maybe related to an ARM gcc bug :-

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363

I start to suspect that I have a problem with alsa lib. How did you cross compile alsa lib för the at91?

I use OpenEmbedded for all my cross compiling:-

http://www.openembedded.org/

OE has the bug fix for the above gcc bug in it's toolchain.

Liam

On Wed, 2007-04-18 at 14:00 +0200, Michel Benoit wrote:

I'm using gcc 4.1.2 built with buildroot to cross compile alsa lib. I've tried it with -O1 as reccomended in the gcc bug discussion but I see a similar behaviour. Now it does not give a

I've turned on debug messages in alsa lib which shows the following

cchange 'default' refine_soft 'default' refine_soft 'default' (begin) ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: (42666 42667) PERIOD_SIZE: 2048 PERIOD_BYTES: 8192 PERIODS: 4 BUFFER_TIME: (170666 170667) BUFFER_SIZE: 8192 BUFFER_BYTES: 32768 TICK_TIME: 10000 refine_soft ok 'default' refine_slave - leave 'default' ********** was set period_size = 0 ********** was set buffer_size = 0

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.

What gcc version are you using?

4.1.1

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...

Btw, have you tried any other tests or aplay ?

What about aplay -Dhw:0.0 file.wav (this should rule out missing conf files that buildroot has not installed)

Liam

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...

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.

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

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

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.

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