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

Re: [alsa-devel] ALSA 1.0.29 release
by humbert.olivier.1＠free.fr 26 Feb '15

26 Feb '15

Congratulations to everyone who was involved in this. Merci, Olivier

1 0

[alsa-devel] New alsa-lib release plans?
by Jurgen Kramer 26 Feb '15

26 Feb '15

It has been a while since the last ALSA lib release. What are the plans for 1.0.28.1 or 1.0.29? There are fixes and enhancements since 1.0.28 which would be nice to find in a production release. Jurgen

2 2

Re: [alsa-devel] [ALSA] ca0106: power down SPI DAC channels when not in use
by Dan Carpenter 26 Feb '15

26 Feb '15

Hello Trent Piepho, The patch 485100706b4b: "[ALSA] ca0106: power down SPI DAC channels when not in use" from Jul 25, 2007, leads to the following static checker warning: sound/pci/ca0106/ca0106_main.c:601 snd_ca0106_pcm_open_playback_channel() warn: bool is not less than zero. sound/pci/ca0106/ca0106_main.c 597 598 /* Front channel dac should already be on */ 599 if (channel_id != PCM_FRONT_CHANNEL) { 600 err = snd_ca0106_pcm_power_dac(chip, channel_id, 1); Because of snd_ca0106_spi_write() then this function appears to return zero on success and 1 on failure. That's very strange. None of the callers expect a 1 return. If they care about the return code then they expect negative error codes. 601 if (err < 0) 602 return err; 603 } 604 regards, dan carpenter

1 0

Re: [alsa-devel] Intel HDA / ALC662 analog surround problem
by Raymond Yau 26 Feb '15

26 Feb '15

> > > You have to post the output of alsa-info.sh > > Please see the attached file. 0.655493] sound hdaudioC1D0: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line [ 0.655494] sound hdaudioC1D0: speaker_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 0.655495] sound hdaudioC1D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 0.655496] sound hdaudioC1D0: mono: mono_out=0x0 [ 0.655496] sound hdaudioC1D0: dig-out=0x1e/0x0 [ 0.655497] sound hdaudioC1D0: inputs: [ 0.655498] sound hdaudioC1D0: Front Mic=0x19 [ 0.655499] sound hdaudioC1D0: Rear Mic=0x18 [ 0.655499] sound hdaudioC1D0: Line=0x1a This is a known bug of hda_generic.c for those desktop with internal speaker and three audio jacks at rear panel (e.g. those lenovo thinkcenter with alc66x codec) The driver prefer to assign volume control/dac to headphone, line out and internal speaker instead of line out and the other two multi io jacks The workaround is to change the internal speaker as not connected node 0x15 or You need to increase badness of multi io so that driver select multi io as the best config > > > The channel mode should be automatically added for those desktop with three > > audio jacks (green line out, blue line in and pink mic) at rear panel > > Although I do have these jacks, there unfortunately isn't a channel mode. > > > either your computer BIOS does not set the correct pin default or it can be > > disabled by hint > > Do you really mean "disabled" or do you mean to enable them by hint? > > As you can see I don't have a hwC1D0/hints (and no reconfig), so I cannot try > setting multi_io to make the driver re-configuring itself. Would an early > patching make sense (or maybe I missing a kernel config option for the > hints)? > > If I only knew more about these "pins" (there seem to be 11, from 0x12 to > 0x1e) I could try to add a model for the ALC66x since the existing ones > (mario, asus-mode?, etc) don't make any differences. >

2 2

Re: [alsa-devel] No sound and systemd journal filling when inserting headphones when power-saving is enabled
by Takashi Iwai 26 Feb '15

26 Feb '15

At Tue, 24 Feb 2015 22:26:32 +0000, Dang Sananikone wrote: > > On 24 February 2015 at 20:57, Takashi Iwai <tiwai(a)suse.de> wrote: > > > At Tue, 24 Feb 2015 20:11:58 +0000, > > Dang Sananikone wrote: > > > > > > Thanks, in that case I'll simply attach the files to this post. There are > > > two files: > > > > > > * alsa-info-notworking.txt: This is the alsa info generated when > > > power-saving is enabled and after "speaker-test" has been invoked. > > > * alsa-info-working.txt: This is the alsa info generated when > > power-saving > > > is disabled and after "speaker-test" has been invoked. > > > > > > > > > To reproduce the problem: > > > > > > Prerequisite: > > > Set "options snd_hda_intel power_save=1" > > > > > > Instructions: > > > 1. Boot up laptop. > > > 2. Insert headphone socket into jack. > > > 3. In terminal, type "speaker-test -c 2". > > > > > > Expected Result: > > > The speaker-test program hangs, and the systemd journal starts filling up > > > with "sound hdaudioC0D0: hda-codec: out of range cmd 0:1:716:ffffffff" > > > messages. > > > > OK, then try to pass power_save_controller=0 option to snd-hda-intel > > module. It might be that the controller gets screwed up by some > > reason by power-saving. > > > > If I've understood you correctly I've set the following options: "options > snd_hda_intel power_save=1 power_save_controller=0". > > Then I've plugged in my headphones before invoking speaker-test. With no > audio playing I hear a blip sound every second. Every second? Is this equal with the length you specified to power_save option? i.e. if you pass power_save=10, the frequency of blip noise changes, too? > Then I invoke "speaker-test -c 2" and I hear the speaker test audio I > expect to hear. The program does not hang. After killing the program and > with no audio playing I hear the blip sound every second. So, the problem was basically the HD-audio controller screwed up by the power-saving. BTW, didn't you see the same problem with the explicit suspend/resume (S3 and S4)? For testing it, try a bigger value in power_save so that you go to S3/S4 before the power save is triggered. > > If this still doesn't help, we need more logs. Build the kernel with > > tracing support, and get the HD-audio verb traces as > > Documentation/sound/alsa/HD-Audio.txt, section Tracepoints. > > > > > > Takashi > > > > Going back to this setting I set out to get the HD-audio verbs to provide > more information: "options snd_hda_intel power_save=1". > > I've attached the trace file which was generated after following your > instructions (I think the kernel already had tracing support enabled > judging by the /proc/config.gz config parameters). The trace already shows the bad read from the controller, so it's likely an issue in the HDA controller and/or communication. In anyway, below is a patch to disable runtime PM of the controller again. It's equivalent as passing power_save_controller=1. Could you give it a test? thanks, Takashi -- 8< -- From: Takashi Iwai <tiwai(a)suse.de> Subject: [PATCH] ALSA: hda - Disable runtime PM for Panther Point again This is essentially a partial revert of the commit [b1920c21102a: 'ALSA: hda - Enable runtime PM on Panther Point']. There was a bug report showing the HD-audio bus hang during runtime PM on HP Spectre XT. Reported-by: Dang Sananikone <dang.sananikone(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 36d2f20db7a4..4ca3d5d02436 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1966,7 +1966,7 @@ static const struct pci_device_id azx_ids[] = { .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM }, /* Panther Point */ { PCI_DEVICE(0x8086, 0x1e20), - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH }, + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM }, /* Lynx Point */ { PCI_DEVICE(0x8086, 0x8c20), .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH }, -- 2.3.0

2 2

[alsa-devel] About iMX6SL AUDMUX (port 7) and SSI3
by Xuebing Wang 26 Feb '15

26 Feb '15

Hi community: I am working on ASoC based sound driver for our iMX6SL based board. There are 3 I2S peripherals on the board: - iMX6SL pads AUD3 (as in AUD3_TXC), connect to peripheral Codec3 - iMX6SL pads AUD5 connect to Codec5 - iMX6SL pads Aud6, connect to Codec6 Q1) Is internal SSI3 controller (ssi@02030000) actually *hard-wired* to AUDMUX port 7? Q2) Can I configure audmux as below? - External AUD3 -> internal SSI3 (which is actually audmux port 7?) - External AUD5 -> internal SSI2 (ssi@0202c000) - External AUD6 -> internal SSI1 (ssi@02028000) Thanks. -- Xuebing

2 5

[alsa-devel] [PATCH v2 RESEND] ASoC: OMAP: mcbsp: ensure that CLKX and CLKR are not used as ouput pins when they are used as input clock for the SRG.
by Thomas Niederprüm 26 Feb '15

26 Feb '15

This patch fixes faulty behaviour in a setup where the input clock for the SRG is fed through the CLKR/CLKX pin but the McBSP is configured to be master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR/CLKX must not be configured as output pin. Otherwise the input clock is messed up horribly. This patch makes it possible to use the CLKR/CLKX pin rather than CLKS to inject a reference clock in setups where McBSP is master and not both rx and tx are used. However for this to work it has to be ensured that set_dai_sysclk() is called after set_dai_fmt(). This was tested on a beagleboard-xm using McBSP1 to drive a i2s DAC through the tx lines (CLKX,FSX,DX). Using this patch the CLKR pin is used to inject an external reference clock. Signed-off-by: Thomas Niederprüm <niederp(a)physik.uni-kl.de> Acked-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- changes since v1: - added comments explaining the bit masking to disable output on CLKR/CLKX sound/soc/omap/omap-mcbsp.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index bd3ef2a..662269c 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -530,8 +530,19 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai, case OMAP_MCBSP_SYSCLK_CLKX_EXT: regs->srgr2 |= CLKSM; + regs->pcr0 |= SCLKME; + /* + * If McBSP is master but yet the CLKX/CLKR pin drives the SRG, + * disable output on those pins. This enables to inject the + * reference clock through CLKX/CLKR. For this to work + * set_dai_sysclk() _needs_ to be called after set_dai_fmt(). + */ + regs->pcr0 &= ~CLKXM; + break; case OMAP_MCBSP_SYSCLK_CLKR_EXT: regs->pcr0 |= SCLKME; + /* Disable ouput on CLKR pin in master mode */ + regs->pcr0 &= ~CLKRM; break; default: err = -ENODEV; -- 2.1.1

2 1

[alsa-devel] [Patch] ASoC: max98357a: Use standard DAI names
by Kenneth Westfield 26 Feb '15

26 Feb '15

From: Kenneth Westfield <kwestfie(a)codeaurora.org> Use the standard naming convention for the codec DAI. Signed-off-by: Kenneth Westfield <kwestfie(a)codeaurora.org> --- based on next/topic/max98357a branch sound/soc/codecs/max98357a.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c index 4ee23fbc4e1237268ae104319a9cfe4fc369934e..bf3e933ee895752352e90f610195f39fc6cc058f 100644 --- a/sound/soc/codecs/max98357a.c +++ b/sound/soc/codecs/max98357a.c @@ -85,9 +85,9 @@ static struct snd_soc_dai_ops max98357a_dai_ops = { }; static struct snd_soc_dai_driver max98357a_dai_driver = { - .name = "max98357a", + .name = "HiFi", .playback = { - .stream_name = "max98357a-playback", + .stream_name = "HiFi Playback", .formats = SNDRV_PCM_FMTBIT_S16 | SNDRV_PCM_FMTBIT_S24 | SNDRV_PCM_FMTBIT_S32, -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

Re: [alsa-devel] Adjust the the codec and dai_link close sequence
by Mark Brown 26 Feb '15

26 Feb '15

On Mon, Jan 19, 2015 at 06:22:00PM -0800, Zhao Ye wrote: Please fix your mailer to word wrap within paragraphs at something confortably less than 80 columns, it makes your messages much easier to read. > We meet a issue, when we close the audio path, we found the dai link > will closed after the codec. And the codec dai register will write > fail. This is because our audio codec is a I2C device, and the codec > dai’s dai_link register is in the I2C device. If we close the codec > chip fisrt, The whole I2C chip’s power will be off, then we write the > dai_link’s register will be fail. I'm a little unclear on the exact scenario here but this sounds like the CODEC driver is probably buggy - it should either be putting the device regmap into cache only mode when powered off (if there is no need for the writes to take immediate effect) or not powering off until after whatever cleanup is being done in the DAI is done. Without knowing more about what the CODEC is trying to do at each stage it's hard to say exactly but it doesn't sound like an ordering issue. > So I think we should adjust the > rtd->dai_link->ops->shutdown(substream); before to > codec_dai->driver->ops->shutdown(substream, codec_dai); in the > soc_pcm_close() function. Doing that then means that we run into trouble on systems where the CODEC somehow depends on clocks from the DAI (which does happen)... really there's no perfect ordering here and attempting to shuffle this stuff around is likely to create bugs in other places as their dependencies on the current ordering get exposed. If there is some core work needed it would be better to do something that explicitly shows the dependencies so we don't get this sort of fragility.

2 2

[alsa-devel] [PATCH 1/2] ASoC: rt5677: Correct the routing paths of that after IF1/2 DACx Mux
by Oder Chiou 26 Feb '15

26 Feb '15

The patch corrects the routing paths of that after IF1/2 DACx Mux Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- sound/soc/codecs/rt5677.c | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index ab62777..f87c929 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -3297,8 +3297,8 @@ static const struct snd_soc_dapm_route rt5677_dapm_routes[] = { { "IB45 Bypass Mux", "Bypass", "IB45 Mux" }, { "IB45 Bypass Mux", "Pass SRC", "IB45 Mux" }, - { "IB6 Mux", "IF1 DAC 6", "IF1 DAC6" }, - { "IB6 Mux", "IF2 DAC 6", "IF2 DAC6" }, + { "IB6 Mux", "IF1 DAC 6", "IF1 DAC6 Mux" }, + { "IB6 Mux", "IF2 DAC 6", "IF2 DAC6 Mux" }, { "IB6 Mux", "SLB DAC 6", "SLB DAC6" }, { "IB6 Mux", "STO4 ADC MIX L", "Stereo4 ADC MIXL" }, { "IB6 Mux", "IF4 DAC L", "IF4 DAC L" }, @@ -3306,8 +3306,8 @@ static const struct snd_soc_dapm_route rt5677_dapm_routes[] = { { "IB6 Mux", "STO2 ADC MIX L", "Stereo2 ADC MIXL" }, { "IB6 Mux", "STO3 ADC MIX L", "Stereo3 ADC MIXL" }, - { "IB7 Mux", "IF1 DAC 7", "IF1 DAC7" }, - { "IB7 Mux", "IF2 DAC 7", "IF2 DAC7" }, + { "IB7 Mux", "IF1 DAC 7", "IF1 DAC7 Mux" }, + { "IB7 Mux", "IF2 DAC 7", "IF2 DAC7 Mux" }, { "IB7 Mux", "SLB DAC 7", "SLB DAC7" }, { "IB7 Mux", "STO4 ADC MIX R", "Stereo4 ADC MIXR" }, { "IB7 Mux", "IF4 DAC R", "IF4 DAC R" }, @@ -3648,15 +3648,15 @@ static const struct snd_soc_dapm_route rt5677_dapm_routes[] = { { "DAC1 FS", NULL, "DAC1 MIXL" }, { "DAC1 FS", NULL, "DAC1 MIXR" }, - { "DAC2 L Mux", "IF1 DAC 2", "IF1 DAC2" }, - { "DAC2 L Mux", "IF2 DAC 2", "IF2 DAC2" }, + { "DAC2 L Mux", "IF1 DAC 2", "IF1 DAC2 Mux" }, + { "DAC2 L Mux", "IF2 DAC 2", "IF2 DAC2 Mux" }, { "DAC2 L Mux", "IF3 DAC L", "IF3 DAC L" }, { "DAC2 L Mux", "IF4 DAC L", "IF4 DAC L" }, { "DAC2 L Mux", "SLB DAC 2", "SLB DAC2" }, { "DAC2 L Mux", "OB 2", "OutBound2" }, - { "DAC2 R Mux", "IF1 DAC 3", "IF1 DAC3" }, - { "DAC2 R Mux", "IF2 DAC 3", "IF2 DAC3" }, + { "DAC2 R Mux", "IF1 DAC 3", "IF1 DAC3 Mux" }, + { "DAC2 R Mux", "IF2 DAC 3", "IF2 DAC3 Mux" }, { "DAC2 R Mux", "IF3 DAC R", "IF3 DAC R" }, { "DAC2 R Mux", "IF4 DAC R", "IF4 DAC R" }, { "DAC2 R Mux", "SLB DAC 3", "SLB DAC3" }, @@ -3664,29 +3664,29 @@ static const struct snd_soc_dapm_route rt5677_dapm_routes[] = { { "DAC2 R Mux", "Haptic Generator", "Haptic Generator" }, { "DAC2 R Mux", "VAD ADC", "VAD ADC Mux" }, - { "DAC3 L Mux", "IF1 DAC 4", "IF1 DAC4" }, - { "DAC3 L Mux", "IF2 DAC 4", "IF2 DAC4" }, + { "DAC3 L Mux", "IF1 DAC 4", "IF1 DAC4 Mux" }, + { "DAC3 L Mux", "IF2 DAC 4", "IF2 DAC4 Mux" }, { "DAC3 L Mux", "IF3 DAC L", "IF3 DAC L" }, { "DAC3 L Mux", "IF4 DAC L", "IF4 DAC L" }, { "DAC3 L Mux", "SLB DAC 4", "SLB DAC4" }, { "DAC3 L Mux", "OB 4", "OutBound4" }, - { "DAC3 R Mux", "IF1 DAC 5", "IF1 DAC4" }, - { "DAC3 R Mux", "IF2 DAC 5", "IF2 DAC4" }, + { "DAC3 R Mux", "IF1 DAC 5", "IF1 DAC5 Mux" }, + { "DAC3 R Mux", "IF2 DAC 5", "IF2 DAC5 Mux" }, { "DAC3 R Mux", "IF3 DAC R", "IF3 DAC R" }, { "DAC3 R Mux", "IF4 DAC R", "IF4 DAC R" }, { "DAC3 R Mux", "SLB DAC 5", "SLB DAC5" }, { "DAC3 R Mux", "OB 5", "OutBound5" }, - { "DAC4 L Mux", "IF1 DAC 6", "IF1 DAC6" }, - { "DAC4 L Mux", "IF2 DAC 6", "IF2 DAC6" }, + { "DAC4 L Mux", "IF1 DAC 6", "IF1 DAC6 Mux" }, + { "DAC4 L Mux", "IF2 DAC 6", "IF2 DAC6 Mux" }, { "DAC4 L Mux", "IF3 DAC L", "IF3 DAC L" }, { "DAC4 L Mux", "IF4 DAC L", "IF4 DAC L" }, { "DAC4 L Mux", "SLB DAC 6", "SLB DAC6" }, { "DAC4 L Mux", "OB 6", "OutBound6" }, - { "DAC4 R Mux", "IF1 DAC 7", "IF1 DAC7" }, - { "DAC4 R Mux", "IF2 DAC 7", "IF2 DAC7" }, + { "DAC4 R Mux", "IF1 DAC 7", "IF1 DAC7 Mux" }, + { "DAC4 R Mux", "IF2 DAC 7", "IF2 DAC7 Mux" }, { "DAC4 R Mux", "IF3 DAC R", "IF3 DAC R" }, { "DAC4 R Mux", "IF4 DAC R", "IF4 DAC R" }, { "DAC4 R Mux", "SLB DAC 7", "SLB DAC7" }, -- 1.8.1.1.439.g50a6b54

2 3