January 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 1/2] ALSA: hda - add mute LED for HP Pavilion 17 (Realtek codec)
by David Henningsson 07 Jan '13

07 Jan '13

The mute LED is in this case connected to the Mic1 VREF. The machine also exposes the following string in BIOS: "HP_Mute_LED_0_A", so if more machines are coming, it probably makes sense to try to do something more generic, like for the IDT codec. Cc: stable(a)vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1096789 Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) I know this is a copy-paste, but I didn't really find a better and more condensed way to do it. Perhaps if we get a third variation it would make sense to write a more generic version. Also, Alsa-info is available at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1096789/+attachment/34… diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 6ee3459..2e6803e 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5992,7 +5992,30 @@ static void alc269_fixup_quanta_mute(struct hda_codec *codec, spec->automute_hook = alc269_quanta_automute; } -/* update mute-LED according to the speaker mute state via mic2 VREF pin */ +/* update mute-LED according to the speaker mute state via mic VREF pin */ +static void alc269_fixup_mic1_mute_hook(void *private_data, int enabled) +{ + struct hda_codec *codec = private_data; + unsigned int pinval = AC_PINCTL_IN_EN + (enabled ? + AC_PINCTL_VREF_HIZ : AC_PINCTL_VREF_80); + snd_hda_set_pin_ctl_cache(codec, 0x18, pinval); +} + +static void alc269_fixup_mic1_mute(struct hda_codec *codec, + const struct alc_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + switch (action) { + case ALC_FIXUP_ACT_BUILD: + spec->vmaster_mute.hook = alc269_fixup_mic1_mute_hook; + snd_hda_add_vmaster_hook(codec, &spec->vmaster_mute, true); + /* fallthru */ + case ALC_FIXUP_ACT_INIT: + snd_hda_sync_vmaster_hook(&spec->vmaster_mute); + break; + } +} + static void alc269_fixup_mic2_mute_hook(void *private_data, int enabled) { struct hda_codec *codec = private_data; @@ -6043,6 +6066,7 @@ enum { ALC269_FIXUP_DMIC, ALC269VB_FIXUP_AMIC, ALC269VB_FIXUP_DMIC, + ALC269_FIXUP_MIC1_MUTE_LED, ALC269_FIXUP_MIC2_MUTE_LED, ALC269_FIXUP_INV_DMIC, ALC269_FIXUP_LENOVO_DOCK, @@ -6171,6 +6195,10 @@ static const struct alc_fixup alc269_fixups[] = { { } }, }, + [ALC269_FIXUP_MIC1_MUTE_LED] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc269_fixup_mic1_mute, + }, [ALC269_FIXUP_MIC2_MUTE_LED] = { .type = ALC_FIXUP_FUNC, .v.func = alc269_fixup_mic2_mute, @@ -6215,6 +6243,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x029b, "Acer 1810TZ", ALC269_FIXUP_INV_DMIC), SND_PCI_QUIRK(0x1025, 0x0349, "Acer AOD260", ALC269_FIXUP_INV_DMIC), SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_MIC2_MUTE_LED), + SND_PCI_QUIRK(0x103c, 0x1972, "HP Pavilion 17", ALC269_FIXUP_MIC1_MUTE_LED), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_DMIC), SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_DMIC), SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW), -- 1.7.9.5

2 4

[alsa-devel] About Alsa arecord
by FF 07 Jan '13

07 Jan '13

Hello! There have 2 stereo ADCs support one stereo microphone and one legacy mixer recording simultaneously, said in the document of ALC888 Datasheet .I inputed 1KHz sine wave into every pins (Line1-R,Line1-L,MIC1-R,MIC1_L,MIC2-R,MIC2-L,LINE2-R,LINE2-L) of ALC888 by signal genrator,and used command 'arecord -c 4 -f S16_LE -r 44100 >test.wav' recording in fedora14.but ALL audio data are recorded in channel 1,2.No any data in channel 3,4.Why?How can I record every pins audio data in each channel? Thank you!Best regards.

2 1

[alsa-devel] Roland-Boss RC-300 support
by Jean-Samuel Reynaud 06 Jan '13

06 Jan '13

Hi All, I have a Boss RC-300 loop station with an USB connector. The windows driver add an audio device but it was not working under linux. So please find attached, the patch for supporting audio in this device. Note that midi is not working yet but I'm working on it... Regards,

2 1

Re: [alsa-devel] Missing exactly 3 of 8 audio packets?
by Daniel Griscom 06 Jan '13

06 Jan '13

Dear Daniel (M) and Clemens, I'd like to conclude this thread if I could. It seems clear that configuring our USB audio card's descriptor with a bInterval value of 1 (a packet every microframe) was too aggressive, and was part of what caused the packet stuttering issue. (Right?) We almost certainly should increase bInterval; I'll try 2, and if that seems stable will probably go to 3 (4 microframes) for some margin. However, I'm still concerned that the symptoms don't sound like a simple starvation issue, where I'd expect to have a missing frame every once in a while. Instead, we were seeing reliable operation interspersed with periods where lots of packets were being consistently omitted. To me, this suggests that there's some other issue going on, either in the USB stack or in the USB hardware itself. Given that, I'm worried that increasing bInterval will just move the symptoms around, making it harder to duplicate but not truly becoming robust. Any thoughts on this? Should I try chasing the issue into the Linux USB development mailing list, or will they just say "set bInterval to a larger value!"? Thanks, Dan -- Daniel T. Griscom griscom(a)suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400

2 1

Re: [alsa-devel] [PATCH v3 0/5] ARM: OMAP4+: HDMI: Update platform devices for audio
by Ricardo Neri 05 Jan '13

05 Jan '13

Hi Mark, Tomi, Just wondering if you had a chance to take a look at these patches. Thanks! Ricardo On 12/17/2012 07:30 PM, Ricardo Neri wrote: > Hi Mark, Tomi, Liam, Tony, > > This set aims to be the version 3 of my previous submission[1] and aims to > address the comments that Mark and Tomi kindly provided on such submission. > > The creation of the platform device for the HDMI audio interface from within the > OMAPDSS HDMI driver that was previously submitted[2] is resubmitted to be > complemented with code to relocate to arch/arm/mach-omap2/display.c the > creation of the platform devices for the HDMI ASoC codec and card drivers. This > series does not break the HDMI audio functionality in any patch. > > Also, the names of the platform devices are changed to give them more logical > and more descriptive names. > > As the commit > > commit 14840b9a83c6a56629db2ba0ec247503e975f143 > Author: Ricardo Neri <ricardo.n...(a)ti.com> > Date: Tue Nov 6 00:19:17 2012 -0600 > > OMAPDSS: HDMI: Create platform device for audio support > > is reverted in Tomi's git://gitorious.org/linux-omap-dss2/linux.git master > branch, this series applies cleanly. > > Changes from v1: > *Put in a single series all the patches related to platform device updates. > *Now HDMI audio works correctly in every patch. > *Remove reference to the TPD12S015 HDMI companion chip as the ASoC drivers > are not aware of this and other chips could be used in the future. > > Changes from v2: > *Split in two patches the renaming and the relocation of the platform devices. > *Create a separate patch to pass only the address offset of the DMA data port > to the audio interface platform device. > *Keep the name hdmi-audio-codec to not refer to explicitly to OMAP. The codec > can be made generic in a different patch series submitted to alsa-devel. > > BR, > > Ricardo > > > [1]. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80785.html > [2]. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79795.html > > Ricardo Neri (5): > ARM: OMAP4+: HDMI: Rename platform devices for ASoC drivers > ARM: OMAP4: Assign IDs to DSS HDMI devices > ARM4: OMAP4+: HDMI: Relocate devices for audio codec and card > ARM: OMAP4+: HDMI: Relocate the device for audio interface > ARM: OMAP4+: HDMI: Refine the DMA port resource for audio > > arch/arm/mach-omap2/board-4430sdp.c | 9 ++--- > arch/arm/mach-omap2/board-omap4panda.c | 9 ++--- > arch/arm/mach-omap2/devices.c | 31 ---------------- > arch/arm/mach-omap2/display.c | 31 ++++++++++++++++ > drivers/video/omap2/dss/hdmi.c | 62 ++++++++++++++++++++++++++++++++ > sound/soc/omap/omap-hdmi-card.c | 4 +-- > sound/soc/omap/omap-hdmi.c | 5 ++- > sound/soc/omap/omap-hdmi.h | 2 -- > 8 files changed, 103 insertions(+), 50 deletions(-) > > -- > 1.7.10.4 >

2 2

[alsa-devel] [PATCH] ASoC: wm2000: Fix sense of speech clarity enable
by Mark Brown 04 Jan '13

04 Jan '13

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm2000.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm2000.c b/sound/soc/codecs/wm2000.c index 1cbe88f..12bcae6 100644 --- a/sound/soc/codecs/wm2000.c +++ b/sound/soc/codecs/wm2000.c @@ -209,9 +209,9 @@ static int wm2000_power_up(struct i2c_client *i2c, int analogue) ret = wm2000_read(i2c, WM2000_REG_SPEECH_CLARITY); if (wm2000->speech_clarity) - ret &= ~WM2000_SPEECH_CLARITY; - else ret |= WM2000_SPEECH_CLARITY; + else + ret &= ~WM2000_SPEECH_CLARITY; wm2000_write(i2c, WM2000_REG_SPEECH_CLARITY, ret); wm2000_write(i2c, WM2000_REG_SYS_START0, 0x33); -- 1.7.10.4

1 0

[alsa-devel] [PATCH] ASoC: arizona: Allow runtime reconfiguration of the output mode
by Mark Brown 04 Jan '13

04 Jan '13

Some systems use external analogue switches to connect more analogue devices to the CODEC than are supported by the device. In some systems this requires changing the switched output from single ended to differential mode dynamically at runtime. Add a new function arizona_set_output_mode() to support this. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.c | 34 ++++++++++++++++++++++++++++++++++ sound/soc/codecs/arizona.h | 3 +++ 2 files changed, 37 insertions(+) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index 7724b4b..6d98cf4 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -1176,6 +1176,40 @@ int arizona_init_fll(struct arizona *arizona, int id, int base, int lock_irq, } EXPORT_SYMBOL_GPL(arizona_init_fll); +/** + * arizona_set_output_mode - Set the mode of the specified output + * + * @codec: Device to configure + * @output: Output number + * @diff: True to set the output to differential mode + * + * Some systems use external analogue switches to connect more + * analogue devices to the CODEC than are supported by the device. In + * some systems this requires changing the switched output from single + * ended to differential mode dynamically at runtime, an operation + * supported using this function. + * + * Most systems have a single static configuration and should use + * platform data instead. + */ +int arizona_set_output_mode(struct snd_soc_codec *codec, int output, bool diff) +{ + unsigned int reg, val; + + if (output < 1 || output > 6) + return -EINVAL; + + reg = ARIZONA_OUTPUT_PATH_CONFIG_1L + (output - 1) * 8; + + if (diff) + val = ARIZONA_OUT1_MONO; + else + val = 0; + + return snd_soc_update_bits(codec, reg, ARIZONA_OUT1_MONO, val); +} +EXPORT_SYMBOL_GPL(arizona_set_output_mode); + MODULE_DESCRIPTION("ASoC Wolfson Arizona class device support"); MODULE_AUTHOR("Mark Brown <broonie(a)opensource.wolfsonmicro.com>"); MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h index 68dfae5..697ff6f 100644 --- a/sound/soc/codecs/arizona.h +++ b/sound/soc/codecs/arizona.h @@ -213,4 +213,7 @@ extern int arizona_set_fll(struct arizona_fll *fll, int source, extern int arizona_init_dai(struct arizona_priv *priv, int dai); +int arizona_set_output_mode(struct snd_soc_codec *codec, int output, + bool diff); + #endif -- 1.7.10.4

1 0

Re: [alsa-devel] draft -- ALSA firewire + digi003
by Robin Gareus 04 Jan '13

04 Jan '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Clemens, Hi ALSA-devs, I'm working with Damien Zammit on the Digidesign-003 driver which is based on your alsa-kprivate dice code. We were able to work out most of the issues so far but are now stuck with timing problems. More specifically: the jitter of async message timing is quite large and the AMDTP ISO stream has regular drop-outs. Comparing 1394 data dumps, OSX sends async messages at regular 125 (+-5us) intervals. On GNU/Linux we've seen a delta -40us, + 120us. For async messages this is not a big deal. But.. Just playing audio via aplay: there are short dropouts every couple of seconds but otherwise the devices plays fine indefinitely. Interestingly, when running cyclictest while playing sound: there are no dropouts but the stream drops after ~10-15 seconds. Any hints why that may be or how to debug the issue further? In order to rule out kernel related issues (3.0.0 is quite old), we've rebased the work (and alsa-kprivate's firewire-kernel-streaming branch) onto alsa-driver.git. The issue remains the same with 3.2.0-4-rt Alas, neither of us has detailed knowledge nor specs for AMDTP, not to mention in-depth knowledge about Linux' firewire stack timings. Any help or leads are appreciated. As we believe we are close to a fully functional driver for the 003, we are very keen to resolve the following two separate issues: 1) The timing problem we have observed with AMDTP over firewire. 2) A framework for the capture stream in ALSA firewire. The rebased driver code is at git://gareus.org/alsa-driver.git http://gareus.org/gitweb/?p=alsa-driver.git The broken-out digi003 driver is available from: https://github.com/zamaudio/snd-firewire-003 https://github.com/x42/003amdtp 1394 bus data dumps of both OSX as well as Linux can be found at http://www.zamaudio.com/?p=715 Cheers! robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQ5t9CAAoJEKCQvOAs9X8ELbsP/Re0wxZKU6v2rbBVhV/FC6zr JYmx/jAsmoC7vtVZMKE4gGcCreszX58oU7RG323qR9iKSEgXeqtuThZSTT6l3N39 KpHW4T094FyQxmvxRYrZnRlHgWexvLfJT/YiuTUX50L/CKgS75ajRfLqADZaHSy5 Oc+CEy50Jmoi/9/dTuM0pVPVvt5APFqLyAisw1/5wzhYMTHF0mBByn5AHXBp7bIl SVg7IoJuTNd4dYgo3PtKw9OqhjMGZ1g5DNHA9OaE7qY12r3TMMKm7Sq2iWS4HQoq RMQLOVtyMOVUKyddK8ubWi0Cm2lYjHUXUNSLyZLcdWYTWbk5eWo6Ze83Tbl33h4T ngiWt+DWpqKpm+U0UQDOU6p+DSAosKHsVcPPPkYVkwXKAkHctXKlPUst5NHEhhK3 5mbVQECHE9+BBy9qY2eimDZ/p3+5C2kIMofDga6jiuFWfHMqKp30uacUHwP4xY38 jHLaTmpX7VNwNYGnFLvGve709ejNjL8ByFKrUKpV1nAMTO4QP4SipHuApBF3BWS7 hAGBD6mKQAPl6AhvuJaxtCdTQc/tkAF0Ep1LClthsHnyhqPVCX+L5sb/z7vVmCkp cFxGXJq6TujcW4kkKPfZCNsnHqea8lgY6tEonc8aRmcIZvF+L4Yp+p4/r9OxL6ma xIIgIVDp1X9HxVayBDWL =lVsY -----END PGP SIGNATURE-----

1 0

[alsa-devel] [PATCH 1/2] ASoC: arizona: Remove DSP B and left justified AIF modes
by Mark Brown 04 Jan '13

04 Jan '13

These are not supported. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index a4d7fb9..7724b4b 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -503,15 +503,9 @@ static int arizona_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) case SND_SOC_DAIFMT_DSP_A: mode = 0; break; - case SND_SOC_DAIFMT_DSP_B: - mode = 1; - break; case SND_SOC_DAIFMT_I2S: mode = 2; break; - case SND_SOC_DAIFMT_LEFT_J: - mode = 3; - break; default: arizona_aif_err(dai, "Unsupported DAI format %d\n", fmt & SND_SOC_DAIFMT_FORMAT_MASK); -- 1.7.10.4

1 1

Re: [alsa-devel] sound: usb-audio: [PATCH]x2 full capture/playback/spdif support for Digidesign Mbox 2
by Damien Zammit 04 Jan '13

04 Jan '13

On 23 December 2012 14:36, Damien Zammit <damien.zammit(a)gmail.com> wrote: > I have fixed both the kernel panic and the broken pipe issue with midi. > I believe this completes the patch, I just don't know how to submit it to you. Please find attached the patch you accepted previously: (Version 5) Plus an incremental patch (Version 5-2) ***Please ignore patch (Version 6)*** I hope this is the easiest way for you to review it. It compiles, runs, and works on the hardware now without errors. Thanks, Damien

2 6