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

[alsa-devel] ASoC updates for 3.3
by Mark Brown 01 Mar '12

01 Mar '12

The following changes since commit e555cf363167f09efae96d32a363e24c4de16b7b: ASoC: ak4642: fixup HeadPhone L/R dapm settings (2012-02-21 10:00:24 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.3 for you to fetch changes up to 5ed80a75b248bfaf840ea6b38f941edcf6ee7dc7: ASoC: i.MX SSI: Fix DSP_A format. (2012-02-23 18:58:17 +0000) ---------------------------------------------------------------- A small fix for the SSI driver and a fix for system shutdown with modern devices. Most of the modern devices will never get shut down normally with a visible kernel log as the systems they're in tend not to shut down often and when they do it's usually in form factors that don't have a user visible console. ---------------------------------------------------------------- Javier Martin (1): ASoC: i.MX SSI: Fix DSP_A format. Mark Brown (1): ASoC: dapm: Check for bias level when powering down sound/soc/imx/imx-ssi.c | 2 +- sound/soc/soc-dapm.c | 12 +++++++++--- 2 files changed, 10 insertions(+), 4 deletions(-)

2 1

[alsa-devel] [PATCH] ASoC: wm8962: Remove register default for PLL2
by Mark Brown 01 Mar '12

01 Mar '12

The initial value can be changed depending on system configuration. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8962.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index 890796f..e73c857 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -208,8 +208,6 @@ static struct reg_default wm8962_reg[] = { { 126, 0x000D }, /* R126 - Analogue Clocking3 */ { 127, 0x0000 }, /* R127 - PLL Software Reset */ - { 129, 0x0000 }, /* R129 - PLL2 */ - { 131, 0x0000 }, /* R131 - PLL 4 */ { 136, 0x0067 }, /* R136 - PLL 9 */ -- 1.7.9.1

1 0

[alsa-devel] oss plugin: SNDCTL_DSP_SETFRAGMENT problems
by Andriy Gapon 01 Mar '12

01 Mar '12

First, a disclaimer: what I'd like to discuss seems to affect a FreeBSD OSS implementation. After looking at the code in oss_pointer() and in snd_pcm_ioplug_hw_ptr_update() it seems that the code depends on OSS driver using exactly the same buffer size as specified by the buffer_size parameter. Otherwise the code that handles hw pointer cycling would calculate a delta incorrectly. Then, it seems that oss_hw_params() tries to enforce the driver's buffer size using SNDCTL_DSP_SETFRAGMENT. But in the OSS specification there are oh so many warnings about it: http://manuals.opensound.com/developer/SNDCTL_DSP_SETFRAGMENT.html > It's important to understand that this call just sets the size hint. There is > no guarantee that the requested size gets used. ... > It's very important to make this ioctl call as early as possible after > opening the device since otherwise the call may not have any effect. In > particular this call must be made before calling read, write or some other > ioctl calls. ... > This ioctl call will return an error only if the argument value is incorrect > or if the call is made in a wrong place. Even if the call returned OK there > is no guarantee that the requested buffer size will be used. This ioctl call > sets just the size hint and the driver may or may not honor the request. I see at least two issues with the oss plugin code: o Actual OSS driver buffer size value is never queried/verified if the SNDCTL_DSP_SETFRAGMENT call is successful o Apparently oss_hw_constraint() function is called before oss_hw_params() and the former makes SNDCTL_DSP_CHANNELS ioctl calls which change a configuration of the OSS driver and may affect the future SNDCTL_DSP_SETFRAGMENT call. This also violates the order described here: http://manuals.opensound.com/developer/callorder.html There is a retry loop in oss_hw_params() which closes and re-opens an OSS device, but that loop is only activated on SNDCTL_DSP_SETFRAGMENT hard failure; there is no handling for the case where the ioctl succeeds but the resulting buffer size differs from the requested one. I think that to nullify any effects of oss_hw_constraint() on the OSS driver configuration there should be a call to SNDCTL_DSP_RESET at the end of the function. Alternatively, there could be a call to this ioctl before SNDCTL_DSP_SETFRAGMENT. Or perhaps there could be resets at both places... Ideally, of course, the OSS plugin should query the exact OSS driver buffer size and alter the buffer_size parameter accordingly. But this is a bit more work. What do you think? Thank you. -- Andriy Gapon

1 0

[alsa-devel] [PATCH] ALSA: hda - Add a fake mute feature
by Takashi Iwai 01 Mar '12

01 Mar '12

David, I thought you have a machine with Cx20561 (such as Lenovo X200, T400 or W500)? Could you check whether this really doesn't break? Thanks, Takashi === Some codecs don't supply the mute amp-capabilities although the lowest volume gives the mute. It'd be handy if the parser provides the mute mixers in such a case. This patch adds an extension amp-cap bit (which is used only in the driver) to represent the min volume = mute state. Also modified the amp cache code to support the fake mute feature when this bit is set but the real mute bit is unset. In addition, conexant cx5051 parser uses this new feature to implement the missing mute controls. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42825 Cc: <stable(a)kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_codec.c | 8 ++++++-- sound/pci/hda/hda_codec.h | 3 +++ sound/pci/hda/patch_conexant.c | 22 +++++++++++++++++++++- 3 files changed, 30 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index c2c65f6..0ae6eb2 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -1759,7 +1759,11 @@ static void put_vol_mute(struct hda_codec *codec, struct hda_amp_info *info, parm = ch ? AC_AMP_SET_RIGHT : AC_AMP_SET_LEFT; parm |= direction == HDA_OUTPUT ? AC_AMP_SET_OUTPUT : AC_AMP_SET_INPUT; parm |= index << AC_AMP_SET_INDEX_SHIFT; - parm |= val; + if ((val & HDA_AMP_MUTE) && !(info->amp_caps & AC_AMPCAP_MUTE) && + (info->amp_caps & AC_AMPCAP_MIN_MUTE)) + ; /* set the zero value as a fake mute */ + else + parm |= val; snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE, parm); info->vol[ch] = val; } @@ -2026,7 +2030,7 @@ int snd_hda_mixer_amp_tlv(struct snd_kcontrol *kcontrol, int op_flag, val1 = -((caps & AC_AMPCAP_OFFSET) >> AC_AMPCAP_OFFSET_SHIFT); val1 += ofs; val1 = ((int)val1) * ((int)val2); - if (min_mute) + if (min_mute || (caps & AC_AMPCAP_MIN_MUTE)) val2 |= TLV_DB_SCALE_MUTE; if (put_user(SNDRV_CTL_TLVT_DB_SCALE, _tlv)) return -EFAULT; diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index e9f71dc..f0f1943 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -298,6 +298,9 @@ enum { #define AC_AMPCAP_MUTE (1<<31) /* mute capable */ #define AC_AMPCAP_MUTE_SHIFT 31 +/* driver-specific amp-caps: using bits 24-30 */ +#define AC_AMPCAP_MIN_MUTE (1 << 30) /* min-volume = mute */ + /* Connection list */ #define AC_CLIST_LENGTH (0x7f<<0) #define AC_CLIST_LONG (1<<7) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index a7a5733..ca117cf 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -4079,7 +4079,8 @@ static int cx_auto_add_volume_idx(struct hda_codec *codec, const char *basename, err = snd_hda_ctl_add(codec, nid, kctl); if (err < 0) return err; - if (!(query_amp_caps(codec, nid, hda_dir) & AC_AMPCAP_MUTE)) + if (!(query_amp_caps(codec, nid, hda_dir) & + (AC_AMPCAP_MUTE | AC_AMPCAP_MIN_MUTE))) break; } return 0; @@ -4379,6 +4380,22 @@ static const struct snd_pci_quirk cxt_fixups[] = { {} }; +/* add "fake" mute amp-caps to DACs on cx5051 so that mixer mute switches + * can be created (bko#42825) + */ +static void add_cx5051_fake_mutes(struct hda_codec *codec) +{ + static hda_nid_t out_nids[] = { + 0x10, 0x11, 0 + }; + hda_nid_t *p; + + for (p = out_nids; *p; p++) + snd_hda_override_amp_caps(codec, *p, HDA_OUTPUT, + AC_AMPCAP_MIN_MUTE | + query_amp_caps(codec, *p, HDA_OUTPUT)); +} + static int patch_conexant_auto(struct hda_codec *codec) { struct conexant_spec *spec; @@ -4397,6 +4414,9 @@ static int patch_conexant_auto(struct hda_codec *codec) case 0x14f15045: spec->single_adc_amp = 1; break; + case 0x14f15051: + add_cx5051_fake_mutes(codec); + break; } apply_pin_fixup(codec, cxt_fixups, cxt_pincfg_tbl); -- 1.7.9

2 1

Re: [alsa-devel] Cranking sound coming out of speakers with the new 3.1 kernel
by Takashi Iwai 01 Mar '12

01 Mar '12

At Thu, 1 Mar 2012 08:44:33 +0100, Jan Prunk wrote: > > Hello ! > > The sound has been stable for the last days without noises, > after applying % amixer -c0 set "Auto-Mute Mode" "Disabled" OK, another question is whether the auto-mute feature works in hardware, i.e. even when this mixer is set off, the hardware switches the speaker upon plugging the headphone? If yes, we can simply remove this switch and software feature from the driver. thanks, Takashi > > It seems this has solved it, until further notice. > You might want to keep the bug open for a while, > so I can check with all the kernels (it works with latest). > > Kind regards, > Jan > > On Tue, Feb 28, 2012 at 4:38 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Tue, 28 Feb 2012 16:16:48 +0100, > > Jan Prunk wrote: > >> > >> Hello ! > >> > >> On Sat, Jan 14, 2012 at 12:04 AM, Jonathan Nieder <jrnieder(a)gmail.com> wrote: > >> > Hi again, > >> > > >> > Jan Prunk wrote: > >> > > >> >> I tried booting into 3.2.0-rc7-686-pae, but the crunching sound > >> >> is still present, I am able to play music file properly, and > >> >> crunching is in the background, and also while not processing > >> >> any sounds, the crunching appears out of the speakers. > >> > > >> > Ok, thanks for testing. Please send a summary of this regression to > >> > alsa-devel(a)alsa-project.org, cc-ing Takashi Iwai <tiwai(a)suse.de> and > >> > either me or this bug log so we can track it. > >> > > >> > Be sure to mention: > >> > > >> > - steps to reproduce, what you expect versus what actually happens, > >> > and how that indicates a bug > >> > >> The sound is ok in kernel version "3.0.0-1-686-pae" but on all newer > >> versions there are sparkling/farting noises coming out of the speaker. > >> The noise is not very loud, its barely noticeable, but its repetative > >> and doesn't go away. And I think it happens while typing on the > >> keyboard and a bit later, then it dissapears for a few seconds, > >> or by the time that I type again. > >> > >> > - which kernel versions you tried, and what happens with each > >> I tried running alsa-info.sh as a "user". > >> > >> I tried 3.0.0-1-686-pae here is the debug: > >> http://www.alsa-project.org/db/?f=c1149b6466b2068d79c7517a8b0808d8b5c26e6b > >> --- > >> Linux vaio 3.2.0-1-686-pae #1 SMP Fri Feb 17 06:27:21 UTC 2012 i686 GNU/Linux > >> ii linux-image-3.2.0-1-686-pae 3.2.6-1 > >> http://www.alsa-project.org/db/?f=fddbfbdc4fc44555a6dc851ecdc70760da6dd840 > >> --- > >> Linux vaio 3.2.0-rc7-686-pae #1 SMP Wed Dec 28 21:26:25 UTC 2011 i686 GNU/Linux > >> ii linux-image-3.2.0-rc7-686-pae 3.2~rc7-1~experimental.1 > >> http://www.alsa-project.org/db/?f=78c8919e87dd03294484f83b5f7ae44331b5edfe > >> Being booted into this version for 15 minutes, it seems to not make any noises, > >> but I will resubmit the info later if the noises will start to appear. > > > > 3.2.0-rc7 alsa-info shows that the headphone jack is plugged, thus the > > speaker is muted. It's natural that the noise goes away in this > > state. > > > > Apart from that, I see no obvious problem in 3.2.0 output. > > > > Does the problem still happen when you disable "Auto-Mute Mode" mixer > > enum? > > % amixer -c0 set "Auto-Mute Mode" "Disabled" > > > > Also, try to pass algin_buffer_size=0 option to snd-hda-intel. > > I don't expect much that this will influence, but at least, it's a > > difference between 3.0 and 3.2. > > > > > > Takashi > > > > > >> > - alsa-info.sh output, as an attachment > >> > > >> > - if you can make a recording of the strange sound available > >> > somewhere online, that would be ideal > >> > >> Because the noise is barely heard, I would need to find a good mic. > >> to be able to record it, but I could do that in the next bug submission. > >> > >> > - whether you are able to bisect or test patches if needed > >> > >> I might try that, if there are any manuals around how to do it, > >> but my response might take some time. > >> > >> > [1] may have more hints. > >> > > >> > Thanks and good luck, > >> > Jonathan > >> > > >> > [1] http://alsa-project.org/main/index.php/Help_To_Debug_Intel_HDA > >> > >> Kind regards, > >> Jan Prunk > >> -- > >> Jan Prunk http://www.prunk.si > >> 0x00E80E86 http://pgp.prunk.si > >> http://AS50763.peeringdb.com > >> > > > > -- > Jan Prunk http://www.prunk.si > 0x00E80E86 http://pgp.prunk.si > http://AS50763.peeringdb.com >

1 0