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. Basically all I have done is remove the spi communication with the AT73C213 that regulates the sound output volume. The PCM chip has no such volume control and I use the i2s interface setup as is to send sample data.
I cross compile alsa lib and run the program test/pcm_min which generates as expected random noise on the speaker output. However when I try to run test/pcm I get a divide by zero floating point exception because the library returns a period_size of 0. This despite the fact that the period time is set to 100000 and buffer time is set to 500000. I enabled some debug info in the library and I see the following data dumped to the console.
ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: (20354 20355) PERIOD_SIZE: 977 PERIOD_BYTES: 3908 PERIODS: (4 5) BUFFER_TIME: (81479 81480) BUFFER_SIZE: 3911 BUFFER_BYTES: 15644 TICK_TIME: 10000
How is it possible that the following code from test/pcm.c
err = snd_pcm_hw_params_set_period_time_near(handle, params, &period_time, &dir); if (err < 0) { printf("Unable to set period time %i for playback: %s\n", period_time, snd_strerror(err)); return err; } err = snd_pcm_hw_params_get_period_size(params, &size, &dir); if (err < 0) { printf("Unable to get period size for playback: %s\n", snd_strerror(err)); return err; }
returns a period_size of 0 when the debug output shows that the period_size has been calculated to be 977?
Can it be that the driver has not initialised the alsa structures properly (the driver file is attached to this email)? Have I mucked something up by removing the spi comm. with the at73c213?
Could this be due to a problem in the cross compilation of alsa-lib? I use the following configure command line:
CC=arm-linux-gcc ./configure \ --host=arm-linux\ --prefix=$HOME/bsp/rootfs/buildroot/build_arm/root/usr\ --with-softfloat
(note: I have also tried it without --with-softfloat)
I have tried digging through the alsa lib code but it is not very clear to me where the returned value for period_size comes from. I appreciate any pointers, hints or tips that can help me to solve and/or understand this problem.
Thanks in advance!
Michel
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
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?
Thanks,
Michel
On 4/16/07, Liam Girdwood lg@opensource.wolfsonmicro.com wrote:
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
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.).
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?
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?
Thanks again for the assistance.
Michel
On 4/17/07, Liam Girdwood lg@opensource.wolfsonmicro.com wrote:
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
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.
I start to suspect that I have a problem with alsa lib. How did you cross compile alsa lib för the at91?
Michel
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:-
OE has the bug fix for the above gcc bug in it's toolchain.
Liam
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?
What gcc version are you using? 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
Michel
On 4/18/07, Liam Girdwood lg@opensource.wolfsonmicro.com wrote:
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:-
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
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.
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.
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]
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 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
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
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
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 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
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
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
-
Frank Mandarino -
Liam Girdwood -
Matthieu CASTET -
Michel Benoit -
Takashi Iwai