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

[alsa-devel] [PATCH] ALSA: hda: Use STAC_DELL_M6_BOTH quirk for Dell Studio 1558
by Daniel Chen 23 Apr '10

23 Apr '10

Hi, Attached is a patch against sound-2.6 master HEAD making audio work by default for the OR's Dell Studio 1558. Best, -Dan

2 1

[alsa-devel] [PATCH] ALSA: hda: Use LPIB quirk for DG965OT board version AAD63733-203
by Daniel Chen 23 Apr '10

23 Apr '10

Hi, Attached is a patch against sound-2.6 master HEAD that makes the OR's audio work by default. Best, -Dan

2 1

[alsa-devel] [PATCH 0/5] ASoC: tlv320dac33: FIFO caused delay reporting and fixes
by Peter Ujfalusi 23 Apr '10

23 Apr '10

Hello, The main feature of this series is the FIFO caused delay reporting on the DAC33 codec. The main patch is quite big, but I don't think it can be divided further. Short details of the actual implementation is in the commit message(s), and I will not copy it here. The values reported by the delay call has been verified by using one GPIO as a signal, and printout from the kernel at the same time with the delay, than based on the time scale on the scope several (>100) cases has been hand calculated and the results were compared to the kernel reported values. The difference were around (or less) the 10 samples, but during the bursts it is much harder to count, but the reported value was reasonable accurate there as well. --- Peter Ujfalusi (5): ASoC: tlv320dac33: Fix for early interrupt in FIFO Mode1 ASoC: tlv320dac33: Skip calculations in FIFO Bypass mode ASoC: tlv320dac33: Change magic numbers used in Mode7 ASoC: tlv320dac33: Calculate the interface speed during bursts ASoC: tlv320dac33: FIFO caused delay reporting sound/soc/codecs/tlv320dac33.c | 249 ++++++++++++++++++++++++++++++++++++++-- 1 files changed, 237 insertions(+), 12 deletions(-)

2 9

[alsa-devel] [PATCH 1/4] snd-meastro3: Add amp_gpio quirk for Compaq EVO N600C
by Hans de Goede 22 Apr '10

22 Apr '10

Without this quirk sound stops working after suspend resume. With this quirk, one still needs to manually unmute the master volume control after a suspend / / resume cycle. That is fixed in another patch in this set. Note that this patch was submitted to the alsa bug tracker a long time ago: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4319 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/pci/maestro3.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/maestro3.c b/sound/pci/maestro3.c index 75283fb..491a2fc 100644 --- a/sound/pci/maestro3.c +++ b/sound/pci/maestro3.c @@ -884,6 +884,7 @@ static struct pci_device_id snd_m3_ids[] = { MODULE_DEVICE_TABLE(pci, snd_m3_ids); static struct snd_pci_quirk m3_amp_quirk_list[] __devinitdata = { + SND_PCI_QUIRK(0x0E11, 0x0094, "Compaq Evo N600c", 0x0c), SND_PCI_QUIRK(0x10f7, 0x833e, "Panasonic CF-28", 0x0d), SND_PCI_QUIRK(0x10f7, 0x833d, "Panasonic CF-72", 0x0d), SND_PCI_QUIRK(0x1033, 0x80f1, "NEC LM800J/7", 0x03), -- 1.7.0.1

4 9

[alsa-devel] [PATCH 1/2] snd-maestro3: Make hardware volume buttons an input device
by Hans de Goede 22 Apr '10

22 Apr '10

While working on the sound suspend / resume problems with my laptop I noticed that the hardware volume handling code in essence just detects key presses, and then does some hardcoded modification of the master volume based on which key is pressed. This made me think that clearly the right thing to do here is just report these keypresses to userspace as keypresses using an input device and let userspace decide what to with them. This patch does this, getting rid of the ugly direct ac97 writes from the tasklet, the ac97lock and the need for using a tasklet in general. As an added bonus the keys now work identical to volume keys on a (usb) keyboard with multimedia keys, providing visual feedback of the volume level change, and a better range of the volume control (with a properly configured desktop environment). Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/pci/maestro3.c | 133 +++++++++++++++++++++++++++----------------------- 1 files changed, 72 insertions(+), 61 deletions(-) diff --git a/sound/pci/maestro3.c b/sound/pci/maestro3.c index 0ed634a..4ee1b67 100644 --- a/sound/pci/maestro3.c +++ b/sound/pci/maestro3.c @@ -41,6 +41,7 @@ #include <linux/vmalloc.h> #include <linux/moduleparam.h> #include <linux/firmware.h> +#include <linux/input.h> #include <sound/core.h> #include <sound/info.h> #include <sound/control.h> @@ -806,6 +807,10 @@ struct m3_dma { struct snd_m3 { struct snd_card *card; +#ifdef CONFIG_INPUT + struct input_dev *input_dev; + char phys[64]; /* physical device path */ +#endif unsigned long iobase; @@ -844,11 +849,7 @@ struct snd_m3 { struct m3_dma *substreams; spinlock_t reg_lock; - spinlock_t ac97_lock; - struct snd_kcontrol *master_switch; - struct snd_kcontrol *master_volume; - struct tasklet_struct hwvol_tq; unsigned int in_suspend; #ifdef CONFIG_PM @@ -1602,11 +1603,9 @@ static void snd_m3_update_ptr(struct snd_m3 *chip, struct m3_dma *s) (without wrap around) in response to volume button presses and then generating an interrupt. The pair of counters is stored in bits 1-3 and 5-7 of a byte wide register. The meaning of bits 0 and 4 is unknown. */ -static void snd_m3_update_hw_volume(unsigned long private_data) +static void snd_m3_update_hw_volume(struct snd_m3 *chip) { - struct snd_m3 *chip = (struct snd_m3 *) private_data; - int x, val; - unsigned long flags; + int x, key = 0; /* Figure out which volume control button was pushed, based on differences from the default register @@ -1632,51 +1631,34 @@ static void snd_m3_update_hw_volume(unsigned long private_data) if (chip->in_suspend) return; - if (!chip->master_switch || !chip->master_volume) +#ifdef CONFIG_INPUT + if (!chip->input_dev) return; - /* FIXME: we can't call snd_ac97_* functions since here is in tasklet. */ - spin_lock_irqsave(&chip->ac97_lock, flags); - - val = chip->ac97->regs[AC97_MASTER_VOL]; switch (x) { case 0x88: /* The counters have not changed, yet we've received a HV interrupt. According to tests run by various people this happens when pressing the mute button. */ - val ^= 0x8000; - chip->ac97->regs[AC97_MASTER_VOL] = val; - outw(val, chip->iobase + CODEC_DATA); - outb(AC97_MASTER_VOL, chip->iobase + CODEC_COMMAND); - snd_ctl_notify(chip->card, SNDRV_CTL_EVENT_MASK_VALUE, - &chip->master_switch->id); + key = KEY_MUTE; break; case 0xaa: /* counters increased by 1 -> volume up */ - if ((val & 0x7f) > 0) - val--; - if ((val & 0x7f00) > 0) - val -= 0x0100; - chip->ac97->regs[AC97_MASTER_VOL] = val; - outw(val, chip->iobase + CODEC_DATA); - outb(AC97_MASTER_VOL, chip->iobase + CODEC_COMMAND); - snd_ctl_notify(chip->card, SNDRV_CTL_EVENT_MASK_VALUE, - &chip->master_volume->id); + key = KEY_VOLUMEUP; break; case 0x66: /* counters decreased by 1 -> volume down */ - if ((val & 0x7f) < 0x1f) - val++; - if ((val & 0x7f00) < 0x1f00) - val += 0x0100; - chip->ac97->regs[AC97_MASTER_VOL] = val; - outw(val, chip->iobase + CODEC_DATA); - outb(AC97_MASTER_VOL, chip->iobase + CODEC_COMMAND); - snd_ctl_notify(chip->card, SNDRV_CTL_EVENT_MASK_VALUE, - &chip->master_volume->id); + key = KEY_VOLUMEDOWN; break; } - spin_unlock_irqrestore(&chip->ac97_lock, flags); + + if (key) { + input_report_key(chip->input_dev, key, 1); + input_sync(chip->input_dev); + input_report_key(chip->input_dev, key, 0); + input_sync(chip->input_dev); + } +#endif } static irqreturn_t snd_m3_interrupt(int irq, void *dev_id) @@ -1691,7 +1673,7 @@ static irqreturn_t snd_m3_interrupt(int irq, void *dev_id) return IRQ_NONE; if (status & HV_INT_PENDING) - tasklet_schedule(&chip->hwvol_tq); + snd_m3_update_hw_volume(chip); /* * ack an assp int if its running @@ -1957,18 +1939,14 @@ static unsigned short snd_m3_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { struct snd_m3 *chip = ac97->private_data; - unsigned long flags; unsigned short data = 0xffff; if (snd_m3_ac97_wait(chip)) goto fail; - spin_lock_irqsave(&chip->ac97_lock, flags); snd_m3_outb(chip, 0x80 | (reg & 0x7f), CODEC_COMMAND); if (snd_m3_ac97_wait(chip)) - goto fail_unlock; + goto fail; data = snd_m3_inw(chip, CODEC_DATA); -fail_unlock: - spin_unlock_irqrestore(&chip->ac97_lock, flags); fail: return data; } @@ -1977,14 +1955,11 @@ static void snd_m3_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned short val) { struct snd_m3 *chip = ac97->private_data; - unsigned long flags; if (snd_m3_ac97_wait(chip)) return; - spin_lock_irqsave(&chip->ac97_lock, flags); snd_m3_outw(chip, val, CODEC_DATA); snd_m3_outb(chip, reg & 0x7f, CODEC_COMMAND); - spin_unlock_irqrestore(&chip->ac97_lock, flags); } @@ -2091,7 +2066,6 @@ static int __devinit snd_m3_mixer(struct snd_m3 *chip) { struct snd_ac97_bus *pbus; struct snd_ac97_template ac97; - struct snd_ctl_elem_id elem_id; int err; static struct snd_ac97_bus_ops ops = { .write = snd_m3_ac97_write, @@ -2111,15 +2085,6 @@ static int __devinit snd_m3_mixer(struct snd_m3 *chip) schedule_timeout_uninterruptible(msecs_to_jiffies(100)); snd_ac97_write(chip->ac97, AC97_PCM, 0); - memset(&elem_id, 0, sizeof(elem_id)); - elem_id.iface = SNDRV_CTL_ELEM_IFACE_MIXER; - strcpy(elem_id.name, "Master Playback Switch"); - chip->master_switch = snd_ctl_find_id(chip->card, &elem_id); - memset(&elem_id, 0, sizeof(elem_id)); - elem_id.iface = SNDRV_CTL_ELEM_IFACE_MIXER; - strcpy(elem_id.name, "Master Playback Volume"); - chip->master_volume = snd_ctl_find_id(chip->card, &elem_id); - return 0; } @@ -2398,6 +2363,11 @@ static int snd_m3_free(struct snd_m3 *chip) struct m3_dma *s; int i; +#ifdef CONFIG_INPUT + if (chip->input_dev) + input_unregister_device(chip->input_dev); +#endif + if (chip->substreams) { spin_lock_irq(&chip->reg_lock); for (i = 0; i < chip->num_substreams; i++) { @@ -2524,6 +2494,41 @@ static int m3_resume(struct pci_dev *pci) } #endif /* CONFIG_PM */ +#ifdef CONFIG_INPUT +static int __devinit snd_m3_input_register(struct snd_m3 *chip) +{ + struct input_dev *input_dev; + int err; + + input_dev = input_allocate_device(); + if (!input_dev) + return -ENOMEM; + + snprintf(chip->phys, sizeof(chip->phys), "pci-%s/input0", + pci_name(chip->pci)); + + input_dev->name = chip->card->driver; + input_dev->phys = chip->phys; + input_dev->id.bustype = BUS_PCI; + input_dev->id.vendor = chip->pci->vendor; + input_dev->id.product = chip->pci->device; + input_dev->dev.parent = &chip->pci->dev; + + __set_bit(EV_KEY, input_dev->evbit); + __set_bit(KEY_MUTE, input_dev->keybit); + __set_bit(KEY_VOLUMEDOWN, input_dev->keybit); + __set_bit(KEY_VOLUMEUP, input_dev->keybit); + + err = input_register_device(input_dev); + if (err) { + input_free_device(input_dev); + return err; + } + + chip->input_dev = input_dev; + return 0; +} +#endif /* CONFIG_INPUT */ /* */ @@ -2567,7 +2572,6 @@ snd_m3_create(struct snd_card *card, struct pci_dev *pci, } spin_lock_init(&chip->reg_lock); - spin_lock_init(&chip->ac97_lock); switch (pci->device) { case PCI_DEVICE_ID_ESS_ALLEGRO: @@ -2650,8 +2654,6 @@ snd_m3_create(struct snd_card *card, struct pci_dev *pci, snd_m3_hv_init(chip); - tasklet_init(&chip->hwvol_tq, snd_m3_update_hw_volume, (unsigned long)chip); - if (request_irq(pci->irq, snd_m3_interrupt, IRQF_SHARED, card->driver, chip)) { snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq); @@ -2682,7 +2684,16 @@ snd_m3_create(struct snd_card *card, struct pci_dev *pci, if ((err = snd_m3_pcm(chip, 0)) < 0) return err; - + +#ifdef CONFIG_INPUT + if (chip->hv_config & HV_CTRL_ENABLE) { + err = snd_m3_input_register(chip); + if (err) + snd_printk(KERN_WARNING "Input device registration " + "failed with error %i", err); + } +#endif + snd_m3_enable_ints(chip); snd_m3_assp_continue(chip); -- 1.7.0.1

2 3

[alsa-devel] [PATCH - alsa-lib 1/1] Fix for snd_seq_parse_address()
by pedro.lopez.cabanillas＠gmail.com 22 Apr '10

22 Apr '10

From: Pedro Lopez-Cabanillas <pedro.lopez.cabanillas(a)gmail.com> snd_seq_parse_address() uses strncmp() to compare the client name in the string argument with the existing clients, until it finds one name matching the same leading characters. This may produce wrong results when there are two sequencer clients with similar names. For instance, the following procedure produces a wrong result: 1. start KMidimon (http://kmidimon.sf.net) $ kmidimon & -->results: Client 128 : "KMidimon" [User] 2. start KMid (http://kmid2.sf.net) $ kmid & -->results: Client 129 : "KMid" [User] 3. try to subscribe the output port of KMid to KMidimon $ aconnect KMid:0 KMidimon:0 --> results: Client 128 : "KMidimon" [User] Port 0 : "KMidimon" (RWe-) Connecting To: 20:0, 128:0 Connected From: 0:1, 128:0 128:0 becomes subscribed to itself. It should be subscribed from 129:0 instead. Signed-off-by: Pedro Lopez-Cabanillas <pedro.lopez.cabanillas(a)gmail.com> --- src/seq/seqmid.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/seq/seqmid.c b/src/seq/seqmid.c index 86a4970..894c3a2 100644 --- a/src/seq/seqmid.c +++ b/src/seq/seqmid.c @@ -414,7 +414,8 @@ int snd_seq_parse_address(snd_seq_t *seq, snd_seq_addr_t *addr, const char *arg) return -EINVAL; cinfo.client = -1; while (snd_seq_query_next_client(seq, &cinfo) >= 0) { - if (! strncmp(arg, cinfo.name, len)) { + if ((strlen(cinfo.name) == len) && + ! strncmp(arg, cinfo.name, len)) { addr->client = cinfo.client; return 0; } -- 1.6.4.2

2 1

[alsa-devel] [PATCH] ALSA: hda: Use ALC880_F1734 quirk for Fujitsu Siemens AMILO Xi 1526
by Daniel Chen 22 Apr '10

22 Apr '10

Hi, Attached is a patch (also applicable to 2.6.32.11 and 2.6.33.2) against sound-2.6 master HEAD that fixes the quirk used for the OR's hardware. Best, -Dan

2 1

Re: [alsa-devel] No shutdown code in soc-core.c
by ANISH KUMAR 22 Apr '10

22 Apr '10

Thanks everyone for the replies but i think for this trivial problem i don't need to backport the kernel.Anyway now i know the answer for my posted question.I have kept backporting as an excersie as my assignment which i will do in due period of time. ------- Original Message------- Sender: Mark Brown<broonie(a)opensource.wolfsonmicro.com> Date: Apr 20, 2010 01:59 (GMT+09:00) Title: Re: [alsa-devel] No shutdown code in soc-core.c On Mon, Apr 19, 2010 at 03:10:55PM +0100, Liam Girdwood wrote: > Ah, your kernel is very old. I would just do what you are currently > doing with shutdown and use the dev_pm_ops when you upgrade your kernel. Actually, IME it's probably as easy to just backport current ASoC to 2.6.29 if you're doing anything non-trivial - the backport is very straightforward for most platforms and the benefits of the enhancements in ASoC are well worth the effort.

1 0

[alsa-devel] pulseaudio eats 19% CPU power in Fedora 12
by Wu Fengguang 22 Apr '10

22 Apr '10

Hi Lennart, We found that pulseaudio eats CPU ~19% CPU time, a little more than mplayer when playing video. This is horrible for laptop batteries. Can we make it just work -- in green CPU mode? I can find many users complaining about this, and it seems like some fix is available in this link: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135 Thanks, Fengguang

6 12

[alsa-devel] [PATCH] ALSA: hda: Use STAC_DELL_M6_BOTH quirk for Dell Studio XPS 1645
by Daniel Chen 22 Apr '10

22 Apr '10

Hi, Attached is a patch against sound-2.6 master HEAD adding a quirk for the Dell Studio XPS 1645 to make playback and capture work. Best, -Dan

2 1