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

[alsa-devel] [PATCH] ASoC: Implement WM8962 ADC high pass filter configuration
by Mark Brown 27 Apr '11

27 Apr '11

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8962.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index 7949f89..f90ae42 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -2039,6 +2039,13 @@ static int wm8962_put_spk_sw(struct snd_kcontrol *kcontrol, return 0; } +static const char *cap_hpf_mode_text[] = { + "Hi-fi", "Application" +}; + +static const struct soc_enum cap_hpf_mode = + SOC_ENUM_SINGLE(WM8962_ADC_DAC_CONTROL_2, 10, 2, cap_hpf_mode_text); + static const struct snd_kcontrol_new wm8962_snd_controls[] = { SOC_DOUBLE("Input Mixer Switch", WM8962_INPUT_MIXER_CONTROL_1, 3, 2, 1, 1), @@ -2064,6 +2071,9 @@ SOC_DOUBLE_R("Capture Switch", WM8962_LEFT_INPUT_VOLUME, WM8962_RIGHT_INPUT_VOLUME, 7, 1, 1), SOC_DOUBLE_R("Capture ZC Switch", WM8962_LEFT_INPUT_VOLUME, WM8962_RIGHT_INPUT_VOLUME, 6, 1, 1), +SOC_SINGLE("Capture HPF Switch", WM8962_ADC_DAC_CONTROL_1, 0, 1, 1), +SOC_ENUM("Capture HPF Mode", cap_hpf_mode), +SOC_SINGLE("Capture HPF Cutoff", WM8962_ADC_DAC_CONTROL_2, 7, 7, 0), SOC_DOUBLE_R_TLV("Sidetone Volume", WM8962_DAC_DSP_MIXING_1, WM8962_DAC_DSP_MIXING_2, 4, 12, 0, st_tlv), -- 1.7.4.1

2 1

[alsa-devel] [PATCH] ASoC: Fix CODEC DAI names for Goni
by Mark Brown 27 Apr '11

27 Apr '11

Immediately after sending the last fix I realised that the CODEC DAI names also don't correspond to the WM8994 driver. Update the DAI names to match. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/goni_wm8994.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/goni_wm8994.c b/sound/soc/samsung/goni_wm8994.c index 3a7861c..0e80dae 100644 --- a/sound/soc/samsung/goni_wm8994.c +++ b/sound/soc/samsung/goni_wm8994.c @@ -236,7 +236,7 @@ static struct snd_soc_dai_link goni_dai[] = { .name = "WM8994", .stream_name = "WM8994 HiFi", .cpu_dai_name = "samsung-i2s.0", - .codec_dai_name = "wm8994-hifi", + .codec_dai_name = "wm8994-aif1", .platform_name = "samsung-audio", .codec_name = "wm8994-codec.0-001a", .init = goni_wm8994_init, @@ -245,7 +245,7 @@ static struct snd_soc_dai_link goni_dai[] = { .name = "WM8994 Voice", .stream_name = "Voice", .cpu_dai_name = "goni-voice-dai", - .codec_dai_name = "wm8994-voice", + .codec_dai_name = "wm8994-aif2", .platform_name = "samsung-audio", .codec_name = "wm8994-codec.0-001a", .ops = &goni_voice_ops, -- 1.7.4.1

2 1

Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod
by Stephen Warren 27 Apr '11

27 Apr '11

Barry Song wrote at Wednesday, April 27, 2011 1:28 AM: > The newest compiliers can optimize pll calculation in several codecs into > __aeabi__uldivmod which doesn't exist in kernel. > Then the link will fail: > ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined! > ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8940.ko] undefined! > ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8510.ko] undefined! > This patch prevent the optimizaton by insert ASM. Aren't there compiler flags that tell gcc it isn't operating in a hosted(?) environment, and hence not to emit calls to these functions? If so, I imagine they should be added to the kernel's core (or ARM arch ) makefiles. I doubt __aeabi_uldivmod is the only function of this type. How was this solved for other such functions; does the kernel implement the AEABI functions, and this implementation is simply missing? But yes either way, ask on the main kernel or ARM kernel mailing list (ARM now CC'd) diff --git a/sound/soc/codecs/wm8510.c b/sound/soc/codecs/wm8510.c index db0dced..a636b15 100644 --- a/sound/soc/codecs/wm8510.c +++ b/sound/soc/codecs/wm8510.c @@ -258,6 +258,12 @@ static void pll_factors(unsigned int target, unsigned int source) Nmod = target % source; Kpart = FIXED_PLL_SIZE * (long long)Nmod; + /* + * The following asm() prevents the compiler from optimising + * into a standard EABI function __aeabi__uldivmod() + */ + asm("" : "+r"(source)); + do_div(Kpart, source); K = Kpart & 0xFFFFFFFF; -- nvpublic

4 4

[alsa-devel] [PATCH] ALSA - au88x0 - Add buffer bytes constraints
by Raymond Yau 27 Apr '11

27 Apr '11

Add buffer bytes constraints so that snd_pcm_hw_params_set_buffer_time_near() can return the buffer time for au88x0 This allow application such as gstreamer and wine which use snd_pcm_hw_params_set_buffer_time_near() since au88x0 require special contraint period bytes of power 2 playback https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/52396 capture http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575013

2 1

[alsa-devel] [PATCH 1/1] ALSA: VIA HDA: Fix Smart5.1 isn't useful for 6 audio jacks motherboard
by lydiawang 27 Apr '11

27 Apr '11

From: Lydia Wang <lydiawang(a)viatech.com.cn> Subject: ALSA: VIA HDA: Fix Smart5.1 isn't useful for 6 audio jacks motherboard. For some motherboards with 5 or 6 audio jacks which had six or eight multiple channels output, smart5.1 item is no useful and should be removed. Signed-off-by: Lydia Wang <lydiawang(a)viatech.com.cn> Index: sound-2.6/sound/pci/hda/patch_via.c =================================================================== --- sound-2.6.orig/sound/pci/hda/patch_via.c 2011-04-27 16:48:03.000000000 +0800 +++ sound-2.6/sound/pci/hda/patch_via.c 2011-04-27 17:01:22.000000000 +0800 @@ -1021,6 +1021,10 @@ hda_nid_t nid; int i; + if (!cfg) + return 0; + if (cfg->line_outs > 2) + return 0; knew = via_clone_control(spec, &via_smart51_mixer[0]); if (knew == NULL) return -ENOMEM;

2 1

[alsa-devel] ASoC: One HW register bit affecting two paths
by Stephen Warren 27 Apr '11

27 Apr '11

Mark, There's one small issue with the WM8903 DMIC patch I sent recently: In HW, there's a single control bit that affects two paths. This is currently represented as two widgets, Left ADC Input and Right ADC Input, each having its own control, both of which point at the same register bit. When alsamixer sets one of these controls, both the Left ADC Input and Right ADC Input controls read back with the value that was set, since they both read from the same register bit. However, if only one of the controls is actually manipulated, then only the paths associated with that single widget are updated by dapm_mux_update_power. To solve this, the user must currently also toggle the other control back to the original value and then to the new value in order to update the paths. I can see some possible ways to solve this, presented below: Solution 1: Applying updates to N controls: Modify snd_soc_dapm_put_* to search for and loop over all widgets using the same control name or register bit(s) in, and perform the same update for each. Essentially, this is the same idea as solution 2 below, but with the implementation performing all the comparisons within snd_soc_dapm_put_*, rather than pre-computing the sharing arrangement when creating controls. The disadvantage here is the perhaps significant run-time comparison costs within the loop over all widgets. Also, each snd_soc_dapm_put_* duplicates that same code, unless the control's .get/.put point at a single unified ASoC function which implements the looping, and then dispatches based on a different function pointer. Solution 2: Sharing controls: * When calling snd_soc_cnew, store a list of widgets in the control instead of a single widget. * Modify snd_soc_dapm_{get,put}_* to retrieve the list of widgets, and iterate over them all. * Modify dapm_new_{mux,*} to: + Search for an existing control with the same name. + If found: Add this widget to the list stored in the control. + If not found: Create a new control with a single-entry list containing the current widget. The advantage here is isolating the searching for widgets using the same register bits to control creation rather than usage. Data setup would be: // Two mono muxes, sharing a control SND_SOC_DAPM_MUX("Left ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), SND_SOC_DAPM_MUX("Right ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), // Existing style of path definitions { "Left ADC Input", "ADC", "Left Input PGA" }, { "Left ADC Input", "DMIC", "DMICDAT" }, { "Right ADC Input", "ADC", "Right Input PGA" }, { "Right ADC Input", "DMIC", "DMICDAT" }, { "ADCL", NULL, "Left ADC Input" }, { "ADCL", NULL, "CLK_DSP" }, { "ADCR", NULL, "Right ADC Input" }, { "ADCR", NULL, "CLK_DSP" }, Solution 3: Stereo widgets: * Modify w->{sources,sinks} to be arrays (an entry for each channel, probably just L/R entries initially) * Modify path list parsing to allow source/sink widget names to contain a ":L"/":R" suffix indicating which w->sources[] array index to use. The arrays would be required so that path traversal code wouldn't find a false path from ADCR to Right Input PGA; the L/R connectivity needs to be completely separate. * snd_soc_dapm_add_route's "find src and dest widgets" loop would need to be enhanced to understand the new syntax, and be able to match up widget names by ignoring ":xxx" when searching, at least for widgets explicitly marked stereo. * Other fallout of the above that I haven't thought through yet. // A single stereo mux SND_SOC_DAPM_MUX("ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), // Enhanced style of path definitions { "ADC Input:L", "ADC", "Left Input PGA" }, { "ADC Input:L", "DMIC", "DMICDAT" }, { "ADC Input:R", "ADC", "Right Input PGA" }, { "ADC Input:R", "DMIC", "DMICDAT" }, { "ADCL", NULL, "ADC Input:R" }, { "ADCL", NULL, "CLK_DSP" }, { "ADCR", NULL, "ADC Input:R" }, { "ADCR", NULL, "CLK_DSP" }, Do you have any other ideas how this might be solved, or a preference for which solution to pursue? Thanks. -- nvpublic

2 1

[alsa-devel] subwoofer problem on hp dv7 laptop
by mak rulz 27 Apr '11

27 Apr '11

hello i need some help. my hp dv7 laptop has a subwoofer under it. the problem it that alsa cant detect the subwoofer and hence i cant use it. http://www.alsa-project.org/db/?f=434819cab8ce83492bc46188bce304e758ccbe48 i have a 92HD75 chip. thanks

2 1

[alsa-devel] PATCH: alsa-plugins: a52: Fix build with older ffmpeg versions
by Colin Guthrie 27 Apr '11

27 Apr '11

This fixes a regression introduced in: commit 40c129a160f37fe9488b2828d6299f99c269703e Author: Joerg Reuter <jreuter(a)suse.de> Date: Wed Apr 6 16:36:11 2011 +0200 a52 - Fix a52 codec with recent libavcodec updates The recent libavcodec is changed to accept only float input, but the old ac3 encoder is still somehow working with a different name. This patch makes it working again. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]

2 1

[alsa-devel] Incorrect guessing of sound card on 2nd generation Intel Macbook
by Debarshi Ray 27 Apr '11

27 Apr '11

I have a 2nd generation Intel Macbook and the elements shown by alsamixer do not do what they are supposed to do. alsamixer shows master, speaker and speaker1. Normally without any headphones muting speaker1 "weakens" the output. But if a headset is attached then speaker1 has to be unmuted otherwise there is no output from the headphones. I am using alsa-lib-1.0.24 and the 2.6.35.11 kernel on a Fedora 14 system. lspci: http://rishi.fedorapeople.org/lspci /proc/asound/Intel/codec#0: http://rishi.fedorapeople.org/proc-asound-Intel-codec-0 Cheers, Debarshi

1 1

[alsa-devel] AC97 Playback Volume and Mic Boost (+20dB)
by Raymond Yau 27 Apr '11

27 Apr '11

Should alsactl init change "AC97 Playback Volume" and "AC97 Playback Switch" only for aureon ? pci/ice1712/aureon.c: .name = "AC97 Playback Volume", CTL{reset}="mixer" CTL{name}="AC97 Playback Volume",CTL{do_search}=="1", \ CTL{values}="100%" CTL{name}="AC97 Playback Switch",CTL{do_search}=="1", \ CTL{values}="on" Refer to Documentation/SB-Live-mixer.txt , The alternative way may be remove these two controls if there are no practical usage ? name='AC97 Playback Volume',index=0 This control is used to attenuate samples for left and right front ADC PCM slots of the AC97 codec. The result samples are forwarded to the front DAC PCM slots of the AC97 codec. ******************************************************************************** *** Note: This control should be zero for the standard operations, otherwise *** *** a digital loopback is activated. *** ******************************************************************************** name='AC97 Capture Volume',index=0 This control is used to attenuate samples for left and right front ADC PCM slots of the AC97 codec. The result is forwarded to the ADC capture FIFO (thus to the standard capture PCM device). ******************************************************************************** *** Note: This control should be 100 (maximal value), otherwise no analog *** *** inputs of the AC97 codec can be captured (recorded). *** ******************************************************************************** BTW , why alsa-lib regard "Mic Boost (+20dB)" switch as a playback switch ? it seem that "20dB Boost " have effect on both playback and capture Simple mixer control 'Mic Boost (+20dB)',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off]

1 0