December 2012 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] [PATCH 7/7] ASoC: tegra: add machine driver using wm9712 codec
by Stephen Warren 20 Dec '12

20 Dec '12

On 12/19/2012 04:17 PM, Lucas Stach wrote: > This adds a simple machine driver using the Wolfson wm9712 AC97 > codec. If the AC'97 code is going to be reworked to probe the CODEC rather than manually specify it in DT, then will this machine driver become generic for any AC'97 system, and hence you could rename the DT binding to nvidia,tegra-audio-ac97? > diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt > +- nvidia,audio-codec : The phandle of the WM9712 audio codec I wonder how you'll get that if you dynamically probe the AC'97 bus... > diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig > +config SND_SOC_TEGRA_WM9712 > + tristate "SoC Audio support for Tegra boards using a WM9712 codec" > + depends on SND_SOC_TEGRA I'd suggest making this depend on the Tegra AC97 module, or ARCH_TEGRA_2x_SOC instead, since it can only run on Tegra20. The AC'97 module has been removed on Tegra30 and replaced with an HD Audio controller instead. > + select SND_SOC_TEGRA20_AC97 if ARCH_TEGRA_2x_SOC That select (or a dependency as mentioned above) is always required. > + select SND_SOC_AC97_BUS Shouldn'y the AC'97 driver select that? > diff --git a/sound/soc/tegra/tegra_wm9712.c b/sound/soc/tegra/tegra_wm9712.c > +static int tegra_wm9712_init(struct snd_soc_pcm_runtime *rtd) > + snd_soc_dapm_force_enable_pin(dapm, "Mic Bias"); Hmm. I guess that potentially ties this driver to whichever CODECs actually expose a widget with that exact name... > +static int tegra_wm9712_remove(struct snd_soc_card *card) > +{ > + return 0; > +} Do you need to implement this at all if it does nothing? > +MODULE_LICENSE("GPL"); "GPL v2"

2 1

Re: [alsa-devel] [PATCH 6/7] ASoC: tegra: add ac97 host controller to device tree
by Stephen Warren 20 Dec '12

20 Dec '12

On 12/19/2012 04:17 PM, Lucas Stach wrote: > This adds the DT bindings and a default entry for the Tegra 2x > AC97 host controller. Everything here except the .dtsi file should be part of the previous patch. > diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt > +- nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number > + of the GPIO corresponding with the AC97 DAP _FS line Hmm, for I2S at least, FS (frame sync I assume) definitely is something that the audio controller itself drives. Are you absolutely sure that this should be represented as a GPIO here? > diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi > + tegra_ac97: ac97@70002000 { There's only 1 node named ac97, so you can leave out the unit address since it's not required to generate a unique node name. In other words just "ac97".

1 0

Re: [alsa-devel] [PATCH 1/7] ARM: tegra: add ac97 clock
by Stephen Warren 20 Dec '12

20 Dec '12

On 12/19/2012 04:17 PM, Lucas Stach wrote: > Add clock used by the AC97 host controller. This is going to conflict with Prashant's clock driver rework. Can you rebase it on top of that once it's checked in. That might be a couple weeks out though.

1 0

Re: [alsa-devel] [PATCH 4/7] ASoC: tegra: add function to set ac97 rate
by Stephen Warren 20 Dec '12

20 Dec '12

On 12/19/2012 04:17 PM, Lucas Stach wrote: > AC97 uses a fixed rate, unrelated to the sample rate. Add a function to > make the setup more trivial. Acked-by: Stephen Warren <swarren(a)nvidia.com>

1 0

Re: [alsa-devel] [PATCH 3/7] ASoC: tegra: setup DAP3<->DAC3 connection by default
by Stephen Warren 20 Dec '12

20 Dec '12

On 12/19/2012 04:17 PM, Lucas Stach wrote: > This connection is used by the AC97 controller. Acked-by: Stephen Warren <swarren(a)nvidia.com>

1 0

[alsa-devel] Fwd: Low volume with Realtek ALC 883.
by prasannatsmkumar 20 Dec '12

20 Dec '12

On Thu, Dec 20, 2012 at 11:07 PM, prasannatsmkumar <prasannatsmkumar(a)gmail.com> wrote: > Hi ALSA people, > > I am having a Realtek ALC 883 chip. The sound volume is very low > compared to what I hear in windows - I maintain same speaker volume > and play same audio. If I keep the volume as 10% in windows I have to > keep a volume of at least 25+% in Linux. Is there any way to improve > it? I have been seeing such a situation for past 4 or 5 years (from > Fedora 9 period till today). I have tried several distributions > (Fedora, Vector Linux, PC Linux OS, Ubuntu, Mint) and all have the > same behaviour. Currently I am running Ubuntu 11.10 with 3.5 kernel. > > $cat /proc/asound/version > Advanced Linux Sound Architecture Driver Version 1.0.25. > > Should I file a bug? If so in which component (kernel or pulseaudio)? > > Thanks in advance, > PrasannaKumar Resending this as this mail was bounced by alsa devel list. Please feel free to ask for information necessary to solve this issue. I have copied output of some commands that may be useful for understanding or digging this issue. dmesg | grep hda output: [ 30.648663] snd_hda_intel 0000:00:1b.0: >irq 43 for MSI/MSI-X [ 30.716741] hda_codec: ALC883: SKU not ready 0x411111f0 lspci -vvv output (only info related audio device is in mail all others are stripped): 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 01) Subsystem: Intel Corporation Device d605 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 43 Region 0: Memory at 501c0000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee0300c Data: 4189 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=80 Status: NegoPending- InProgress- Capabilities: [130 v1] Root Complex Link Desc: PortNumber=0f ComponentID=02 EltType=Config Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+ Addr: 00000000fed1c000 Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel amixer output: Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 13 [42%] [-27.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [0.00dB] [on] Front Right: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [0.00dB] Front Right: Playback 255 [100%] [0.00dB] Simple mixer control 'Front',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [0.00dB] [on] Front Right: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Front Mic',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [12.00dB] [off] Front Right: Playback 31 [100%] [12.00dB] [off] Simple mixer control 'Front Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 3 [100%] [30.00dB] Front Right: 3 [100%] [30.00dB] Simple mixer control 'Surround',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [0.00dB] [on] Front Right: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Center',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'LFE',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Line',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [12.00dB] [off] Front Right: Playback 31 [100%] [12.00dB] [off] Simple mixer control 'Beep',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 31 Front Left: Capture 8 [26%] [0.00dB] [on] Front Right: Capture 8 [26%] [0.00dB] [on] Simple mixer control 'Capture',1 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 31 Front Left: Capture 0 [0%] [-12.00dB] [off] Front Right: Capture 0 [0%] [-12.00dB] [off] Simple mixer control '2ch-Upmix Master',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 255 Front Left: 255 [100%] Front Right: 255 [100%] Simple mixer control 'Channel Mode',0 Capabilities: enum Items: '2ch' '4ch' '6ch' Item0: '2ch' Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Rear Mic' 'Front Mic' 'Line' Item0: 'Front Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Rear Mic' 'Front Mic' 'Line' Item0: 'Rear Mic' Simple mixer control 'Rear Mic',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Rear Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 2 [67%] [20.00dB] Front Right: 2 [67%] [20.00dB] Thanks and Regards, PrasannaKumar

1 1

[alsa-devel] Fwd: Low volume with Realtek ALC 883.
by prasannatsmkumar 20 Dec '12

20 Dec '12

Hi ALSA / pulseaudio people, Resending this as this mail was bounced by alsa devel list. I am having a Realtek ALC 883 chip. The sound volume is very low compared to what I hear in windows - I maintain same speaker volume and play same audio. If I keep the volume as 10% in windows I have to keep a volume of at least 25+% in Linux. Is there any way to improve it? I have been seeing such a situation for past 4 or 5 years (from Fedora 9 period till today). I have tried several distributions (Fedora, Vector Linux, PC Linux OS, Ubuntu, Mint) and all have the same behaviour. Currently I am running Ubuntu 11.10 with 3.5 kernel. $cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.25. Should I file a bug? If so in which component (kernel or pulseaudio)? Thanks in advance, PrasannaKumar

1 0

[alsa-devel] [PATCH RFT] ASoC: sta529: Fix update register bits in sta529_set_dai_fmt
by Axel Lin 20 Dec '12

20 Dec '12

Both the mask and mode settings are wrong in current code. According to the datasheet: S2PCFG0 (0x0A) BIT[3:1] DATA_FORMAT serial interface protocol format: 000: left Justified 001: I2S (default) 010: right justified 100: PCM no delay 101: PCM delay 111: DSP Thus fixes the defines for LEFT_J_DATA_FORMAT, I2S_DATA_FORMAT, and RIGHT_J_DATA_FORMAT. Also adds define for DATA_FORMAT_MSK. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- Hi Rajeev, I don't have this hardware, can you test this patch? Thanks, Axel sound/soc/codecs/sta529.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/sta529.c b/sound/soc/codecs/sta529.c index ab355c4..40c07be 100644 --- a/sound/soc/codecs/sta529.c +++ b/sound/soc/codecs/sta529.c @@ -74,9 +74,10 @@ SNDRV_PCM_FMTBIT_S32_LE) #define S2PC_VALUE 0x98 #define CLOCK_OUT 0x60 -#define LEFT_J_DATA_FORMAT 0x10 -#define I2S_DATA_FORMAT 0x12 -#define RIGHT_J_DATA_FORMAT 0x14 +#define DATA_FORMAT_MSK 0x0E +#define LEFT_J_DATA_FORMAT 0x00 +#define I2S_DATA_FORMAT 0x02 +#define RIGHT_J_DATA_FORMAT 0x04 #define CODEC_MUTE_VAL 0x80 #define POWER_CNTLMSAK 0x40 @@ -289,7 +290,7 @@ static int sta529_set_dai_fmt(struct snd_soc_dai *codec_dai, u32 fmt) return -EINVAL; } - snd_soc_update_bits(codec, STA529_S2PCFG0, 0x0D, mode); + snd_soc_update_bits(codec, STA529_S2PCFG0, DATA_FORMAT_MSK, mode); return 0; } -- 1.7.9.5

3 2

[alsa-devel] [PATCH] ASoC: pcm: allow backend hardware to be freed in pause state
by Patrick Lai 20 Dec '12

20 Dec '12

When front-end PCM session is in paused state, back-end PCM session will be put in paused state as well if given front-end PCM session is the only client of given back-end. Then, application closes front-end PCM session, DPCM framework will not allow back-end enters HW_FREE state so back-end will never get shutdown completely. Signed-off-by: Patrick Lai <plai(a)codeaurora.org> --- sound/soc/soc-pcm.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index ef22d0b..d340644 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1240,6 +1240,7 @@ static int dpcm_be_dai_hw_free(struct snd_soc_pcm_runtime *fe, int stream) if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PREPARE) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE) && + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP)) continue; -- 1.7.8.3 Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

3 2

[alsa-devel] [PATCH RFT] ASoC: arizona: Do proper shift for setting aif1 rate
by Axel Lin 20 Dec '12

20 Dec '12

ARIZONA_AIF1_RATE_MASK is 0x7800 /* AIF1_RATE - [14:11] */ Thus we need left shift ARIZONA_AIF1_RATE_SHIFT when setting aif1 rate. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/arizona.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index adf397b..38248a7 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -714,7 +714,8 @@ static int arizona_hw_params(struct snd_pcm_substream *substream, snd_soc_update_bits(codec, ARIZONA_ASYNC_SAMPLE_RATE_1, ARIZONA_ASYNC_SAMPLE_RATE_MASK, sr_val); snd_soc_update_bits(codec, base + ARIZONA_AIF_RATE_CTRL, - ARIZONA_AIF1_RATE_MASK, 8); + ARIZONA_AIF1_RATE_MASK, + 8 << ARIZONA_AIF1_RATE_SHIFT); break; default: arizona_aif_err(dai, "Invalid clock %d\n", dai_priv->clk); -- 1.7.9.5

2 1

Re: [alsa-devel] [PATCH] ASoC: dapm: Fix the unpaired runtime_get/put cases
by Mark Brown 20 Dec '12

20 Dec '12

On Thu, Dec 20, 2012 at 06:37:26AM +0000, Liu, Chuansheng wrote: > Meanwhile, is it useful to add one warning there for that case? > After all, in probing, set the bias to _STANDBY even idle_bias_off == 1, and calling get_runtime_sync(), it > will let the code more obscure. So giving a warning there to indicate the driver: > it is not suggested that in probing, set the bias to _STANDBY even idle_bias_off == 1. Probably, send a patch please. Like I say it is possible to start off in _STANDBY providing the driver grabs the runtime PM reference too but I can't think of any reason for doing that so the warning seems sensible.

1 0

Re: [alsa-devel] [PATCH 2/7] ASoC: allow wolfson wm9712 codec to be instantiated using device tree
by Mark Brown 20 Dec '12

20 Dec '12

On Thu, Dec 20, 2012 at 12:17:31AM +0100, Lucas Stach wrote: > static struct platform_driver wm9712_codec_driver = { > .driver = { > .name = "wm9712-codec", > .owner = THIS_MODULE, > + .of_match_table = wm9712_of_match, > }, No, this is really not a sane way of handling AC'97 at all. They're not platform devices, there is no sane reason why they should appear in the device tree as such. Really we ought to be just hotplugging them, AC'97 is perfectly enumerable.

1 0

[alsa-devel] Adding wm8962 support to mx6qsabresd
by Fabio Estevam 20 Dec '12

20 Dec '12

Hi, I am working on adding audio support to mx6qsabresd board, which contains a wm8962 codec. Here is the log with debug information turned on that I am getting so far: wm8962 0-001a: customer id 0 revision D wm8962 0-001a: read 25 => 8 wm8962 0-001a: read 25 => 8 wm8962 0-001a: read 25 => 8 wm8962 0-001a: read 25 => 8 wm8962 0-001a: read 26 => 8 wm8962 0-001a: read 26 => 8 wm8962 0-001a: read 26 => 8 wm8962 0-001a: read 26 => 8 wm8962 0-001a: read 22 => 9 wm8962 0-001a: read 22 => 9 wm8962 0-001a: read 22 => 9 wm8962 0-001a: read 22 => 9 wm8962 0-001a: read 22 => 9 wm8962 0-001a: read 22 => 9 wm8962 0-001a: read 3a => 0 wm8962 0-001a: read 3a => 0 wm8962 0-001a: read 39 => 0 wm8962 0-001a: read 39 => 0 wm8962 0-001a: read 64 => 0 wm8962 0-001a: read 64 => 0 wm8962 0-001a: read 64 => 0 wm8962 0-001a: read 64 => 0 wm8962 0-001a: read 64 => 0 wm8962 0-001a: read 64 => 0 wm8962 0-001a: read 65 => 0 wm8962 0-001a: read 65 => 0 wm8962 0-001a: read 65 => 0 wm8962 0-001a: read 65 => 0 wm8962 0-001a: read 65 => 0 wm8962 0-001a: read 65 => 0 wm8962 0-001a: read 64 => 0 wm8962 0-001a: read 64 => 0 wm8962 0-001a: read 65 => 0 wm8962 0-001a: read 65 => 0 wm8962 0-001a: read 69 => 0 wm8962 0-001a: read 69 => 0 wm8962 0-001a: read 69 => 0 wm8962 0-001a: read 69 => 0 wm8962 0-001a: read 69 => 0 wm8962 0-001a: read 69 => 0 wm8962 0-001a: read 6a => 0 wm8962 0-001a: read 6a => 0 wm8962 0-001a: read 6a => 0 wm8962 0-001a: read 6a => 0 wm8962 0-001a: read 6a => 0 wm8962 0-001a: read 6a => 0 wm8962 0-001a: read 69 => 0 wm8962 0-001a: read 69 => 0 wm8962 0-001a: read 6a => 0 wm8962 0-001a: read 6a => 0 wm8962 0-001a: read 200 => ffffffff wm8962 0-001a: read 201 => 0 wm8962 0-001a: read 202 => 0 wm8962 0-001a: read 203 => ffffffff wm8962 0-001a: read 204 => 8100 wm8962 0-001a: read 205 => 8100 wm8962 0-001a: DMIC not in use, disabling input: WM8962 Beep Generator as /devices/soc.0/2100000.aips-bus/21a0000.i2c/i2c-0/0-001a/input/input0 wm8962 0-001a: read 31 => ffffffff wm8962 0-001a: read 31 => ffffffff wm8962 0-001a: read 1a => 0 wm8962 0-001a: read 1a => 0 wm8962 0-001a: read 63 => 0 wm8962 0-001a: read 63 => 0 wm8962 0-001a: read 1a => 0 wm8962 0-001a: read 1a => 0 wm8962 0-001a: read 63 => 0 wm8962 0-001a: read 63 => 0 wm8962 0-001a: read 1a => 0 wm8962 0-001a: read 1a => 0 wm8962 0-001a: read 19 => 0 wm8962 0-001a: read 19 => 0 wm8962 0-001a: read 19 => 0 wm8962 0-001a: read 19 => 0 wm8962 0-001a: read 19 => 0 wm8962 0-001a: read 26 => 8 wm8962 0-001a: read 25 => 8 wm8962 0-001a: read 30 => ffffffff wm8962 0-001a: read 30 => ffffffff wm8962 0-001a: read 300 => 1c00 wm8962 0-001a: read 17 => 160 wm8962 0-001a: read 48 => 0 wm8962 0-001a: read 8 => ffffffff wm8962 0-001a: read 52 => 4 wm8962 0-001a: read 19 => 0 wm8962 0-001a: write a0 = 149 wm8962 0-001a: write a1 = 271 wm8962 0-001a: write a2 = 7 wm8962 0-001a: FLL configured for 24000000Hz->11289600Hz wm8962 0-001a: No audio clocks configured ... imx-wm8962 sound.14: wm8962 <-> 2028000.ssi mapping ok root@freescale /home$ ./aplay Front_Left.wav wm8962 0-001a: hw_params set BCLK 1411200Hz LRCLK 44100Hz wm8962 0-001a: wm8962->sysclk_rate = 11289600 wm8962 0-001a: wm8962->lrclk = 44100 wm8962 0-001a: Selected sysclk ratio 256 wm8962 0-001a: read 4 => ffffffff wm8962 0-001a: Failed to read DSPCLK: -1 wm8962 0-001a: read 3 => 100 wm8962 0-001a: write 3 = 100 wm8962 0-001a: ASoC: POST_PMU: HPOUTR PGA event failed: -5 wm8962 0-001a: read 29 => 100 wm8962 0-001a: write 29 = 100 wm8962 0-001a: ASoC: POST_PMU: SPKOUTR PGA event failed: -5 wm8962 0-001a: read 2 => 100 wm8962 0-001a: write 2 = 100 wm8962 0-001a: ASoC: POST_PMU: HPOUTL PGA event failed: -5 wm8962 0-001a: read 28 => 100 wm8962 0-001a: write 28 = 100 wm8962 0-001a: ASoC: POST_PMU: SPKOUTL PGA event failed: -5 wm8962 0-001a: read 42 => ffffffff wm8962 0-001a: Failed to read DCS status: -1 wm8962 0-001a: DC servo complete after 1ms Playing WAVE 'Front_Left.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono Any idea of why register 4 and 42 read fails? wm8962 0-001a: read 4 => ffffffff wm8962 0-001a: Failed to read DSPCLK: -1 wm8962 0-001a: read 42 => ffffffff wm8962 0-001a: Failed to read DCS status: -1 Any suggestion is appreciated. Thanks, Fabio Estevam

3 2

[alsa-devel] how to check the CODEC registers vaule
by Zhang wei 20 Dec '12

20 Dec '12

Hello everyone,I am confused again : ( I read the wm8985.pdf and found the description: If the address is not recognised or the R/W bit is '1' when operating in write only mode,the WM8985 returns to the idle conditon and waits for a new start condition and valid address. Does it mean the wm8985 registers write only, can not be read? I found other kinds of codec datasheet same as it. Is it necessary to read back the value from the register ? Thanks a lot. Best Regards zw

1 0

[alsa-devel] [PATCH 1/2] Revert "ALSA: usb-audio: ignore delay calculation for capture stream"
by Pierre-Louis Bossart 19 Dec '12

19 Dec '12

This reverts commit 3f94fad09538ec988919ec3f371841182df71d04. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/usb/pcm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index c659310..b09b895 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -78,8 +78,7 @@ static snd_pcm_uframes_t snd_usb_pcm_pointer(struct snd_pcm_substream *substream return SNDRV_PCM_POS_XRUN; spin_lock(&subs->lock); hwptr_done = subs->hwptr_done; - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - substream->runtime->delay = snd_usb_pcm_delay(subs, + substream->runtime->delay = snd_usb_pcm_delay(subs, substream->runtime->rate); spin_unlock(&subs->lock); return hwptr_done / (substream->runtime->frame_bits >> 3); -- 1.7.9.5

2 2

[alsa-devel] [PATCH] ASoC: core: Fix SOC_DOUBLE_RANGE() macros
by Mark Brown 19 Dec '12

19 Dec '12

Although we've had macros defining double _RANGE controls for a while now they've not actually been backed up properly by the implementation, it's treated everything as mono. Fix that by implementing the handling in the stereo controls, ensuring that the mono controls don't mistakenly get treated as stereo. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/soc.h | 10 ++++++---- sound/soc/soc-core.c | 32 ++++++++++++++++++++++++++++++-- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 4a27822..1e4ea78 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -58,8 +58,9 @@ .info = snd_soc_info_volsw_range, .get = snd_soc_get_volsw_range, \ .put = snd_soc_put_volsw_range, \ .private_value = (unsigned long)&(struct soc_mixer_control) \ - {.reg = xreg, .shift = xshift, .min = xmin,\ - .max = xmax, .platform_max = xmax, .invert = xinvert} } + {.reg = xreg, .rreg = xreg, .shift = xshift, \ + .rshift = xshift, .min = xmin, .max = xmax, \ + .platform_max = xmax, .invert = xinvert} } #define SOC_SINGLE_TLV(xname, reg, shift, max, invert, tlv_array) \ { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \ .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ |\ @@ -88,8 +89,9 @@ .info = snd_soc_info_volsw_range, \ .get = snd_soc_get_volsw_range, .put = snd_soc_put_volsw_range, \ .private_value = (unsigned long)&(struct soc_mixer_control) \ - {.reg = xreg, .shift = xshift, .min = xmin,\ - .max = xmax, .platform_max = xmax, .invert = xinvert} } + {.reg = xreg, .rreg = xreg, .shift = xshift, \ + .rshift = xshift, .min = xmin, .max = xmax, \ + .platform_max = xmax, .invert = xinvert} } #define SOC_DOUBLE(xname, reg, shift_left, shift_right, max, invert) \ { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = (xname),\ .info = snd_soc_info_volsw, .get = snd_soc_get_volsw, \ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index b1738d5..d4732ac 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2922,7 +2922,7 @@ int snd_soc_info_volsw_range(struct snd_kcontrol *kcontrol, platform_max = mc->platform_max; uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; - uinfo->count = 1; + uinfo->count = snd_soc_volsw_is_stereo(mc) ? 2 : 1; uinfo->value.integer.min = 0; uinfo->value.integer.max = platform_max - min; @@ -2946,12 +2946,14 @@ int snd_soc_put_volsw_range(struct snd_kcontrol *kcontrol, (struct soc_mixer_control *)kcontrol->private_value; struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); unsigned int reg = mc->reg; + unsigned int rreg = mc->rreg; unsigned int shift = mc->shift; int min = mc->min; int max = mc->max; unsigned int mask = (1 << fls(max)) - 1; unsigned int invert = mc->invert; unsigned int val, val_mask; + int ret; val = ((ucontrol->value.integer.value[0] + min) & mask); if (invert) @@ -2959,7 +2961,21 @@ int snd_soc_put_volsw_range(struct snd_kcontrol *kcontrol, val_mask = mask << shift; val = val << shift; - return snd_soc_update_bits_locked(codec, reg, val_mask, val); + ret = snd_soc_update_bits_locked(codec, reg, val_mask, val); + if (ret != 0) + return ret; + + if (snd_soc_volsw_is_stereo(mc)) { + val = ((ucontrol->value.integer.value[1] + min) & mask); + if (invert) + val = max - val; + val_mask = mask << shift; + val = val << shift; + + ret = snd_soc_update_bits_locked(codec, rreg, val_mask, val); + } + + return ret; } EXPORT_SYMBOL_GPL(snd_soc_put_volsw_range); @@ -2979,11 +2995,13 @@ int snd_soc_get_volsw_range(struct snd_kcontrol *kcontrol, (struct soc_mixer_control *)kcontrol->private_value; struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); unsigned int reg = mc->reg; + unsigned int rreg = mc->rreg; unsigned int shift = mc->shift; int min = mc->min; int max = mc->max; unsigned int mask = (1 << fls(max)) - 1; unsigned int invert = mc->invert; + int ret; ucontrol->value.integer.value[0] = (snd_soc_read(codec, reg) >> shift) & mask; @@ -2993,6 +3011,16 @@ int snd_soc_get_volsw_range(struct snd_kcontrol *kcontrol, ucontrol->value.integer.value[0] = ucontrol->value.integer.value[0] - min; + if (snd_soc_volsw_is_stereo(mc)) { + ucontrol->value.integer.value[1] = + (snd_soc_read(codec, rreg) >> shift) & mask; + if (invert) + ucontrol->value.integer.value[1] = + max - ucontrol->value.integer.value[1]; + ucontrol->value.integer.value[1] = + ucontrol->value.integer.value[1] - min; + } + return 0; } EXPORT_SYMBOL_GPL(snd_soc_get_volsw_range); -- 1.7.10.4

2 1

[alsa-devel] Newbie help with WM8962 and tinyalsa
by Randi Eckstein 19 Dec '12

19 Dec '12

If anyone has an explanation on how to use tinymix to play on a wm8962, I'd really appreciate it. Thanks, Randi Eckstein

2 1

Re: [alsa-devel] [PATCH] ASoC: dapm: Fix the unpaired runtime_get/put cases
by Mark Brown 19 Dec '12

19 Dec '12

On Wed, Dec 19, 2012 at 06:36:37PM +0800, Chuansheng Liu wrote: > But some devices has been set to STANDY bias directly during device probing, > such as cs42l73_probe(): > cs42l73_set_bias_level(codec, SND_SOC_BIAS_STANDBY); > Then it will cause runtime_get() not be called but laterly runtime_put() will > be called. Also found some other uppaired cases. This is just a bug in the driver, if it's idle_bias_off then it really should be starting in _OFF or at the very least starting actually in _STANDBY (including taking the runtime reference) rather than partially in _STANDBY. > So here add new flag get_runtime, and the logic will be: > 1/ when device is from off to non-off bias, runtime_get() will be called if not yet; > 2/ When device is off bias, runtime_put() will be called if runtime_get() has > been called; This is really not a good idea at all, it's just adding new special cases and making the code more obscure.

1 0

[alsa-devel] Speaker not working; muted?
by Martin Michlmayr 19 Dec '12

19 Dec '12

I've a problem with audio on my HP 2560p laptop (using snd_hda_intel): the speaker no longer works. However, I successfully get sound on a headphone. I've attached the output of alsa-info. It would be great if someone could take a look at let me know if this is a bug in the driver or wrong settings. Background: I used ALSA successfully in the past to play audio with the in-built speaker. At some point, I used aumix (which requires OSS modules) to turn the volume to zero. I believe I turned the volume back up again. I also rebooted my laptop at some point. I don't know if it's related to using aumix or something else, but at some point the in-built speaker stopped working... I can still listen to audio using a headphone. Another observation is that my laptop has a speaker mute button. When I reboot my laptop, and the BIOS or grub is running, I see that the mute button is activated. However, pressing the button doesn't change anything... when the Linux kernel loads, the mute button is still on, but when ALSA starts the button changes colour: it seems to me that ALSA thinks that mute is off while in reality it is on. -- Martin Michlmayr http://www.cyrius.com/

1 0

[alsa-devel] [PATCH 1/2] Revert "ALSA: usb-audio: ignore delay calculation for capture stream"
by Pierre-Louis Bossart 19 Dec '12

19 Dec '12

This reverts commit 3f94fad09538ec988919ec3f371841182df71d04. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/usb/pcm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index c659310..b09b895 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -78,8 +78,7 @@ static snd_pcm_uframes_t snd_usb_pcm_pointer(struct snd_pcm_substream *substream return SNDRV_PCM_POS_XRUN; spin_lock(&subs->lock); hwptr_done = subs->hwptr_done; - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - substream->runtime->delay = snd_usb_pcm_delay(subs, + substream->runtime->delay = snd_usb_pcm_delay(subs, substream->runtime->rate); spin_unlock(&subs->lock); return hwptr_done / (substream->runtime->frame_bits >> 3); -- 1.7.9.5

1 1

[alsa-devel] [PATCH 1/3] ASoC: arizona: Add noise gate hold time enumeration
by Mark Brown 18 Dec '12

18 Dec '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.c | 9 +++++++++ sound/soc/codecs/arizona.h | 2 ++ 2 files changed, 11 insertions(+) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index a85a68f..89c0433 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -323,6 +323,15 @@ const struct soc_enum arizona_lhpf4_mode = arizona_lhpf_mode_text); EXPORT_SYMBOL_GPL(arizona_lhpf4_mode); +static const char *arizona_ng_hold_text[] = { + "30ms", "120ms", "250ms", "500ms", +}; + +const struct soc_enum arizona_ng_hold = + SOC_ENUM_SINGLE(ARIZONA_NOISE_GATE_CONTROL, ARIZONA_NGATE_HOLD_SHIFT, + 4, arizona_ng_hold_text); +EXPORT_SYMBOL_GPL(arizona_ng_hold); + int arizona_in_ev(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h index db0c8dd..68dfae5 100644 --- a/sound/soc/codecs/arizona.h +++ b/sound/soc/codecs/arizona.h @@ -176,6 +176,8 @@ extern const struct soc_enum arizona_lhpf2_mode; extern const struct soc_enum arizona_lhpf3_mode; extern const struct soc_enum arizona_lhpf4_mode; +extern const struct soc_enum arizona_ng_hold; + extern int arizona_in_ev(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event); -- 1.7.10.4

1 2

[alsa-devel] [PATCH] ASoC: arizona: Correct FLL source definitions
by Mark Brown 18 Dec '12

18 Dec '12

The FLL source constants were numbered as a simple enumeration but were being used in the code as direct values to be written to the registers. Renumber the constants to reflect the usage. Reported-by: Ryo Tsutsui <Ryo.Tsutsui(a)wolfsonmicro.com> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.h | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h index 7f22b4f..68dfae5 100644 --- a/sound/soc/codecs/arizona.h +++ b/sound/soc/codecs/arizona.h @@ -34,15 +34,15 @@ #define ARIZONA_FLL_SRC_MCLK1 0 #define ARIZONA_FLL_SRC_MCLK2 1 -#define ARIZONA_FLL_SRC_SLIMCLK 2 -#define ARIZONA_FLL_SRC_FLL1 3 -#define ARIZONA_FLL_SRC_FLL2 4 -#define ARIZONA_FLL_SRC_AIF1BCLK 5 -#define ARIZONA_FLL_SRC_AIF2BCLK 6 -#define ARIZONA_FLL_SRC_AIF3BCLK 7 -#define ARIZONA_FLL_SRC_AIF1LRCLK 8 -#define ARIZONA_FLL_SRC_AIF2LRCLK 9 -#define ARIZONA_FLL_SRC_AIF3LRCLK 10 +#define ARIZONA_FLL_SRC_SLIMCLK 3 +#define ARIZONA_FLL_SRC_FLL1 4 +#define ARIZONA_FLL_SRC_FLL2 5 +#define ARIZONA_FLL_SRC_AIF1BCLK 8 +#define ARIZONA_FLL_SRC_AIF2BCLK 9 +#define ARIZONA_FLL_SRC_AIF3BCLK 10 +#define ARIZONA_FLL_SRC_AIF1LRCLK 12 +#define ARIZONA_FLL_SRC_AIF2LRCLK 13 +#define ARIZONA_FLL_SRC_AIF3LRCLK 14 #define ARIZONA_MIXER_VOL_MASK 0x00FE #define ARIZONA_MIXER_VOL_SHIFT 1 -- 1.7.10.4

1 0

[alsa-devel] [PATCH 1/1] ALSA: hda - bug fix for invalid connection list of more Haswell HDMI codec pins
by mengdong.lin＠intel.com 18 Dec '12

18 Dec '12

From: Mengdong Lin <mengdong.lin(a)intel.com> Haswell HDMI codec may report invalid connection list entries on all three pins. But our previous patch only fixes the HDMI pin, not the DP pin, so audio playbak via DP can still fail. This patch adds fixup for Haswell to set proper connection list entries for the other 2 pins including the DP pin. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 42fdf14..73d298a 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1710,8 +1710,14 @@ static void intel_haswell_fixup_connect_list(struct hda_codec *codec, if (vendor_param == -1 || !(vendor_param & 0x02)) return; + snd_hda_override_conn_list(codec, 0x05, 3, list); + hdmi_read_pin_conn(codec, 1); + snd_hda_override_conn_list(codec, 0x06, 3, list); hdmi_read_pin_conn(codec, 1); + + snd_hda_override_conn_list(codec, 0x07, 3, list); + hdmi_read_pin_conn(codec, 1); } -- 1.7.9.5

3 5

Re: [alsa-devel] [pulseaudio-discuss] Front mic not working properly
by Raymond Yau 18 Dec '12

18 Dec '12

>> > >> > I'm totally stuck with a sound problem I fail to debug on my own. >> > >> > My setup: >> > Asus P5Q Motherboard with Realtec ALC1200 soundchip. Stereo speakers plugged in to the rear output and headphone speaker/mic combo plugged in to the front jacks. System: Ubuntu 12.10 >> > Desired behaviour: Sound is played back on headphones AND rear speaker. Front mic should "just-work" Asus P5Q specification Realtek ALC1200, 8-channel High Definition Audio CODEC - Support Jack-Detection, Multi-streaming, and Front Panel Jack-Retasking Alt_playback is still not enabled to support multi streaming playback on realtec codecs >> > Problem 2: >> > This is the biggest problem. >> > As soon as I plug in the front mic, Inside gnome-alsamixer the volume for master, surround,center,lfe start to jump between on and off. Why is the Front mic jack controlling these values? Do you mean BIOS did not setup pin default correctly after asus-p5q model was removed? http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=6f… > How can I debug this behaviour? Post the output of alsa-info.sh > I just want them to stay the same, if the mic is plugged in or not. >> > Inside the gnome volume settings, the output port starts to jump between "Analog Output" and "Analog Headphones" >> >> This look like problem in Jack detection of the headphone and Mic Jack of front audio panel >> >> alsamixer -c0 >> >> Does the playback switch change rapidly on and off in alsamixer ? >> >> Do your computer chassis have a hda front audio panel and you connect them to the front audio connector of the motherboard according to the user manual ? >> >> Does it help if you disabled the automute switch ? >> > Thanks a lot. Your input helped me to at least work around the problem. My chassis has a HDA and an AC97 connector. The HDA connector was plugged in and correctly configured in BIOS. > I now use the AC97 connector (and changed the BIOS settings) and everything is working properly. Checking the front audio panel specification of your computer chassis Setting front audio panel to AC97 in BIOS of Asus motherboard change the miscellaneous bit of pin default of front HP and Mic Jack （i.e. misc = NO_PRESENCE) The alsa driver won't enable the unsolicited event on these nodes > > Regarding your questions: Disabling automute didn't help. And yes, the playback switch toggled rapidly. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi… Try disable trigger sense by codec->no_trigger_sense = 1; > > One thing I didn't test: I mistakenly plugged the rear speaker into the front channel jack (plugging the green connector into a green jack seemed so obvious). I don't know is this is the same channel as the headphone connector on the front panel... > > In AC97 mode it doesn't matter if I use the front channel jack or the rear channel jack (both at the rear of the computer) to connect my main speakers.

1 0

[alsa-devel] [PATCH 0/2] A few fixes for Reatek codecs
by Takashi Iwai 17 Dec '12

17 Dec '12

Hi, here is a patch series for fixing some obvious errors I've overseen for Realtek codecs. It'll be queued for 3.8-rc1. Takashi

1 2