[Buildroot] alsa lib problem

[Buildroot] alsa lib problem

[Will Wagner]

Hi All,

I have alsa-lib compiling for my arm target however aplay fails to work with the kernel 
reporting:

ALSA sound/core/pcm_native.c:2587: unknown ioctl = 0x80184132

Decoding this ioctl it is SNDRV_PCM_IOCTL_CHANNEL_INFO defined in asound.h.

The reason it is not working is that the kernel and alsa-lib think that the 
sndrv_pcm_channel_info struct is different sizes.

The definition in asound.h is:

struct sndrv_pcm_channel_info {
	unsigned int channel;
	off_t offset;			/* mmap offset */
	unsigned int first;		/* offset to first sample in bits */
	unsigned int step;		/* samples distance in bits */
};

The problem is that when compiling linux it thinks off_t is 4 bytes but it appears that 
when compiling alsa-lib it thought it was 8 bytes. I assume this is because something in 
the toolchain on the host PC or the alsa-lib build is wrong and it is picking up a define 
from outside buildroot.

Does this sound possible? How do I establish which definition it is using?

Thanks,

Will.
-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] alsa lib problem

[Peter Korsgaard]

>>>>> "Will" == Will Wagner <will_wagner@carallon.com> writes:

Hi,

 Will> The definition in asound.h is:

 Will> struct sndrv_pcm_channel_info {
 Will> 	unsigned int channel;
 Will> 	off_t offset;			/* mmap offset */
 Will> 	unsigned int first;		/* offset to first sample in bits */
 Will> 	unsigned int step;		/* samples distance in bits */
 Will> };

 Will> The problem is that when compiling linux it thinks off_t is 4
 Will> bytes but it appears that when compiling alsa-lib it thought it
 Will> was 8 bytes. I assume this is because something in the
 Will> toolchain on the host PC or the alsa-lib build is wrong and it
 Will> is picking up a define from outside buildroot.

It looks to me like a largefile problem, E.G:

cat test.c
#include <stdio.h>
#include <sys/types.h>
int main(int argc, char **argv)
{
  printf("%d\n", sizeof(off_t));
  return 0;
}
arm-linux-gcc -static -o test test.c && qemu-arm ./test
4

arm-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -static -o test test.c && qemu-arm ./test
8

We unconditinally add the largefile stuff to TARGET_CFLAGS, which
apparently isn't a good idea for alsa.

If the kernel interface is always with an 32bit offset, then asound.h
should probably be changed to use a 32bit data type instead. Could you
try changing it to an unsigned int and recompile?

-- 
Bye, Peter Korsgaard

[Buildroot] alsa lib problem

[Will Wagner]

Peter Korsgaard wrote:
> 
> We unconditinally add the largefile stuff to TARGET_CFLAGS, which
> apparently isn't a good idea for alsa.
> 
> If the kernel interface is always with an 32bit offset, then asound.h
> should probably be changed to use a 32bit data type instead. Could you
> try changing it to an unsigned int and recompile?

Yes is I change the asound.h header it does work.

What is the best way to proceed from here? Just patch alsa?

Thanks for your help,

Will.

> 

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] alsa lib problem

[Hans-Christian Egtvedt]

On Tue, 27 Jan 2009 12:32:28 +0000
Will Wagner <will_wagner@carallon.com> wrote:

> Peter Korsgaard wrote:
> > 
> > We unconditinally add the largefile stuff to TARGET_CFLAGS, which
> > apparently isn't a good idea for alsa.
> > 
> > If the kernel interface is always with an 32bit offset, then
> > asound.h should probably be changed to use a 32bit data type
> > instead. Could you try changing it to an unsigned int and recompile?
> 
> Yes is I change the asound.h header it does work.
> 
> What is the best way to proceed from here? Just patch alsa?
> 

Make a patch for alsa, and send it upstream to the alsa maintainers.
They need to fix broken code like this anyway.

<snipp>

-- 
Best regards,
Hans-Christian Egtvedt

[Buildroot] alsa lib problem

[Will Wagner]

Hans-Christian Egtvedt wrote:
> On Tue, 27 Jan 2009 12:32:28 +0000
> Will Wagner <will_wagner@carallon.com> wrote:
> 
>> Peter Korsgaard wrote:
>>> We unconditinally add the largefile stuff to TARGET_CFLAGS, which
>>> apparently isn't a good idea for alsa.
>>>
>>> If the kernel interface is always with an 32bit offset, then
>>> asound.h should probably be changed to use a 32bit data type
>>> instead. Could you try changing it to an unsigned int and recompile?
>> Yes is I change the asound.h header it does work.
>>
>> What is the best way to proceed from here? Just patch alsa?
>>
> 
> Make a patch for alsa, and send it upstream to the alsa maintainers.
> They need to fix broken code like this anyway.

Happy to prepare a patch for upstream. However can someone explain to me what is broken in 
alsa? Looking at the code the declaration of the struct is identical in the kernel code 
and the copy of the header in alsa. How is it that the size of off_t is different?

Thanks,

Will.

> 
> <snipp>
> 

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] alsa lib problem

[Peter Korsgaard]

>>>>> "Will" == Will Wagner <will_wagner@carallon.com> writes:

 >> Make a patch for alsa, and send it upstream to the alsa maintainers.
 >> They need to fix broken code like this anyway.

 Will> Happy to prepare a patch for upstream. However can someone explain to
 Will> me what is broken in alsa? Looking at the code the declaration of the
 Will> struct is identical in the kernel code and the copy of the header in
 Will> alsa. How is it that the size of off_t is different?

Without largefile enabled off_t is a 32bit type (on 32bit archs), but
with largefile enabled it's a 64bit type. The kernel only accepts a
32bit type, so things break.

Looking closer at it, off_t in the kernel is a typedef of
__kernel_off_t, which seems to be a long on all archs.

In other words, the fix seems to be a simple s/off_t/long/

You are welcome to CC me on the mail to the alsa list.

-- 
Bye, Peter Korsgaard

[Buildroot] alsa lib problem

[Peter Korsgaard]

>>>>> "Will" == Will Wagner <will_wagner@carallon.com> writes:

Hi,

 >> If the kernel interface is always with an 32bit offset, then asound.h
 >> should probably be changed to use a 32bit data type instead. Could you
 >> try changing it to an unsigned int and recompile?

 Will> Yes is I change the asound.h header it does work.

Great.

 Will> What is the best way to proceed from here? Just patch alsa?

Well, I would bring the issue up on the alsa list so we can get a real
fix upstream, but we could carry a patch in BR for now.

I'll whip one up shortly.

-- 
Bye, Peter Korsgaard

[Buildroot] alsa lib problem

[Peter Korsgaard]

>>>>> "Will" == Will Wagner <will_wagner@carallon.com> writes:

 >> If the kernel interface is always with an 32bit offset, then asound.h
 >> should probably be changed to use a 32bit data type instead. Could you
 >> try changing it to an unsigned int and recompile?

 Will> Yes is I change the asound.h header it does work.

 Will> What is the best way to proceed from here? Just patch alsa?

Yes, I checked in the patch Takashi Iwai committed to alsa-lib.git as
r25101.

Thanks.

-- 
Bye, Peter Korsgaard