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

Re: [alsa-devel] [ALSA hda 3.4-rc] suspend2ram regression in snd_hda_intel
by Konstantin Khlebnikov 06 May '12

06 May '12

Konstantin Khlebnikov wrote: > Mainline commit 785f857d1cb0856b612b46a0545b74aa2596e44a > ("ALSA: hda - Set codec to D3 forcibly even if not used") > breaks sound for my notebook (thinkpad x220), > looks like codec cannot wake from power-save state after resume. > After reverting looks like all works fine. > > how to reproduce: > * unplug the power cord (to enable hda power safe mode) > * play something and stop > * wait until the background noise disappears (codec went into power-save mode) > * suspend > * resume > * play something again and hear the silence > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Bump BTW, I don't see any locks around hda power-save code, for example hda_power_work() reads codec->power_on and codec->power_count without any locks. This seems racy.

2 1

[alsa-devel] Call for propsals: Audio micro-conf at LPC 2012 San Diego
by Takashi Iwai 05 May '12

05 May '12

Hi, we're planning to hold an Audio micro-conference again this year at Linux Plumbers conference (LPC). It'll be held at San Diego, CA, Aug. 29-31. The Wiki page is found at http://wiki.linuxplumbersconf.org/2012:audio The items listed there are rough ideas popping up during a mail thread. If you have interest and want to give a talk or discussions, don't hesitate to submit your proposal. Please mail to submissions(a)linuxplumbersconf.org, as described in the page below: http://www.linuxplumbersconf.org/2012/2012-lpc-call-for-proposals-take-2/ The deadline for submission is 11:59 PDT on May 1, 2012. So, it's pretty little time left. Sorry for the late announce... thanks, Takashi

2 2

Re: [alsa-devel] [GIT PULL] ASoC fix for 3.4
by Takashi Iwai 05 May '12

05 May '12

At Fri, 04 May 2012 12:24:58 +0100, Liam Girdwood wrote: > > Hi Takashi, > > For your final sound 3.4 fixes pull request. > > Thanks > > Liam > > --- > > The following changes since commit 1a38336b8611a04f0a624330c1f815421f4bf5f4: > > ASoC: wm8994: Improve sequencing of AIF channel enables (2012-04-23 12:55:52 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git for-3.4 > > for you to fetch changes up to fad9365bcc2a69ae16adc092e8ac192354980665: > > ASoC: omap-pcm: Free dma buffers in case of error. (2012-05-04 12:09:28 +0100) Thanks, pulled. I'm going to send a pull request to Linus later today. Takashi > ---------------------------------------------------------------- > Oleg Matcovschi (1): > ASoC: omap-pcm: Free dma buffers in case of error. > > sound/soc/omap/omap-pcm.c | 4 ++++ > 1 file changed, 4 insertions(+) > >

1 0

[alsa-devel] ASoC updates for 3.4
by Mark Brown 05 May '12

05 May '12

The following changes since commit 1a38336b8611a04f0a624330c1f815421f4bf5f4: ASoC: wm8994: Improve sequencing of AIF channel enables (2012-04-23 12:55:52 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.4 for you to fetch changes up to 06412088ce98f745405b8f65cfc51ddd6b842bbf: ASoC: s3c2412-i2s: Fix dai registration (2012-04-30 23:45:25 +0100) ---------------------------------------------------------------- ASoC: Updates for 3.4 Nothing terribly exciting here, a bunch of small and simple fixes scattered around the place. ---------------------------------------------------------------- Eric Bénard (1): ASoC: tlv312aic23: unbreak resume Fabio Estevam (1): ASoC: dt: sgtl5000.txt: Add description for 'reg' field Heiko Stübner (1): ASoC: s3c2412-i2s: Fix dai registration Lars-Peter Clausen (1): ASoC: bf5xx-ssm2602: Set DAI format Mark Brown (2): ASoC: wm_hubs: Make sure we don't disable differential line outputs ASoC: wm8350: Don't use locally allocated codec struct Richard Zhao (1): ASoC: core: check of_property_count_strings failure Documentation/devicetree/bindings/sound/sgtl5000.txt | 2 ++ sound/soc/blackfin/bf5xx-ssm2602.c | 2 ++ sound/soc/codecs/tlv320aic23.c | 4 ++-- sound/soc/codecs/wm8350.c | 11 ++++++----- sound/soc/codecs/wm_hubs.c | 15 +++++++++------ sound/soc/samsung/s3c2412-i2s.c | 2 +- sound/soc/soc-core.c | 6 +++--- 7 files changed, 25 insertions(+), 17 deletions(-)

2 1

[alsa-devel] Diagnosing why DAPM config is not correctly applied
by Daniel Drake 05 May '12

05 May '12

Hi, I'm working with Linux 3.3 and the soc/codecs/rt5631.c driver in an OLPC XO-1.75 laptop. We are only getting silence when playing back sound. I have added in some debug messages in soc-io.c and enabled DEBUG and VERBOSE_DEBUG in soc-dapm.c. Here are boot messages: http://dev.laptop.org/~dsd/20120504/boot.log At time X in the above log, I start "speaker-test -c 2 -t wav" and leave it running for the remainder of this test. Here is the "amixer" output at this point: http://dev.laptop.org/~dsd/20120504/amixer-initial.txt speaker-test seems happy but no audio can be heard :( However, I have found that the following tweak to the sound controls will fix the left channel: # amixer sset 'Left SPKVOL Mux' 'Vmid' # amixer sset 'Left SPKVOL Mux' 'SPKMIXL' Note that the original value was SPKMIXL (see initial amixer output) so this should have had no effect. However, the result is that sound is now heard through the left channel. (A very similar sound control change will fix the right channel too) While running these commands, the following kernel messages appear: (amixer sset 'Left SPKVOL Mux' 'Vmid') read c = 0 read c = 0 read 10 = 606 read 10 = 606 read c = 0 read c = 0 read a = 0 read a = 0 read 6 = a080 read 1e = 88c0 read 1e = 88c0 read 1e = 88c0 read 1e = 88c0 read 6 = a080 read 20 = 88c0 read 20 = 88c0 read 20 = 88c0 read 20 = 88c0 read 24 = 3000 read 24 = 3000 read 24 = 3000 read 24 = 3000 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 2c = 0 read 2c = 0 read 4 = c0c0 read 6 = a080 read 2 = 4040 read 22 = 7700 read 22 = 7700 read e = 0 read 22 = 7700 read 22 = 7700 read e = 0 read 2c = 0 read 6 = a080 read 26 = 8404 read 26 = 8404 read 26 = 8404 read 2a = 6c00 read 2a = 6c00 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 2 = 4040 read 2 = 4040 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 4 = c0c0 read 6 = a080 read 2 = 4040 read 40 = 4e00 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 2c = 0 read 2a = 6c00 read 2a = 6c00 read 2c = 0 read 2a = 6c00 read 2a = 6c00 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 rt5631 0-001a: Marking Vmid dirty due to mux connection rt5631 0-001a: Marking Left SPKVOL Mux dirty due to mux change read 2 = 4040 write 2 = 40 (cached) read 2 = 40 (amixer sset 'Left SPKVOL Mux' 'SPKMIXL') read c = 0 read c = 0 read 10 = 606 read 10 = 606 read c = 0 read c = 0 read a = 0 read a = 0 read 6 = a080 read 1e = 88c0 read 1e = 88c0 read 1e = 88c0 read 1e = 88c0 read 6 = a080 read 20 = 88c0 read 20 = 88c0 read 20 = 88c0 read 20 = 88c0 read 24 = 3000 read 24 = 3000 read 24 = 3000 read 24 = 3000 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 2c = 0 read 2c = 0 read 4 = c0c0 read 6 = a080 read 2 = 40 read 22 = 7700 read 22 = 7700 read e = 0 read 22 = 7700 read 22 = 7700 read e = 0 read 2c = 0 read 6 = a080 read 26 = 8404 read 26 = 8404 read 26 = 8404 read 2a = 6c00 read 2a = 6c00 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 2 = 40 read 2 = 40 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 4 = c0c0 read 6 = a080 read 2 = 40 read 40 = 4e00 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 2c = 0 read 2a = 6c00 read 2a = 6c00 read 2c = 0 read 2a = 6c00 read 2a = 6c00 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 rt5631 0-001a: Marking Vmid dirty due to mux disconnection rt5631 0-001a: Marking SPKMIXL Mixer dirty due to mux connection rt5631 0-001a: Marking Left SPKVOL Mux dirty due to mux change rt5631 0-001a: Marking Left DAC dirty due to peer state change rt5631 0-001a: Marking Left DAC To Mixer dirty due to peer state change rt5631 0-001a: Marking DAC REF dirty due to peer state change rt5631 0-001a: Marking I2S dirty due to peer state change rt5631 0-001a: Marking PLL1 dirty due to peer state change rt5631 0-001a: Marking Left DAC_HP dirty due to peer state change rt5631 0-001a: Marking OUTMIXL Mixer dirty due to peer state change read 1a = dfc0 read 28 = d8d8 read 42 = 0 read 42 = 0 read 42 = 0 read 42 = 0 read 2 = 40 write 2 = 4040 (cached) read 3a = 1000 write 3a = 90c0 (cached) read 3a = 90c0 write 3a = 92c0 (cached) read 3b = c write 3b = 200c (cached) read 2 = 4040 So, changing these settings in a way that should have no effect seems to kick DAPM into applying quite a different config from the one initially applied. In particular, the register value register 0x3a (RT5631_PWR_MANAG_ADD1) is quite different from the one applied earlier, and I think this is the key to having playback working. I've spent some time trying to get my head around the dapm code and see whats happening here, without much luck. If someone more experienced here could take a quick look at these messages and the dapm routes in rt5631.c for anything obvious, it would be much appreciated. Further debugging tips welcome too. Thanks, Daniel

1 0

[alsa-devel] ALSA driver issue with the ssm2602.c
by Bishop, Mark 04 May '12

04 May '12

When I enable the 'Output Mixer HiFi' using amixer it also powers up the Mic input on this codec. I believe this is incorrect. I would like to modify the driver to fix it but am having issues with the ALSA structures in the driver. Would I be off if I attempt to make my changes in the snd_soc_dapm_route structures? I am unsure how everything is hooked together in all those structs{}.

2 2

[alsa-devel] [PATCH v2] Provide interface for audio support in DSS
by Ricardo Neri 04 May '12

04 May '12

Hi, This patch is proposed as a result of a previous discussion related to include audio support in the DSS device driver (http://www.spinics.net/lists/linux-omap/msg64748.html) At the moment, this is intended to cover display technologies with audio based on CEA-861 and IEC-60958, such as HDMI and DisplayPort. However, provisions are made to make it extensible (see below). These are the changes with respect to v1: * The audio_enable and audio_start functions were split into enable/disable and start/stop respectively to improve readability. * Comments were added on whether the DSS audio functions may sleep. * In order to make the audio configuration parameters extensible, a struct omap_dss_audio is defined. This helps to easily add more config parameters in the future if/when required (e.g., speaker order configuration). BR, Ricardo Ricardo Neri (1): OMAPDSS: Provide an interface for audio support in DSS Documentation/arm/OMAP/DSS | 38 ++++++++++++++++++++++++++++++++++++++ include/video/omapdss.h | 25 +++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 0 deletions(-) -- 1.7.5.4

1 1

[alsa-devel] [PATCH] ASoC: da7210: Minor improvements and a bugfix
by Ashish Chavan 03 May '12

03 May '12

This patch improves playback quality for few sample rates like 8000 and 11025 Hz. This also fixes an issue observed during testing of pll slave mode. Due to the issue, on some rare occasions there was no sound output for first time playback after system boot, though all subsequent playbacks were fine. It was mainly because of the sequence in which SRM bit was enabled. Signed-off-by: Ashish Chavan <ashish.chavan(a)kpitcummins.com> Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> --- sound/soc/codecs/da7210.c | 28 +++++++++++++++------------- 1 files changed, 15 insertions(+), 13 deletions(-) diff --git a/sound/soc/codecs/da7210.c b/sound/soc/codecs/da7210.c index 10f52ff..af5db70 100644 --- a/sound/soc/codecs/da7210.c +++ b/sound/soc/codecs/da7210.c @@ -850,8 +850,19 @@ static int da7210_hw_params(struct snd_pcm_substream *substream, if (da7210->mclk_rate && (da7210->mclk_rate != sysclk)) { /* PLL mode, disable PLL bypass */ snd_soc_update_bits(codec, DA7210_PLL_DIV3, DA7210_PLL_BYP, 0); + + if (!da7210->master) { + /* PLL slave mode, also enable SRM */ + snd_soc_update_bits(codec, DA7210_PLL, + (DA7210_MCLK_SRM_EN | + DA7210_MCLK_DET_EN), + (DA7210_MCLK_SRM_EN | + DA7210_MCLK_DET_EN)); + } } else { - /* PLL bypass mode, enable PLL bypass */ + /* PLL bypass mode, enable PLL bypass and Auto Detection */ + snd_soc_update_bits(codec, DA7210_PLL, DA7210_MCLK_DET_EN, + DA7210_MCLK_DET_EN); snd_soc_update_bits(codec, DA7210_PLL_DIV3, DA7210_PLL_BYP, DA7210_PLL_BYP); } @@ -1014,18 +1025,9 @@ static int da7210_set_dai_pll(struct snd_soc_dai *codec_dai, int pll_id, snd_soc_update_bits(codec, DA7210_PLL_DIV3, DA7210_PLL_DIV_L_MASK, pll_div3); - if (da7210->master) { - /* In master mode, no need to enable SRM */ - snd_soc_update_bits(codec, DA7210_PLL, DA7210_PLL_EN, - DA7210_PLL_EN); - } else { - /* In slave mode, enable SRM and PLL */ - snd_soc_update_bits(codec, DA7210_PLL, - (DA7210_PLL_EN | DA7210_MCLK_SRM_EN | - DA7210_MCLK_DET_EN), - (DA7210_PLL_EN | DA7210_MCLK_SRM_EN | - DA7210_MCLK_DET_EN)); - } + /* Enable PLL */ + snd_soc_update_bits(codec, DA7210_PLL, DA7210_PLL_EN, DA7210_PLL_EN); + /* Enable active mode */ snd_soc_update_bits(codec, DA7210_STARTUP1, DA7210_SC_MST_EN, DA7210_SC_MST_EN); -- 1.7.1

2 1

Re: [alsa-devel] Fast Track Ultra latency and new streaming logic.
by Clemens Ladisch 03 May '12

03 May '12

Felix Homann wrote: > 2012/5/3 Clemens Ladisch <clemens(a)ladisch.de>: >> USB playback also adds further latency by queueing the packets; the >> number of packets can be seen under "URBs" in /proc/asound/card?/stream0. >> (There are 1000/8000 packets per second at full/high speed.) > > I'm getting "URBs = 2 [ 5 6 ]" for playback and "URBs = 8 [ 8 8 8 8 > 8 8 8 8 ]" for capture with the "old" streaming logic. What does it > mean? The queue length is 5+6 = 11 packets; at high speed, that's 11 / 8 kHz = 1.4 ms. Regards, Clemens

1 0

[alsa-devel] Fast Track Ultra latency and new streaming logic.
by Grant Diffey 03 May '12

03 May '12

Daniel, In continuing my personal habit of looking gift horses in the mouth... I can't seem to get below 512frames in flight (2 256sample frames or 4 128 or 8 64's) without consistant overruns. I have a feeling that the pcm <-> urb layer is buffering until a urb is max urbsize from a quick look at the code does this seem like the right track? This leads to rather high latencies (22ms+) or is this conclusion bogus? Grant.

4 5