April 2009 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Asterisk 1.4.17 and alsa 1.0.19 dmix plugin problem.
by Nicola Mfb 21 Apr '09

21 Apr '09

Hi! I'm sorry if this is an old issue but I did not found help in archives/alsaweb/google and I'm new to alsa, so this report is what I guessed reading sources and compiling test apps for about 2 days, and the following assumptions may be completely wrong. Asterisk has an alsa channel that works fine when using plughw:0,0 both for read and for writing, but if use plug:dmix/plug:dsnoop or default with a dmix/dsnoop wrapper in /etc/asound.conf it does not emit any sound. It uses select on poll fd descriptor to know if the pcm is ready to be sent output samples. The select will never return as it seems the dmix plugin is not able to signal when is ready. I noted that using snd_pcm_wait works well but cannot be used in asterisk as it needs to select on two fd. I guess that snd_pcm_wait with dmix check the shared memory and not the fd descriptor. So should poll/select be avoided completely in applications (as they does not know if the default pcm is a dmix) and asterisk alsa channel be rewritten or is there a workaround? Best Regards Nicola

2 5

Re: [alsa-devel] Cirrus Logic CS4207
by Takashi Iwai 21 Apr '09

21 Apr '09

At Tue, 21 Apr 2009 09:24:31 +0200, Peter-Jan Deweirdt wrote: > > Hi, > > This is the patch that I've changed to the 2.6.29 kernel. However I > need some more help for playing the audio. Since I don't really know > what is happening. > > It's detecting my audio chip. (a part of dmesg) > [ 5.171478] Advanced Linux Sound Architecture Driver Version 1.0.18a. > [ 5.176635] HDA Intel 0000:00:1b.0: setting latency timer to 64 > [ 5.220417] ALSA device list: > [ 5.220434] #0: HDA Intel MID at 0xd0010000 irq 22 > > So it looks like my audio card is found. Some more outputs > > lspci -v > 00:1b.0 Audio device: Intel Corporation System Controller Hub (SCH > Poulsbo) HD Audio Controller (rev 06) > Subsystem: Intel Corporation Unknown device 8119 > Flags: bus master, fast devsel, latency 0, IRQ 22 > Memory at d0010000 (64-bit, non-prefetchable) [size=16K] > Capabilities: [50] Power Management version 2 > Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 > Kernel driver in use: HDA Intel > > > [root@localhost ~]# cat /proc/asound/cards > 0 [MID ]: HDA-Intel - HDA Intel MID > HDA Intel MID at 0xd0010000 irq 22 > [root@localhost ~]# > > [root@localhost ~]# aplay -l > **** List of PLAYBACK Hardware Devices **** > card 0: MID [HDA Intel MID], device 0: CS4207 Analog [CS4207 Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: MID [HDA Intel MID], device 1: CS4207 Digital [CS4207 Digital] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > [root@localhost ~]# > > > [root@localhost ~]# aplay -L > front:CARD=MID,DEV=0 > HDA Intel MID, CS4207 Analog > Front speakers > surround40:CARD=MID,DEV=0 > HDA Intel MID, CS4207 Analog > 4.0 Surround output to Front and Rear speakers > surround41:CARD=MID,DEV=0 > HDA Intel MID, CS4207 Analog > 4.1 Surround output to Front, Rear and Subwoofer speakers > surround50:CARD=MID,DEV=0 > HDA Intel MID, CS4207 Analog > 5.0 Surround output to Front, Center and Rear speakers > surround51:CARD=MID,DEV=0 > HDA Intel MID, CS4207 Analog > 5.1 Surround output to Front, Center, Rear and Subwoofer speakers > surround71:CARD=MID,DEV=0 > HDA Intel MID, CS4207 Analog > 7.1 Surround output to Front, Center, Side, Rear and Woofer > speakers > iec958:CARD=MID,DEV=0 > HDA Intel MID, CS4207 Digital > IEC958 (S/PDIF) Digital Audio Output > null > Discard all samples (playback) or generate zero samples (capture) > pulse > PulseAudio Sound Server > default > Default > [root@localhost ~]# > > [root@localhost ~]# ls -al /dev/snd/ > total 0 > drwxr-xr-x 2 root root 200 Mar 24 20:00 . > drwxr-xr-x 15 root root 3360 Mar 24 20:00 .. > crw-rw---- 1 root audio 116, 9 Mar 24 20:00 controlC0 > crw-rw---- 1 root audio 116, 8 Mar 24 20:00 hwC0D0 > crw-rw---- 1 root audio 116, 7 Mar 24 20:00 pcmC0D0c > crw-rw---- 1 root audio 116, 6 Mar 24 20:58 pcmC0D0p > crw-rw---- 1 root audio 116, 5 Mar 24 20:00 pcmC0D1c > crw-rw---- 1 root audio 116, 4 Mar 24 20:30 pcmC0D1p > crw-rw---- 1 root audio 116, 3 Mar 24 20:00 seq > crw-rw---- 1 root audio 116, 2 Mar 24 20:00 timer > [root@localhost ~]# All look good, so far. > The problems that I'm having is: > - How to play audio? % aplay foo.wav > - I am seeing 2 playback devices (what is correct) but no headphones The streams are just for analog and digital outputs. The analog outputs are switched either by the automatic HP jack detection or manual switch (if any). > - How can I see the difference between the MIC in and LINE IN? Via mixer controls. Takashi

2 3

[alsa-devel] [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
by Jean Delvare 21 Apr '09

21 Apr '09

The legacy i2c binding model is going away soon, so convert the AOA codec drivers to the new model or they'll break. Signed-off-by: Jean Delvare <khali(a)linux-fr.org> Tested-by: Johannes Berg <johannes(a)sipsolutions.net> Tested-by: Andreas Schwab <schwab(a)linux-m68k.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: Takashi Iwai <tiwai(a)suse.de> --- Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. sound/aoa/codecs/onyx.c | 76 ++++++++++++++++++++++++++++++++--------------- sound/aoa/codecs/tas.c | 66 +++++++++++++++++++++++++--------------- 2 files changed, 95 insertions(+), 47 deletions(-) --- linux-2.6.30-rc2.orig/sound/aoa/codecs/onyx.c 2009-04-15 09:55:20.000000000 +0200 +++ linux-2.6.30-rc2/sound/aoa/codecs/onyx.c 2009-04-15 14:07:50.000000000 +0200 @@ -47,7 +47,7 @@ MODULE_DESCRIPTION("pcm3052 (onyx) codec struct onyx { /* cache registers 65 to 80, they are write-only! */ u8 cache[16]; - struct i2c_client i2c; + struct i2c_client *i2c; struct aoa_codec codec; u32 initialised:1, spdif_locked:1, @@ -72,7 +72,7 @@ static int onyx_read_register(struct ony *value = onyx->cache[reg-FIRSTREGISTER]; return 0; } - v = i2c_smbus_read_byte_data(&onyx->i2c, reg); + v = i2c_smbus_read_byte_data(onyx->i2c, reg); if (v < 0) return -1; *value = (u8)v; @@ -84,7 +84,7 @@ static int onyx_write_register(struct on { int result; - result = i2c_smbus_write_byte_data(&onyx->i2c, reg, value); + result = i2c_smbus_write_byte_data(onyx->i2c, reg, value); if (!result) onyx->cache[reg-FIRSTREGISTER] = value; return result; @@ -996,12 +996,45 @@ static void onyx_exit_codec(struct aoa_c onyx->codec.soundbus_dev->detach_codec(onyx->codec.soundbus_dev, onyx); } -static struct i2c_driver onyx_driver; - static int onyx_create(struct i2c_adapter *adapter, struct device_node *node, int addr) { + struct i2c_board_info info; + struct i2c_client *client; + + memset(&info, 0, sizeof(struct i2c_board_info)); + strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE); + info.addr = addr; + info.platform_data = node; + client = i2c_new_device(adapter, &info); + if (!client) + return -ENODEV; + + /* + * We know the driver is already loaded, so the device should be + * already bound. If not it means binding failed, which suggests + * the device doesn't really exist and should be deleted. + * Ideally this would be replaced by better checks _before_ + * instantiating the device. + */ + if (!client->driver) { + i2c_unregister_device(client); + return -ENODEV; + } + + /* + * Let i2c-core delete that device on driver removal. + * This is safe because i2c-core holds the core_lock mutex for us. + */ + list_add_tail(&client->detected, &client->driver->clients); + return 0; +} + +static int onyx_i2c_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct device_node *node = client->dev.platform_data; struct onyx *onyx; u8 dummy; @@ -1011,20 +1044,12 @@ static int onyx_create(struct i2c_adapte return -ENOMEM; mutex_init(&onyx->mutex); - onyx->i2c.driver = &onyx_driver; - onyx->i2c.adapter = adapter; - onyx->i2c.addr = addr & 0x7f; - strlcpy(onyx->i2c.name, "onyx audio codec", I2C_NAME_SIZE); - - if (i2c_attach_client(&onyx->i2c)) { - printk(KERN_ERR PFX "failed to attach to i2c\n"); - goto fail; - } + onyx->i2c = client; + i2c_set_clientdata(client, onyx); /* we try to read from register ONYX_REG_CONTROL * to check if the codec is present */ if (onyx_read_register(onyx, ONYX_REG_CONTROL, &dummy) != 0) { - i2c_detach_client(&onyx->i2c); printk(KERN_ERR PFX "failed to read control register\n"); goto fail; } @@ -1036,14 +1061,14 @@ static int onyx_create(struct i2c_adapte onyx->codec.node = of_node_get(node); if (aoa_codec_register(&onyx->codec)) { - i2c_detach_client(&onyx->i2c); goto fail; } printk(KERN_DEBUG PFX "created and attached onyx instance\n"); return 0; fail: + i2c_set_clientdata(client, NULL); kfree(onyx); - return -EINVAL; + return -ENODEV; } static int onyx_i2c_attach(struct i2c_adapter *adapter) @@ -1080,28 +1105,33 @@ static int onyx_i2c_attach(struct i2c_ad return onyx_create(adapter, NULL, 0x47); } -static int onyx_i2c_detach(struct i2c_client *client) +static int onyx_i2c_remove(struct i2c_client *client) { - struct onyx *onyx = container_of(client, struct onyx, i2c); - int err; + struct onyx *onyx = i2c_get_clientdata(client); - if ((err = i2c_detach_client(client))) - return err; aoa_codec_unregister(&onyx->codec); of_node_put(onyx->codec.node); if (onyx->codec_info) kfree(onyx->codec_info); + i2c_set_clientdata(client, onyx); kfree(onyx); return 0; } +static const struct i2c_device_id onyx_i2c_id[] = { + { "aoa_codec_onyx", 0 }, + { } +}; + static struct i2c_driver onyx_driver = { .driver = { .name = "aoa_codec_onyx", .owner = THIS_MODULE, }, .attach_adapter = onyx_i2c_attach, - .detach_client = onyx_i2c_detach, + .probe = onyx_i2c_probe, + .remove = onyx_i2c_remove, + .id_table = onyx_i2c_id, }; static int __init onyx_init(void) --- linux-2.6.30-rc2.orig/sound/aoa/codecs/tas.c 2009-04-15 09:55:20.000000000 +0200 +++ linux-2.6.30-rc2/sound/aoa/codecs/tas.c 2009-04-15 09:56:39.000000000 +0200 @@ -82,7 +82,7 @@ MODULE_DESCRIPTION("tas codec driver for struct tas { struct aoa_codec codec; - struct i2c_client i2c; + struct i2c_client *i2c; u32 mute_l:1, mute_r:1 , controls_created:1 , drc_enabled:1, @@ -108,9 +108,9 @@ static struct tas *codec_to_tas(struct a static inline int tas_write_reg(struct tas *tas, u8 reg, u8 len, u8 *data) { if (len == 1) - return i2c_smbus_write_byte_data(&tas->i2c, reg, *data); + return i2c_smbus_write_byte_data(tas->i2c, reg, *data); else - return i2c_smbus_write_i2c_block_data(&tas->i2c, reg, len, data); + return i2c_smbus_write_i2c_block_data(tas->i2c, reg, len, data); } static void tas3004_set_drc(struct tas *tas) @@ -882,12 +882,34 @@ static void tas_exit_codec(struct aoa_co } -static struct i2c_driver tas_driver; - static int tas_create(struct i2c_adapter *adapter, struct device_node *node, int addr) { + struct i2c_board_info info; + struct i2c_client *client; + + memset(&info, 0, sizeof(struct i2c_board_info)); + strlcpy(info.type, "aoa_codec_tas", I2C_NAME_SIZE); + info.addr = addr; + info.platform_data = node; + + client = i2c_new_device(adapter, &info); + if (!client) + return -ENODEV; + + /* + * Let i2c-core delete that device on driver removal. + * This is safe because i2c-core holds the core_lock mutex for us. + */ + list_add_tail(&client->detected, &client->driver->clients); + return 0; +} + +static int tas_i2c_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct device_node *node = client->dev.platform_data; struct tas *tas; tas = kzalloc(sizeof(struct tas), GFP_KERNEL); @@ -896,17 +918,11 @@ static int tas_create(struct i2c_adapter return -ENOMEM; mutex_init(&tas->mtx); - tas->i2c.driver = &tas_driver; - tas->i2c.adapter = adapter; - tas->i2c.addr = addr; + tas->i2c = client; + i2c_set_clientdata(client, tas); + /* seems that half is a saner default */ tas->drc_range = TAS3004_DRC_MAX / 2; - strlcpy(tas->i2c.name, "tas audio codec", I2C_NAME_SIZE); - - if (i2c_attach_client(&tas->i2c)) { - printk(KERN_ERR PFX "failed to attach to i2c\n"); - goto fail; - } strlcpy(tas->codec.name, "tas", MAX_CODEC_NAME_LEN); tas->codec.owner = THIS_MODULE; @@ -915,14 +931,12 @@ static int tas_create(struct i2c_adapter tas->codec.node = of_node_get(node); if (aoa_codec_register(&tas->codec)) { - goto detach; + goto fail; } printk(KERN_DEBUG "snd-aoa-codec-tas: tas found, addr 0x%02x on %s\n", - addr, node->full_name); + (unsigned int)client->addr, node->full_name); return 0; - detach: - i2c_detach_client(&tas->i2c); fail: mutex_destroy(&tas->mtx); kfree(tas); @@ -970,14 +984,11 @@ static int tas_i2c_attach(struct i2c_ada return -ENODEV; } -static int tas_i2c_detach(struct i2c_client *client) +static int tas_i2c_remove(struct i2c_client *client) { - struct tas *tas = container_of(client, struct tas, i2c); - int err; + struct tas *tas = i2c_get_clientdata(client); u8 tmp = TAS_ACR_ANALOG_PDOWN; - if ((err = i2c_detach_client(client))) - return err; aoa_codec_unregister(&tas->codec); of_node_put(tas->codec.node); @@ -989,13 +1000,20 @@ static int tas_i2c_detach(struct i2c_cli return 0; } +static const struct i2c_device_id tas_i2c_id[] = { + { "aoa_codec_tas", 0 }, + { } +}; + static struct i2c_driver tas_driver = { .driver = { .name = "aoa_codec_tas", .owner = THIS_MODULE, }, .attach_adapter = tas_i2c_attach, - .detach_client = tas_i2c_detach, + .probe = tas_i2c_probe, + .remove = tas_i2c_remove, + .id_table = tas_i2c_id, }; static int __init tas_init(void) -- Jean Delvare

3 4

Re: [alsa-devel] [PATCH] keywest: Convert to new-style i2c driver
by Takashi Iwai 21 Apr '09

21 Apr '09

At Tue, 21 Apr 2009 19:33:00 +1000, Paul Mackerras wrote: > > Takashi Iwai writes: > > > At least, the conversion patch Jean posted can be in 2.6.30, I think. > > Really? What regression, security hole or serious bug are you going > to tell Linus that it fixes? :) Build warning fixes :) Takashi

1 0

Re: [alsa-devel] 2.6.29 regression: left audio channel broken after resume from suspend with Intel HDA
by Takashi Iwai 21 Apr '09

21 Apr '09

At Tue, 21 Apr 2009 09:32:19 +0200, Tino Keitel wrote: > > On Tue, Apr 21, 2009 at 07:24:40 +0200, Takashi Iwai wrote: > > The commit is fcad94a4c71c36a05f4d5c6dcb174534b4e0b136: > > ALSA: hda - Fix the cmd cache keys for amp verbs > > Thanks for the reply. However, the patch doesn't work. I just got > distorted sound again. Then please run alsa-info.sh (with --no-upload option) before and after suspend, and attach the generated files. Also, check the latest Linus tree whether the problem still appears. thanks, Takashi

1 0

[alsa-devel] Getting M-Audio JamLab simple controls to work
by Greg Erwin 21 Apr '09

21 Apr '09

I have an M-Audio JamLab usb audio interface. Long story short, it works for the most part, but trying to use the simple controls via amixer or alsamixer don't work. I've filed a bug report about it a little while back that has quite a bit of information in it: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4415 Anyway, I feel like it would't take a whole lot to get working (I hope), but the thing is, I bet very few people actually have one. I know a little bit of C, and will be glad to help as much as I can.

2 1

Re: [alsa-devel] 2.6.29 regression: left audio channel broken after resume from suspend with Intel HDA
by Takashi Iwai 21 Apr '09

21 Apr '09

At Mon, 20 Apr 2009 21:46:59 +0200, Tino Keitel wrote: > > On Mon, Apr 20, 2009 at 21:41:06 +0200, Takashi Iwai wrote: > > [...] > > > Could you try the latest Linus git tree? A fix patch was merged > > after 2.6.30-rc2. The patch will be merged to later stable kernel, too. > > What commit is this? Can it be applied to 2.6.29? As it isn't perfectly > reproducable, I'd like to run 2.6.29 with the patch applied and see if > the problem disappears. The commit is fcad94a4c71c36a05f4d5c6dcb174534b4e0b136: ALSA: hda - Fix the cmd cache keys for amp verbs Takashi

1 0

[alsa-devel] PS3 Eye Microphone support
by Mihai Tanasescu 21 Apr '09

21 Apr '09

Hello guys, I don't know if this is the proper list to address the question but here it goes and sorry if I'm wrong. I wanted to ask if there is any support for the Playstation3 Eye USB Camera Microphone provided by alsa at the moment or if there are plans to support it. Currently from what I could figure out: root@Mihai:~# cat /proc/asound/cards 0 [Audigy ]: Audigy - Audigy 1 [SB0090] Audigy 1 [SB0090] (rev.3, serial:0x531102) at 0xb880, irq 23 1 [CameraB304061 ]: USB-Audio - USB Camera-B3.04.06.1 OmniVision Technologies, Inc. USB Camera-B3.04.06.1 at usb-0000:00:1d.7-5.1, hi the Microphone Camera is seen there. I successfully recorded something using Audacity and the OSS driver that was reported in the recording options. What I can't do is control the sound levels via the gnome volume control applet (which uses alsactl store and restore). Also, alsamixer won't work. root@Mihai:~# alsactl store alsactl: get_control:262: Cannot read control '2,0,0,Mic Capture Volume,0': Invalid argument root@Mihai:~# alsamixer -c 1 alsamixer: function snd_mixer_load failed: Invalid argument Cheers, Mihai

1 0

Re: [alsa-devel] 2.6.29 regression: left audio channel broken after resume from suspend with Intel HDA
by Takashi Iwai 20 Apr '09

20 Apr '09

At Mon, 20 Apr 2009 20:40:24 +0200, Tino Keitel wrote: > > Hi, > > since 2.6.29 and also with 2.6.29.1 the left audio channel of the > digital output of my Mac mini Core 2 Duo is noisy. This didn't happen > with 2.6.28. Unloading snd-hda-intel and reloading it does fix the > noisy sound. > > This happened with some older versions of the Linux kernel (with an > older Mac mini Core Duo, I don't remeber which kernel version), but got > fixed at some point. Now it happens again with 2.6.29. Could you try the latest Linus git tree? A fix patch was merged after 2.6.30-rc2. The patch will be merged to later stable kernel, too. Takashi

1 0

Re: [alsa-devel] 2.6.29 regression: left audio channel broken after resume from suspend with Intel HDA
by Rafael J. Wysocki 20 Apr '09

20 Apr '09

On Monday 20 April 2009, Tino Keitel wrote: > Hi, > > since 2.6.29 and also with 2.6.29.1 the left audio channel of the > digital output of my Mac mini Core 2 Duo is noisy. This didn't happen > with 2.6.28. Unloading snd-hda-intel and reloading it does fix the > noisy sound. > > This happened with some older versions of the Linux kernel (with an > older Mac mini Core Duo, I don't remeber which kernel version), but got > fixed at some point. Now it happens again with 2.6.29. > > Here is the dmesg output for the sound hardware: > > HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 > HDA Intel 0000:00:1b.0: setting latency timer to 64 > hda_codec: STAC922x, Apple subsys_id=100 > input: HDA Intel Line In at Ext Left Jack as /class/input/input18 > input: HDA Intel Mic at Ext Left Jack as /class/input/input19 > input: HDA Intel HP Out at Ext Left Jack as /class/input/input20 > > Any hints what I could try to fix this, maybe some commit that I should > try to revert? Well, no. Still, you might try the current Linus' tree. Best, Rafael

1 0