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

[alsa-devel] ASoC updates for 2.6.40
by Mark Brown 26 May '11

26 May '11

The following changes since commit de0853c000aa3b5c9983d066c137e5dc9c8355a0: Merge branch 'topic/asoc' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 into for-2.6.40 (2011-05-22 10:31:51 +0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.40 These are all small, targetted fixes or just plain trivial. Axel Lin (1): ASoC: wm1250-ev1: Define "WM1250 Output" with SND_SOC_DAPM_OUTPUT Daniel Mack (1): ASoC: fix raumfeld platform Jarkko Nikula (1): ASoC: Fix power down for widgetless per-card DAPM context case Jesper Juhl (1): ASoC: Remove duplicate linux/delay.h inclusion. Liam Girdwood (2): ASoC: core - fix module reference counting for CPU DAIs ASoC: core - remove superfluous new line. Nicolas Ferre (2): ASoC: wm8731: fix wm8731_check_osc() connected condition ASoC: sam9g20_wm8731: use the proper SYSCKL value sound/soc/atmel/sam9g20_wm8731.c | 2 +- sound/soc/codecs/wm1250-ev1.c | 2 +- sound/soc/codecs/wm8731.c | 2 +- sound/soc/codecs/wm8915.c | 1 - sound/soc/pxa/raumfeld.c | 92 ++++++++++++++++++++++++-------------- sound/soc/soc-core.c | 8 ++-- sound/soc/soc-dapm.c | 2 +- 7 files changed, 66 insertions(+), 43 deletions(-)

2 1

[alsa-devel] No HDMI audio output, nVidia audio not listed in lspci
by Joost Verdoorn 26 May '11

26 May '11

Hi there, After asking around on the IRC it was recommended to me that I should take my problem to the alsa-devel mailing list. So here goes. When I ran Windows (1 year+ ago) I never tried HDMI audio output, or any HDMI output for that matter. Therefore I cannot verify that HDMI audio worked in the first place. However, my GPU, and more specifically, my laptop, is specced to be able to deliver audio through HDMI. I've been looking on and off for a solution to this problem for a couple of months now, but nowhere I found a solution to the specific symptoms that I'm having. My laptop in a nutshell: Machine: HP Compaq 8510w Mobile Workstation Chipset: Mobile Intel PM965 with 800-MHz front side bus GPU: NVIDIA Quadro FX 570M graphics with up to 256MB dedicated memory (512 MB TurboCache) CPU: Intel Core 2 Duo Processor T9300 (2.50 GHz, 6 MB L2 cache, 800 MHz FSB) OS: Linux x86-64 Ubuntu 11.04 Natty Narwhal nVidia Driver Version: 270.41.06 Output of alsa-info: http://paste.ubuntu.com/613101/ Output of lspci: http://paste.ubuntu.com/613123/ I really hope this is the right place for me to find a solution, with your help, and I thank you all for taking the time to read this email. Joost Verdoorn

4 5

[alsa-devel] [PATCH] ASoC: Fix dapm_is_shared_kcontrol so everything isn't shared
by Stephen Warren 26 May '11

26 May '11

Commit af46800 ("ASoC: Implement mux control sharing") introduced function dapm_is_shared_kcontrol. When this function returns true, the naming of DAPM controls is derived from the kcontrol_new. Otherwise, the name comes from the widget (and possibly a widget's naming prefix). A bug in the implementation of dapm_is_shared_kcontrol made it return 1 in all cases. Hence, that commit caused a change in control naming for all controls instead of just shared controls. Specifically, a control is always considered shared because it is always compared against itself. Solve this by never comparing against the widget containing the control being created. I tested that with the Tegra WM8903 driver: * Shared is now mostly 0 as expected, and sometimes 1. * The expected controls are still generated after this change. Howwever, I don't have any systems that have a widget/control naming prefix, so I can't test that aspect. Reported-by: Liam Girdwood <lrg(a)ti.com> Root-caused-by: Jarkko Nikula <jhnikula(a)gmail.com> Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/soc-dapm.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 456617e..5397699 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -325,6 +325,7 @@ static int dapm_connect_mixer(struct snd_soc_dapm_context *dapm, } static int dapm_is_shared_kcontrol(struct snd_soc_dapm_context *dapm, + struct snd_soc_dapm_widget *kcontrolw, const struct snd_kcontrol_new *kcontrol_new, struct snd_kcontrol **kcontrol) { @@ -334,6 +335,8 @@ static int dapm_is_shared_kcontrol(struct snd_soc_dapm_context *dapm, *kcontrol = NULL; list_for_each_entry(w, &dapm->card->widgets, list) { + if (w == kcontrolw) + continue; for (i = 0; i < w->num_kcontrols; i++) { if (&w->kcontrol_news[i] == kcontrol_new) { if (w->kcontrols) @@ -468,7 +471,7 @@ static int dapm_new_mux(struct snd_soc_dapm_context *dapm, return -EINVAL; } - shared = dapm_is_shared_kcontrol(dapm, &w->kcontrol_news[0], + shared = dapm_is_shared_kcontrol(dapm, w, &w->kcontrol_news[0], &kcontrol); if (kcontrol) { wlist = kcontrol->private_data; -- 1.7.0.4 nvpublic

2 5

[alsa-devel] [PATCH for 2.6.40] ASoC: Fix power down for widgetless per-card DAPM context case
by Jarkko Nikula 26 May '11

26 May '11

Commit 52ba67b ("ASoC: Force all DAPM contexts into the same bias state") powers up all the DAPM contexts in a card if any DAPM context becomes active. Unfortunately power down newer happens if per-card DAPM context doesn't have any widgets. Reason for this is that power state of per-card DAPM context without widgets is never cleared and thus all the DAPM contexts remain permanently active. Test for widgetless calling DAPM context in dapm_power_widgets() doesn't work for per-card DAPM context since power change is never originating from widgetless per-card DAPM context. Fix this by pre-clearing power state flag of non-codec DAPM context at the beginning of power sequence. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- sound/soc/soc-dapm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 456617e..999bb08 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -1110,7 +1110,7 @@ static int dapm_power_widgets(struct snd_soc_dapm_context *dapm, int event) trace_snd_soc_dapm_start(card); list_for_each_entry(d, &card->dapm_list, list) - if (d->n_widgets) + if (d->n_widgets || d->codec == NULL) d->dev_power = 0; /* Check which widgets we need to power and store them in -- 1.7.4.4

3 2

Re: [alsa-devel] [PATCH] ASoC: wm1250-ev1: Define "WM1250 Output" with SND_SOC_DAPM_OUTPUT
by Mark Brown 26 May '11

26 May '11

On Thu, May 26, 2011 at 10:54:12AM +0800, Axel Lin wrote: > Codec output pin should be defined with SND_SOC_DAPM_OUTPUT. Applied, thanks.

1 0

[alsa-devel] [PATCH] ASoC: core: Don't schedule deferred_resume_work twice
by Stephen Warren 26 May '11

26 May '11

For cards that have two or more DAIs, snd_soc_resume's loop over all DAIs ends up calling schedule_work(deferred_resume_work) once per DAI. Since this is the same work item each time, the 2nd and subsequent calls return 0 (work item already queued), and trigger the dev_err message below stating that a work item may have been lost. Solve this by adjusting the loop to simply calculate whether to run the resume work immediately or defer it, and then call schedule work (or not) one time based on that. Note: This has not been tested in mainline, but only in chromeos-2.6.38; mainline doesn't support suspend/resume on Tegra, nor does the mainline Tegra ASoC driver contain multiple DAIs. It has been compile-checked in mainline. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/soc-core.c | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index a477e21..c261eeb 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1256,7 +1256,7 @@ static void soc_resume_deferred(struct work_struct *work) int snd_soc_resume(struct device *dev) { struct snd_soc_card *card = dev_get_drvdata(dev); - int i; + int i, ac97_control = 0; /* AC97 devices might have other drivers hanging off them so * need to resume immediately. Other drivers don't have that @@ -1265,14 +1265,15 @@ int snd_soc_resume(struct device *dev) */ for (i = 0; i < card->num_rtd; i++) { struct snd_soc_dai *cpu_dai = card->rtd[i].cpu_dai; - if (cpu_dai->driver->ac97_control) { - dev_dbg(dev, "Resuming AC97 immediately\n"); - soc_resume_deferred(&card->deferred_resume_work); - } else { - dev_dbg(dev, "Scheduling resume work\n"); - if (!schedule_work(&card->deferred_resume_work)) - dev_err(dev, "resume work item may be lost\n"); - } + ac97_control |= cpu_dai->driver->ac97_control; + } + if (ac97_control) { + dev_dbg(dev, "Resuming AC97 immediately\n"); + soc_resume_deferred(&card->deferred_resume_work); + } else { + dev_dbg(dev, "Scheduling resume work\n"); + if (!schedule_work(&card->deferred_resume_work)) + dev_err(dev, "resume work item may be lost\n"); } return 0; -- 1.7.0.4

3 2

[alsa-devel] [PATCH] ASoC: tlv320aic3x: Add correct hw registers to Line1 cross connect muxes
by Jarkko Nikula 26 May '11

26 May '11

Commit af46800 ("ASoC: Implement mux control sharing") revealed that "Left Line1[L | R] Mux" and "Right Line1[L | R] Mux" widgets were pointing to the same kcontrols and codec registers and thus soc-core falsely detected them as shared controls. This is actually wrong since there are separate registers in hardware that configure Line1L to RADC and Line1R to LADC cross connects so these muxes should not be shared. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- sound/soc/codecs/tlv320aic3x.c | 34 +++++++++++++++++++++------------- 1 files changed, 21 insertions(+), 13 deletions(-) diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index 789453d..0963c4c 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -226,11 +226,13 @@ static const char *aic3x_adc_hpf[] = #define RDAC_ENUM 1 #define LHPCOM_ENUM 2 #define RHPCOM_ENUM 3 -#define LINE1L_ENUM 4 -#define LINE1R_ENUM 5 -#define LINE2L_ENUM 6 -#define LINE2R_ENUM 7 -#define ADC_HPF_ENUM 8 +#define LINE1L_2_L_ENUM 4 +#define LINE1L_2_R_ENUM 5 +#define LINE1R_2_L_ENUM 6 +#define LINE1R_2_R_ENUM 7 +#define LINE2L_ENUM 8 +#define LINE2R_ENUM 9 +#define ADC_HPF_ENUM 10 static const struct soc_enum aic3x_enum[] = { SOC_ENUM_SINGLE(DAC_LINE_MUX, 6, 3, aic3x_left_dac_mux), @@ -238,6 +240,8 @@ static const struct soc_enum aic3x_enum[] = { SOC_ENUM_SINGLE(HPLCOM_CFG, 4, 3, aic3x_left_hpcom_mux), SOC_ENUM_SINGLE(HPRCOM_CFG, 3, 5, aic3x_right_hpcom_mux), SOC_ENUM_SINGLE(LINE1L_2_LADC_CTRL, 7, 2, aic3x_linein_mode_mux), + SOC_ENUM_SINGLE(LINE1L_2_RADC_CTRL, 7, 2, aic3x_linein_mode_mux), + SOC_ENUM_SINGLE(LINE1R_2_LADC_CTRL, 7, 2, aic3x_linein_mode_mux), SOC_ENUM_SINGLE(LINE1R_2_RADC_CTRL, 7, 2, aic3x_linein_mode_mux), SOC_ENUM_SINGLE(LINE2L_2_LADC_CTRL, 7, 2, aic3x_linein_mode_mux), SOC_ENUM_SINGLE(LINE2R_2_RADC_CTRL, 7, 2, aic3x_linein_mode_mux), @@ -490,12 +494,16 @@ static const struct snd_kcontrol_new aic3x_right_pga_mixer_controls[] = { }; /* Left Line1 Mux */ -static const struct snd_kcontrol_new aic3x_left_line1_mux_controls = -SOC_DAPM_ENUM("Route", aic3x_enum[LINE1L_ENUM]); +static const struct snd_kcontrol_new aic3x_left_line1l_mux_controls = +SOC_DAPM_ENUM("Route", aic3x_enum[LINE1L_2_L_ENUM]); +static const struct snd_kcontrol_new aic3x_right_line1l_mux_controls = +SOC_DAPM_ENUM("Route", aic3x_enum[LINE1L_2_R_ENUM]); /* Right Line1 Mux */ -static const struct snd_kcontrol_new aic3x_right_line1_mux_controls = -SOC_DAPM_ENUM("Route", aic3x_enum[LINE1R_ENUM]); +static const struct snd_kcontrol_new aic3x_right_line1r_mux_controls = +SOC_DAPM_ENUM("Route", aic3x_enum[LINE1R_2_R_ENUM]); +static const struct snd_kcontrol_new aic3x_left_line1r_mux_controls = +SOC_DAPM_ENUM("Route", aic3x_enum[LINE1R_2_L_ENUM]); /* Left Line2 Mux */ static const struct snd_kcontrol_new aic3x_left_line2_mux_controls = @@ -535,9 +543,9 @@ static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = { &aic3x_left_pga_mixer_controls[0], ARRAY_SIZE(aic3x_left_pga_mixer_controls)), SND_SOC_DAPM_MUX("Left Line1L Mux", SND_SOC_NOPM, 0, 0, - &aic3x_left_line1_mux_controls), + &aic3x_left_line1l_mux_controls), SND_SOC_DAPM_MUX("Left Line1R Mux", SND_SOC_NOPM, 0, 0, - &aic3x_left_line1_mux_controls), + &aic3x_left_line1r_mux_controls), SND_SOC_DAPM_MUX("Left Line2L Mux", SND_SOC_NOPM, 0, 0, &aic3x_left_line2_mux_controls), @@ -548,9 +556,9 @@ static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = { &aic3x_right_pga_mixer_controls[0], ARRAY_SIZE(aic3x_right_pga_mixer_controls)), SND_SOC_DAPM_MUX("Right Line1L Mux", SND_SOC_NOPM, 0, 0, - &aic3x_right_line1_mux_controls), + &aic3x_right_line1l_mux_controls), SND_SOC_DAPM_MUX("Right Line1R Mux", SND_SOC_NOPM, 0, 0, - &aic3x_right_line1_mux_controls), + &aic3x_right_line1r_mux_controls), SND_SOC_DAPM_MUX("Right Line2R Mux", SND_SOC_NOPM, 0, 0, &aic3x_right_line2_mux_controls), -- 1.7.4.4

2 1

[alsa-devel] sound/trivial: some little typo and little fix
by Nicolas Ferre 26 May '11

26 May '11

Hi, This is a tiny patch series with two typos and one error path fix. More interesting stuff will come ;-) Best regards, -- Nicolas Ferre

3 5

[alsa-devel] Negative volume steps?
by Tanu Kaskinen 26 May '11

26 May '11

Hi, If a driver claims that the lowest volume step (integer step, not dB) of a volume element is -126 and the highest step is 0, is the driver broken? I'm asking, because apparently there are such drivers, but Pulseaudio currently assumes that the volume steps are never negative. -- Tanu

3 3

[alsa-devel] about ioctl calls
by Lorenzo Fundaró 26 May '11

26 May '11

Hi folks, I have a program that constantly make ioctl calls like this: ioctl(4, 0x4122, 0x8b703) ioctl(4, 0x4122, 0xbfb65768) I suspect that this call pertains to ALSA, since I have straced other programs that play music and they always use in the ioctl request field the 0x4122 code. I am interested on finding out what's in the third argument of the ioctl call, is it a sort of struct that contains the audio samples ? Thanks in advance, Lorenzo Fundaró García Université de Technologie de Compiègne Génie Informatique

2 2