_From a printk in the soc driver:

SNDRV_CTL_IOCTL_ELEM_READ is 0xc2c85512

Is that correct?

On 5/11/07, Takashi Iwai tiwai@suse.de wrote:

At Fri, 11 May 2007 12:36:01 +0200, Michel Benoit wrote:

...

Hello

Now that I have my pcm playback working with aplay with our at91 aSoc sound driver I would like to control the volume with softvol.

I followed the instructions from http://alsa.opensrc.org/How_to_use_softvol_to_control_the_master_volume and I have the following asound.con file in /etc

pcm.!default { type plug slave.pcm "softvol" }

pcm.softvol { type softvol slave { pcm "plughw:0,0" } control { name "PCM volume" card 0 } }

When I play a wav file directly to the device it works fine:

# aplay -Dplughw:0,0 Front_Center.wav Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

but when I try to use the default softvol device I get the following output (and no sound):

# aplay Front_Center.wav Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono ALSA sound/core/control.c:1244: unknown ioctl = 0xc2c45512 ALSA sound/core/control.c:1244: unknown ioctl = 0xc2c45512 ALSA sound/core/control.c:1244: unknown ioctl = 0xc2c45512 ALSA sound/core/control.c:1244: unknown ioctl = 0xc2c45512 ALSA sound/core/control.c:1244: unknown ioctl = 0xc2c45512 ...

Does anyone have any ideas as to why this is happening?

This should be SNDRV_CTL_IOCTL_ELEM_READ.

Could you check which number this ioctl is in the kernel code? e.g. try printk("0x%x\n", SNDRV_CTL_IOCTL_ELEM_READ) in kernel and in alsa-lib, too.

Takashi

...

...

From a printk in the soc driver:

SNDRV_CTL_IOCTL_ELEM_READ is 0xc2c85512

Is that correct?

Right, it means that the struct is aligned differently on between user- and kernel-spaces.

Could check the offset of each field, such as

    printk("id = %d\n", offsetof(struct snd_ctl_elem_value, id));
    printk("value = %d\n", offsetof(struct snd_ctl_elem_value, value));
    printk("tstamp = %d\n", offsetof(struct snd_ctl_elem_value, tstamp));
    printk("reserved = %d\n", offsetof(struct snd_ctl_elem_value, reserved));

for both kernel and user-spaces? I guess either it's a difference of pointer alignment or time_spec definition.

The output from printk("0x%x\n", SNDRV_CTL_IOCTL_ELEM_READ); printk("id = %d\n", offsetof(struct snd_ctl_elem_value, id)); printk("value = %d\n", offsetof(struct snd_ctl_elem_value, value)); printk("tstamp = %d\n", offsetof(struct snd_ctl_elem_value, tstamp)); printk("reserved = %d\n", offsetof(struct snd_ctl_elem_value, reserved));

in the kernel driver is

0xc2c85512 id = 0 value = 72 tstamp = 584 reserved = 592

and in the pcm test program the ouput of printk("0x%x\n", SNDRV_CTL_IOCTL_ELEM_READ); is

0xc2c45512

What is the difference? Which version of alsa is used/expected in the kernel?

At Tue, 15 May 2007 09:35:57 +0200, Michel Benoit wrote:

FYI, I rebuilt alsa-lib, alsa-utils and the kernel from scratch with buildroot using OABI instead of EABI and softvol works fine now. Thanks for your help.

It seems that my kernel was built using EABI but that my userspace was being built with OABI.

Good to hear :)

The problem was that the struct size was different between the definition in the kernel side and in the user side. This caused a mismatch of ioctl number.

Takashi