January 2011 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ALSA: hda: Use vostro model quirk for Dell Vostro 1014 [Was: Re: Please add PCI quirk for Vostro 1014 (1028:0401)]
by Daniel Chen 10 Jan '11

10 Jan '11

Hi Fernando, Takashi, Attached is a patch against current master HEAD resolving Fernando's symptom. Thanks, -Dan On Sat, Jan 8, 2011 at 11:37 AM, Fernando Lemos <fernandotcl(a)gmail.com> wrote: > Hi, > > Following the advice received here[1] (thanks, Raymond), I'm asking > for someone to add the following entry to the list of PCI quirks > cxt5066_cfg_tbl if possible: > > SND_PCI_QUIRK(0x1028, 0x02f5, "Dell", CXT5066_DELL_LAPTOP), > +SND_PCI_QUIRK(0x1028, 0x0401, "Dell Vostro 1014", CXT5066_DELL_VOSTRO), > SND_PCI_QUIRK(0x1028, 0x0402, "Dell Vostro", CXT5066_DELL_VOSTRO), > SND_PCI_QUIRK(0x1028, 0x0408, "Dell Inspiron One 19T", CXT5066_IDEAPAD), > > Codec: Conexant CX20583 (Pebble HSF) > Address: 0 > Function Id: 0x2 > Vendor Id: 0x14f15067 > Subsystem Id: 0x10280401 > Revision Id: 0x100300 > > I can confirm that forcing model=vostro works perfectly for this > specific laptop model (tested speakers and headphones). If there's any > test you want me to do, please let me know. There are more details > about the issue in the aforementioned bug report[1]. > > By the way, I also got a chance to test on 2.6.37 recently and the > problem persists. In fact, in 2.6.37 I don't even get any sound in my > headphones. But it all works flawlessly with model=vostro. > > I apologize if you receive another e-mail from me with similar > contents in the future. I've sent this e-mail to the list last year, > but I wasn't subscribed so I'd been waiting for moderator approval > since then. Now I'm subscribed to the list, let's see if this e-mail > gets through. > > [1] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5184 > > Thanks in advance, > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >

2 1

[alsa-devel] [PATCH] ALSA: HDA: Add Lenovo vendor quirk for Conexant 205xx
by David Henningsson 10 Jan '11

10 Jan '11

BugLink: http://bugs.launchpad.net/bugs/689036 Many new Lenovos need the ideapad quirk. Also, since the auto parser for this chip is far from optimal, the regression risk is low (although not zero). So let's add it for 2.6.38, but not for stable. Seems reasonable? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1

[alsa-devel] [PATCH] ALSA: HDA: Fix volume control indices for Mics (Realtek)
by David Henningsson 10 Jan '11

10 Jan '11

This patch assumes you applied the "Boost" => "Boost Volume" patch posted yesterday. If more than one mic is present with different locations, e g "Front Mic" and "Rear Mic", they can use the same index (0), since their names are different. Previous behavior was to have "Front Mic" as index 1, causing it to be ignored by e g PulseAudio. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1

[alsa-devel] [PATCH] ALSA: HDA: Rename "Mic Boost" to "Mic Boost Volume"
by David Henningsson 10 Jan '11

10 Jan '11

If the "Volume" suffix is not given, alsa-lib gets confused and loses the dB information at the simple element level. Boosts generally affects both playback and capture, as they are applied early in the chain. Hence no "Playback" or "Capture" in the suffix. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1

[alsa-devel] [PATCH] ALSA: HDA: Add internal mic for IDT 92HD88B
by David Henningsson 10 Jan '11

10 Jan '11

BugLink: http://bugs.launchpad.net/bugs/696493 According to datasheet (and real-world testing), IDT 92HD88B can have internal mics at NID 0x11 and 0x20, so enable them accordingly. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1

[alsa-devel] snd_soc_codec_set_cache_io()
by Timur Tabi 10 Jan '11

10 Jan '11

Mark, The comments for snd_soc_codec_set_cache_io() say this: * Note that at present this code cannot be used by CODECs with * volatile registers. Is this still true? I ask because I think I've been able to use this function in the CS4270 with volatile registers, and it appears to work. -- Timur Tabi Linux kernel developer at Freescale

2 1

Re: [alsa-devel] [PATCH] Don't leak in sound/core/oss/pcm_oss.c::snd_pcm_hw_param_near()
by Takashi Iwai 10 Jan '11

10 Jan '11

At Thu, 6 Jan 2011 22:19:47 +0100 (CET), Jesper Juhl wrote: > > > snd_pcm_hw_param_near() will leak the memory allocated to 'save' if the > call to snd_pcm_hw_param_max() returns less than zero. > This patch makes sure we never leak. > > Signed-off-by: Jesper Juhl <jj(a)chaosbits.net> Applied now. Thanks. Takashi > --- > pcm_oss.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/sound/core/oss/pcm_oss.c b/sound/core/oss/pcm_oss.c > index b753ec6..a2e4eb3 100644 > --- a/sound/core/oss/pcm_oss.c > +++ b/sound/core/oss/pcm_oss.c > @@ -453,8 +453,10 @@ static int snd_pcm_hw_param_near(struct snd_pcm_substream *pcm, > } else { > *params = *save; > max = snd_pcm_hw_param_max(pcm, params, var, max, &maxdir); > - if (max < 0) > + if (max < 0) { > + kfree(save); > return max; > + } > last = 1; > } > _end: > > > > -- > Jesper Juhl <jj(a)chaosbits.net> http://www.chaosbits.net/ > Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html > Plain text mails only, please. >

1 0

[alsa-devel] PCM direct access functions for recording
by jonas.rabbe＠nokia.com 10 Jan '11

10 Jan '11

Hi, I am trying to use the PCM direct access (MMAP) functions for recording sound from an ALSA source, and reading the documentation has brought up a few questions. The documentation page for the mmap function [1] and the PCM test demo [2] both concern themselves with writing to the ring buffer. I was wondering if there was a similar example for reading from the ring buffer. At this point I have been searching through the alsa-devel archives, alsa-project.org, and anything else google could throw at me, but it seems my google-fu is not as strong as I had thought. Any pointers and links concerning my use case would be most appreciated. Thank you, Jonas Rabbe Software Engineer // Qt Multimedia / Brisbane / Australia [1] http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___direct.html [2] http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html

1 0

[alsa-devel] hda: again low volume problem :-(
by Halim Sahin 09 Jan '11

09 Jan '11

hi Folks, i see the low volume problem is not only related to my hardware but reported a few times in alsa-user mailinglist. Please! have a look in to that problem. Using 100% of the volume sliders in alsamixer is not enough to get usable sound for the amp. here my last mail ng the same problemd Hi, On Mo, Aug 23, 2010 at 08:18:46 +0200, Takashi Iwai wrote: > First off, try with the latest version of alsa-driver. > Get the snapshot version from > ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-sna… Done. Compilation and load of the modules are ok but the volume stays low on the rear panel of the computer. > If this doesn't help, try to set EAPD on NID 0x14 and/or 0x15, set it > to 0x02. Get hda-verb program (available on OBS home:tiwai repo), > then run like > > hda-verb /dev/snd/hwC0D0 0x14 SET_EAPD 0x02 > hda-verb /dev/snd/hwC0D0 0x15 SET_EAPD 0x02 also no success with hda-verb. Do you have more ideas what I can test? Maybe this aditional info helps you :-). I noticed a difference in volume between headphone (front connector) and the line out (rear panel connector). The volume is higher when using the headphone connector but should also be improoved a bit :-(. this info is from alsamixer and the new driver: Card: HDA NVidia Chip: Nvidia ID 7 This info is from the orginal driver of kernel 2.6.34: Card: HDA NVidia Chip: Nvidia MCP79/7A HDMI Why does alsamixer show Chip: Nvidia ID 7 with new driver? All help appreciated ;-) BR. halim

1 0

[alsa-devel] [PATCH] ASoC: Taint the kernel if debugfs is used to write directly to CODECs
by Mark Brown 09 Jan '11

09 Jan '11

Since direct register writes may confuse the drivers and are supposed to be used only in diagnostic situations discourage their use in production by tainting the kernel when we do a write. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmciro.com> --- sound/soc/soc-core.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index a233607..dbca5023 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -209,6 +209,10 @@ static ssize_t codec_reg_write_file(struct file *file, start++; if (strict_strtoul(start, 16, &value)) return -EINVAL; + + /* Userspace has been fiddling around behind the kernel's back */ + add_taint(TAINT_USER); + snd_soc_write(codec, reg, value); return buf_size; } -- 1.7.2.3

2 1