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

[alsa-devel] [PATCH 0/3] add support for jack detection in mid-x86
by Koul, Vinod 09 Feb '11

09 Feb '11

From: Vinod Koul <vinod.koul(a)intel.com> This patch set adds support for jack detection in mid-x6 machine and TI sn95031 codec drivers. This also adds support to read mic bias values thru ADC The comments from previous submission are addressed and patches split Vinod Koul (3): ASoC: sn95031: Add jack support in the codec ASoC: mfld_machine: Add support for jack detection ASoC: sn95031: Add support for reading mic bias sound/soc/codecs/sn95031.c | 184 ++++++++++++++++++++++++++++++++- sound/soc/codecs/sn95031.h | 35 ++++++ sound/soc/mid-x86/mfld_machine.c | 211 +++++++++++++++++++++++++++++++++----- 3 files changed, 399 insertions(+), 31 deletions(-) -- 1.7.2.3

2 12

[alsa-devel] [PATCH 1/6] ASoC: Tegra: Harmony: Add headphone jack detection
by Stephen Warren 09 Feb '11

09 Feb '11

Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/tegra/harmony.c | 30 +++++++++++++++++++++++++++++- 1 files changed, 29 insertions(+), 1 deletions(-) diff --git a/sound/soc/tegra/harmony.c b/sound/soc/tegra/harmony.c index 1b80c4f..26ab4fd 100644 --- a/sound/soc/tegra/harmony.c +++ b/sound/soc/tegra/harmony.c @@ -38,6 +38,7 @@ #include <mach/harmony_audio.h> #include <sound/core.h> +#include <sound/jack.h> #include <sound/pcm.h> #include <sound/pcm_params.h> #include <sound/soc.h> @@ -123,6 +124,24 @@ static struct snd_soc_ops harmony_asoc_ops = { .hw_params = harmony_asoc_hw_params, }; +static struct snd_soc_jack harmony_hp_jack; + +static struct snd_soc_jack_pin harmony_hp_jack_pins[] = { + { + .pin = "Headphone Jack", + .mask = SND_JACK_HEADPHONE, + }, +}; + +static struct snd_soc_jack_gpio harmony_hp_jack_gpios[] = { + { + .name = "headphone detect", + .report = SND_JACK_HEADPHONE, + .debounce_time = 150, + .invert = 1, + } +}; + static int harmony_event_int_spk(struct snd_soc_dapm_widget *w, struct snd_kcontrol *k, int event) { @@ -178,11 +197,20 @@ static int harmony_asoc_init(struct snd_soc_pcm_runtime *rtd) snd_soc_dapm_add_routes(dapm, harmony_audio_map, ARRAY_SIZE(harmony_audio_map)); - snd_soc_dapm_enable_pin(dapm, "Headphone Jack"); snd_soc_dapm_enable_pin(dapm, "Int Spk"); snd_soc_dapm_enable_pin(dapm, "Mic Jack"); snd_soc_dapm_sync(dapm); + harmony_hp_jack_gpios[0].gpio = pdata->gpio_hp_det; + snd_soc_jack_new(codec, "Headphone Jack", SND_JACK_HEADPHONE, + &harmony_hp_jack); + snd_soc_jack_add_pins(&harmony_hp_jack, + ARRAY_SIZE(harmony_hp_jack_pins), + harmony_hp_jack_pins); + snd_soc_jack_add_gpios(&harmony_hp_jack, + ARRAY_SIZE(harmony_hp_jack_gpios), + harmony_hp_jack_gpios); + return 0; } -- 1.7.1

3 25

[alsa-devel] [PATCH] alsa-utils: Spelling fixes
by David Henningsson 09 Feb '11

09 Feb '11

While looking into the Debian packaging of alsa-utils, I noticed a few patches which fix spelling errors. I'm attaching them here. If the patches attached are good for just applying, please do so or report back if there's anything I can do to get them in upstream. Thanks! -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

1 0

Re: [alsa-devel] ALC861-VD bad recording issue
by Raymond Yau 09 Feb '11

09 Feb '11

> This is the output of the alsa script to ge information about my system and the driver http://www.alsa-project.org/db/?f=9871b38d99bdd4cc91e398b60eb31361eb305395 Node 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Input Source", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x80 0x80] [0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 11 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b if Input source is using [Audio Mixer], the driver may need to unmute only the seleted source and the other sources may need to be muted

1 0

Re: [alsa-devel] MIDI playback not keeping steady time with recent kernels
by Clemens Ladisch 09 Feb '11

09 Feb '11

Arthur Marsh wrote: >>> Arthur Marsh wrote, on 05/02/11 17:30: >>>> MIDI playback either through xmms or aplaymidi won't keep regular time, >>>> sounding weird going faster and slower under any kind of system load >>>> except when nothing else is running. > > I've tried setting "options snd-timer timer_limit=x" where x is anywhere > from 5 down to 0, and seeing either: > > $ cat /proc/asound/seq/timer > Timer for queue 0 : HR timer > Period time : 0.004000250 > Skew : 65536 / 65536 > > or "system timer" in place of "HR timer". > > In all cases, under sufficient load (which might be just running > aptitude -u), the tempo of the MIDI file play-back slows right down. The ALSA interfaces of both the system timer and the HR timer do not handle delayed interrupts correctly. Please try the patch below, and if it fixes the HR timer, tell me if you're OK with the published tag Reported-and-tested-by: Arthur Marsh <arthur.marsh(a)internode.on.net>. Regards, Clemens --- a/sound/core/hrtimer.c +++ b/sound/core/hrtimer.c @@ -45,12 +45,13 @@ static enum hrtimer_restart snd_hrtimer_ { struct snd_hrtimer *stime = container_of(hrt, struct snd_hrtimer, hrt); struct snd_timer *t = stime->timer; + unsigned long oruns; if (!atomic_read(&stime->running)) return HRTIMER_NORESTART; - hrtimer_forward_now(hrt, ns_to_ktime(t->sticks * resolution)); - snd_timer_interrupt(stime->timer, t->sticks); + oruns = hrtimer_forward_now(hrt, ns_to_ktime(t->sticks * resolution)); + snd_timer_interrupt(stime->timer, t->sticks * oruns); if (!atomic_read(&stime->running)) return HRTIMER_NORESTART;

2 3

[alsa-devel] [PATCH 0/2] LaCie Firewire Speakers/Griffin FireWave support
by Clemens Ladisch 08 Feb '11

08 Feb '11

This driver version is, I hope, finished enough so that I can commit it soon. The FireWave's low-frequency processing makes me believe that this device is prepared to accept two- and four-channel data, so I've enabled this in the driver; but I'd still like to actually know if it works. (If it does, adding support for the AC-3 decoding will be possible too.) I haven't yet looked into volume controls. Jay, are you OK with "Tested-by: Jay Fenlason <fenlason(a)redhat.com>"? Stefan, if those firewire core bits are worth your notice :) , please give an Acked-by for them. Regards, Clemens

2 10

[alsa-devel] ASoC updates for 2.6.39
by Mark Brown 08 Feb '11

08 Feb '11

The following changes since commit 273de37655369e57919f19e157fafb2b4b1e4472: Merge branch 'for-2.6.39' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6 into for-2.6.39 (2011-02-01 14:55:10 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.39 Alexander Sverdlin (1): ASoC: CS4271: Move Chip Select control out of the CODEC code. Dan Carpenter (1): ASoC: soc-cache: dereferencing before checking Dimitris Papastamos (1): ASoC: soc-core: Support debugfs entries larger than PAGE_SIZE bytes Janusz Krzysztofik (1): ASoC: fill in snd_soc_pcm_runtime.card before calling snd_soc_dai_link.init() Lars-Peter Clausen (1): ASoC: codecs: wm8753: Fix DAI mode switching Mark Brown (6): ASoC: Update PM ifdefs for exported suspend/resume Merge branch 'for-2.6.38' into for-2.6.39 ASoC: Sort ALC5623 in Kconfig and Makefile ASoC: Create an AIF1ADCDAT signal widget to match AIF2 ASoC: Improve WM8994 digital power sequencing Merge branch 'for-2.6.38' into for-2.6.39 Mika Westerberg (1): ASoC: ep93xx-ac97: remove extra empty line Sven Neumann (1): ASoC: PXA: formatting Vaibhav Bedia (1): asoc: davinci: da830/omap-l137: correct cpu_dai_name Vinod Koul (1): ASoC: mid-x86: Fix dependency on intel_sst driver include/sound/cs4271.h | 1 - sound/soc/codecs/Makefile | 2 +- sound/soc/codecs/cs4271.c | 22 +--- sound/soc/codecs/wm8753.c | 296 ++++++++++++++++----------------------- sound/soc/codecs/wm8994.c | 26 +++- sound/soc/davinci/davinci-evm.c | 18 ++- sound/soc/ep93xx/ep93xx-ac97.c | 1 - sound/soc/mid-x86/Kconfig | 2 +- sound/soc/pxa/raumfeld.c | 16 +- sound/soc/soc-cache.c | 25 ++-- sound/soc/soc-core.c | 114 ++++++++++----- 11 files changed, 258 insertions(+), 265 deletions(-)

2 1

[alsa-devel] ASoC updates for 2.6.38
by Mark Brown 08 Feb '11

08 Feb '11

The following changes since commit f019ee5feb344ff0b22b58df4568676295aae14f: ASoC: CX20442: fix NULL pointer dereference (2011-02-01 14:13:56 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.38 Janusz Krzysztofik (1): ASoC: fill in snd_soc_pcm_runtime.card before calling snd_soc_dai_link.init() Mark Brown (2): ASoC: Create an AIF1ADCDAT signal widget to match AIF2 ASoC: Improve WM8994 digital power sequencing Vaibhav Bedia (1): asoc: davinci: da830/omap-l137: correct cpu_dai_name sound/soc/codecs/wm8994.c | 26 ++++++++++++++++++++++---- sound/soc/davinci/davinci-evm.c | 18 +++++++++++++++--- sound/soc/soc-core.c | 2 +- 3 files changed, 38 insertions(+), 8 deletions(-)

2 1

Re: [alsa-devel] [Alsa-user] hda intel alc889 broken since 2.6.36.2
by Paul Menzel 08 Feb '11

08 Feb '11

Dear Andrea, please do just send plain text messages to lists [2]. Also I am subscribed to the list, so you do not need to CC me. Am Dienstag, den 08.02.2011, 08:36 +0100 schrieb Andrea Rizzolo: > On Tue, Feb 8, 2011 at 8:29 AM, Paul Menzel wrote: > > Am Montag, den 07.02.2011, 18:12 +0100 schrieb Andrea Rizzolo: > > > Hi, my hda intel card is broken since kernel 2.6.36.2. it looks correctly > > > recognized, but it plays no sound at all. Same problem with 2.6.36.3 and > > > 2.6.37, instead it works correctly with kernels up to 2.6.36.1 (same > > > config). > > > my /proc/asound/cards: > > > 0 [Intel ]: HDA-Intel - HDA Intel > > > HDA Intel at 0xf0420000 irq 22 > > > > please read the Wiki pages [1] and attach the output of `alsa-info.sh` > > from the working setup and the non-working setup. > > > > What GNU/Linux distribution do you use? According to your report in the BTS, you are using Arch Linux. > Sorry, you are right. Here I provide full details: > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5267 Unfortunately most ALSA developers do not use the BTS but the documentation is not updated. :( I am attaching the differences to this message. With Linux kernel 2.6.37 your Webcam seems to be detected. Could you try if the volumes are up and the correct outputs are used. I am moving this thread to alsa-devel [3][4] since I have the experience that you will more likely get an answer there. Thanks, Paul > > [1] http://alsa-project.org/main/index.php/Help_To_Debug [2] http://www2.cit.cornell.edu/computer/elist/text/google.html [3] http://alsa-project.org/main/index.php/Mailing-lists [4] http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

1 0

[alsa-devel] ALSA: Reasonable buffer size / where should it be implemented?
by Knut Petersen 08 Feb '11

08 Feb '11

I use a RME Digi 96 PAD audio card, and I do have buffer overrun/underrun problems if I use the standard rme96c linux driver. I need a simple recording machine. It should not fail if e.g. cron starts updatedb or if I start a make -j 15 icecream compile job and decide to surf the internet while I record the digital satellite radio 48kHz stream. There is a lot of information about xrun problems, but somehow that information either does not help to prevent xruns on my system, is outdated, or asks for system changes I do not accept. No, JACK does not help. No, I do not need low latency. No, I don't want to switch to rt kernels. No, I don't want to use an audio PC without X, without cron, network, etc. The hardware provides independent 64k ringbuffers for capture and playback, that's not more than 85msec for a 96 kHz / 2 channel / 32 bit setup or ADAT. That's simply not enough for reliable operation. My private solution is a rme96.c that kmallocs 4 MB software buffers for capture and playback, data transfer between software and hardware buffer in the interrupt service routine. That does efficiently prevent xruns even on a really loaded system. But I don't know if that is the right way to go. Wouldn't it be better if there would be an (optional) software buffer one layer above the hardware driver? That would increase reliability for all audio hardware with insufficient hardware buffers. Is there any other audio hardware with similar small buffers? Has somebody already written an "extended alsa buffer" patch? Did I miss something? To put it into one question: How much buffer should be provided by an alsa hardware driver module? cu, Knut

2 2