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

[alsa-devel] [PATCH] ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist
by Takashi Iwai 09 Sep '13

09 Sep '13

Toshiba Satellite C870 shows interrupt problems occasionally when certain mixer controls like "Mic Switch" is toggled. This seems worked around by not using MSI. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index c6c9829..7f88dd6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -3400,6 +3400,7 @@ static struct snd_pci_quirk msi_black_list[] = { SND_PCI_QUIRK(0x1043, 0x81f2, "ASUS", 0), /* Athlon64 X2 + nvidia */ SND_PCI_QUIRK(0x1043, 0x81f6, "ASUS", 0), /* nvidia */ SND_PCI_QUIRK(0x1043, 0x822d, "ASUS", 0), /* Athlon64 X2 + nvidia MCP55 */ + SND_PCI_QUIRK(0x1179, 0xfb44, "Toshiba Satellite C870", 0), /* AMD Hudson */ SND_PCI_QUIRK(0x1849, 0x0888, "ASRock", 0), /* Athlon64 X2 + nvidia */ SND_PCI_QUIRK(0xa0a0, 0x0575, "Aopen MZ915-M", 0), /* ICH6 */ {} -- 1.8.4

1 0

[alsa-devel] Help with editing the Raw Midi data with ALSA?
by Ember Autumn Rose Leona 09 Sep '13

09 Sep '13

Dear ALSA team, I just joined the mailing list on after being referred to it. Is it possible for me to edit the Raw Midi data with ALSA... I looked a RtMidi and that opens a port but doesn't help me Midi Poison or Midi Message Map. What I want to do is edit the Midi Messages, re-mapping the notes. I simply want to flip the progression of the keys on a midi piano from high notes to low notes. On the fly. Basically I want to take the note on message byte and use the note number as an index for an array of remapped keys. I want to flip the keyboard on a D note for now... then later allow users to turn this remapping off and on (on the fly.) Also it would be nice to have certain note ranges mapped to different programs/patches. -Ember PS> I wish I could help test the sound drivers... but I only have an inexpensive intel integrated sound chip and I am on a dell which needs to be replaced with something par.

3 5

[alsa-devel] where to get snd_pcm_hardware info when usb audio device plug in?
by loody 09 Sep '13

09 Sep '13

hi all: is it possible to get snd_pcm_hardware information in /proc, /sys or anywhere when usb audio device plug in? if no, is there api I can take in usermode to get snd_pcm_hardware of this usb audio device? -- Thanks for your great help,

2 6

[alsa-devel] [PATCH] ALSA: snd-usb: sample rate detection workaround for Axe-Fx II
by Daniel Mack 08 Sep '13

08 Sep '13

Fractal Audio Systems Axe-Fx II and maybe other devices fail to return their sample rate range descriptor when only asked for the first two bytes. Add a workaround and assume exactly one sample rate in this case, and continue with the full descriptor fetch. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Reported-and-tested-by: Joachim Gahl <joachim.gahl(a)web.de> --- sound/usb/format.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/sound/usb/format.c b/sound/usb/format.c index 3525231..d9de43d 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -297,13 +297,17 @@ static int parse_audio_format_rates_v2(struct snd_usb_audio *chip, snd_usb_ctrl_intf(chip) | (clock << 8), tmp, sizeof(tmp)); - if (ret < 0) { - snd_printk(KERN_ERR "%s(): unable to retrieve number of sample rates (clock %d)\n", - __func__, clock); - goto err; - } + /* + * Some devices, including Fractal Audio Systems Axe-Fx II, fail to + * return only a fraction of this descriptor. If that happens, assume + * we have only one sample rate and continue. In case of any other + * error, we will bail on the full descriptor fetch below. + */ + if (ret < 0) + nr_triplets = 1; + else + nr_triplets = combine_word(tmp); - nr_triplets = (tmp[1] << 8) | tmp[0]; data_size = 2 + 12 * nr_triplets; data = kzalloc(data_size, GFP_KERNEL); if (!data) { @@ -319,8 +323,9 @@ static int parse_audio_format_rates_v2(struct snd_usb_audio *chip, data, data_size); if (ret < 0) { - snd_printk(KERN_ERR "%s(): unable to retrieve sample rate range (clock %d)\n", - __func__, clock); + snd_printk(KERN_ERR "%s(): unable to retrieve sample rate range " + "(clock %d, nr_triplets %d)\n", + __func__, clock, nr_triplets); ret = -EINVAL; goto err_free; } -- 1.8.3.1

1 1

[alsa-devel] [PATCH] ASoC: fsl_spdif: Select regmap-mmio
by Mark Brown 08 Sep '13

08 Sep '13

From: Mark Brown <broonie(a)linaro.org> The S/PDIF driver needs regmap so select it to make sure it gets included in the build. Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/fsl/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index 704e246..b7ab71f 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -198,6 +198,7 @@ config SND_SOC_IMX_SPDIF select SND_SOC_IMX_PCM_DMA select SND_SOC_FSL_SPDIF select SND_SOC_SPDIF + select REGMAP_MMIO help SoC Audio support for i.MX boards with S/PDIF Say Y if you want to add support for SoC audio on an i.MX board with -- 1.8.4.rc3

2 1

[alsa-devel] alsa crash with “ ALSA sound/usb/urb.c:179 cannot submit urb (err = -27)” on imx6q sabrelite
by Ankit Agarwal 08 Sep '13

08 Sep '13

I am using alsa pcm player to listen to audio. The alsa pcm crashes with the error: ALSA sound/usb/urb.c:179 cannot submit urb (err = -27). I am able to hear the data initially but when other transaction begins on HID report endpoint, alsa crashes with the mentioned error. I am working on imx6q board with linux kernel-3.0.35. I am using Apple device to get the digital audio. -- Best Regards, Ankit Agarwal

2 1

[alsa-devel] US-1641 drivers involvment
by Luca Novarini 08 Sep '13

08 Sep '13

Hello, I would participate, if possible, in the ALSA development to add support to the USB card Tascam US-1641. Any reply or help from who tried in this task before is really really appreciated. Thank you! Bye. LL

3 4

[alsa-devel] Request for information
by Michael Jordan 07 Sep '13

07 Sep '13

Hello, I am developing a driver for the PCM3168A. We have created an expansion board with the codec, op-amp buffers, etc. which is designed to connect to the audio expansion connector on an OMAPL138 EXPKIT from LogicPD. I have the rough draft of the pcm3168a.c and pcm3168a.h. Looking through the code, I see that the DA850 is "hard-wired" in the code to expect the TLV320AIC3106, which is the on-board codec on the kit. My question is, would it be proper for me to create entries in davinci-evm.c, mach-types.h, etc. in order to provide a way to register this new driver? Or is there a different way I should proceed? I'll be modifying my code base for testing purposes, but when it comes time for submission, I would like to know the proper way to handle this. Thank you, Michael

1 0

[alsa-devel] [PATCH v2 2/2] ALSA: hda - unmute pin amplifier in infoframe setup for Haswell
by mengdong.lin＠intel.com 06 Sep '13

06 Sep '13

From: Mengdong Lin <mengdong.lin(a)intel.com> When Gfx driver reconnects a port and transcoder, the pin amplifier will be muted. To enable sound, the pin amp need to be unmuted. This patch - moves pin amp unmuting from stream preparing to hdmi_setup_audio_infoframe(). So if port:transcoder reconnection happens during stream playback, the ELDV unsol event can stil trigger pin's amp unmuting when re-setting up audio info frame. - remove reading pin amp status before unmuting for speed-up, since pin amp should always be unmuted. - rename haswell_verify_pin_D0() to haswell_verify_D0(), since the convertor power state is also fixed here. This patch is mostly based on suggestion of David Henningsson. Cc: David Henningsson <david.henningsson(a)canonical.com> 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 974b55c..3d8cd044 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -896,6 +896,11 @@ static void hdmi_setup_audio_infoframe(struct hda_codec *codec, if (!channels) return; + if (is_haswell(codec)) + snd_hda_codec_write(codec, pin_nid, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AMP_OUT_UNMUTE); + eld = &per_pin->sink_eld; if (!eld->monitor_present) return; @@ -1035,10 +1040,10 @@ static void hdmi_unsol_event(struct hda_codec *codec, unsigned int res) hdmi_non_intrinsic_event(codec, res); } -static void haswell_verify_pin_D0(struct hda_codec *codec, +static void haswell_verify_D0(struct hda_codec *codec, hda_nid_t cvt_nid, hda_nid_t nid) { - int pwr, lamp, ramp; + int pwr; /* For Haswell, the converter 1/2 may keep in D3 state after bootup, * thus pins could only choose converter 0 for use. Make sure the @@ -1054,25 +1059,6 @@ static void haswell_verify_pin_D0(struct hda_codec *codec, pwr = (pwr & AC_PWRST_ACTUAL) >> AC_PWRST_ACTUAL_SHIFT; snd_printd("Haswell HDMI audio: Power for pin 0x%x is now D%d\n", nid, pwr); } - - lamp = snd_hda_codec_read(codec, nid, 0, - AC_VERB_GET_AMP_GAIN_MUTE, - AC_AMP_GET_LEFT | AC_AMP_GET_OUTPUT); - ramp = snd_hda_codec_read(codec, nid, 0, - AC_VERB_GET_AMP_GAIN_MUTE, - AC_AMP_GET_RIGHT | AC_AMP_GET_OUTPUT); - if (lamp != ramp) { - snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE, - AC_AMP_SET_RIGHT | AC_AMP_SET_OUTPUT | lamp); - - lamp = snd_hda_codec_read(codec, nid, 0, - AC_VERB_GET_AMP_GAIN_MUTE, - AC_AMP_GET_LEFT | AC_AMP_GET_OUTPUT); - ramp = snd_hda_codec_read(codec, nid, 0, - AC_VERB_GET_AMP_GAIN_MUTE, - AC_AMP_GET_RIGHT | AC_AMP_GET_OUTPUT); - snd_printd("Haswell HDMI audio: Mute after set on pin 0x%x: [0x%x 0x%x]\n", nid, lamp, ramp); - } } /* @@ -1090,7 +1076,7 @@ static int hdmi_setup_stream(struct hda_codec *codec, hda_nid_t cvt_nid, int new_pinctl = 0; if (is_haswell(codec)) - haswell_verify_pin_D0(codec, cvt_nid, pin_nid); + haswell_verify_D0(codec, cvt_nid, pin_nid); if (snd_hda_query_pin_caps(codec, pin_nid) & AC_PINCAP_HBR) { pinctl = snd_hda_codec_read(codec, pin_nid, 0, @@ -1361,13 +1347,9 @@ static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll) * changed during the stream playback */ if (is_haswell(codec) && - eld->eld_valid && !old_eld_valid && per_pin->setup) { - snd_hda_codec_write(codec, pin_nid, 0, - AC_VERB_SET_AMP_GAIN_MUTE, - AMP_OUT_UNMUTE); + eld->eld_valid && !old_eld_valid && per_pin->setup) hdmi_setup_audio_infoframe(codec, per_pin, per_pin->non_pcm); - } } mutex_unlock(&pin_eld->lock); -- 1.8.1.2

2 1

[alsa-devel] [PATCH] ALSA: hda - Add dock speaker support for ASUS TX300
by Takashi Iwai 06 Sep '13

06 Sep '13

ASUS TX300 has a built-in speaker in the tablet part and in the dock part, and the tablet speaker is supposed to be unused while the machine is docked. The current HD-audio driver, however, doesn't support the dock speaker, partly because BIOS doesn't set up the pin for the corresponding output. But, not only the missing pin config, also the missing unsol event handling is another issue. Otherwise the automatic switching via dock/undock won't work. Through debugging sessions, we found out that the dock speaker pin is NID 0x1b, and it generates an unsol event at docking/undocking, the docking state can be inquired via the normal pin detection verb. Also, it's turned out that GPIO 2 is needed as an amp. So, all materials are ready to cook. This patch provides the basic dock speaker support with TX300: - The dock speaker is turned on/off via "Dock Speaker" mixer mute. - The dock speaker is automatically muted when docked. This is independently from the mixer mute switch, just like the headphone auto-mute function. The implementation is a bit tricky. Since we want to handle it as a secondary speaker, we set it up a pin as a speaker with a jack detection. Then, the fixup function registers the own unsol callback for this pin because the standard automute can't handle the thing like a "speaker jack". In the own automute hook, we apply the mute of the tablet speaker in addition by checking the dock state. Also, the speaker control names are slightly shuffled because the generic parser doesn't give good names but blindly assumes a bass speaker as a secondary speaker. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59791 Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_realtek.c | 56 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 4a90917..d38d6a0 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3443,6 +3443,56 @@ static void alc283_fixup_chromebook(struct hda_codec *codec, } } +/* mute tablet speaker pin (0x14) via dock plugging in addition */ +static void asus_tx300_automute(struct hda_codec *codec) +{ + struct alc_spec *spec = codec->spec; + snd_hda_gen_update_outputs(codec); + if (snd_hda_jack_detect(codec, 0x1b)) + spec->gen.mute_bits |= (1ULL << 0x14); +} + +static void alc282_fixup_asus_tx300(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + /* TX300 needs to set up GPIO2 for the speaker amp */ + static const struct hda_verb gpio2_verbs[] = { + { 0x01, AC_VERB_SET_GPIO_MASK, 0x04 }, + { 0x01, AC_VERB_SET_GPIO_DIRECTION, 0x04 }, + { 0x01, AC_VERB_SET_GPIO_DATA, 0x04 }, + {} + }; + static const struct hda_pintbl dock_pins[] = { + { 0x1b, 0x21114000 }, /* dock speaker pin */ + {} + }; + struct snd_kcontrol *kctl; + + switch (action) { + case HDA_FIXUP_ACT_PRE_PROBE: + snd_hda_add_verbs(codec, gpio2_verbs); + snd_hda_apply_pincfgs(codec, dock_pins); + spec->gen.auto_mute_via_amp = 1; + spec->gen.automute_hook = asus_tx300_automute; + snd_hda_jack_detect_enable_callback(codec, 0x1b, + HDA_GEN_HP_EVENT, + snd_hda_gen_hp_automute); + break; + case HDA_FIXUP_ACT_BUILD: + /* this is a bit tricky; give more sane names for the main + * (tablet) speaker and the dock speaker, respectively + */ + kctl = snd_hda_find_mixer_ctl(codec, "Speaker Playback Switch"); + if (kctl) + strcpy(kctl->id.name, "Dock Speaker Playback Switch"); + kctl = snd_hda_find_mixer_ctl(codec, "Bass Speaker Playback Switch"); + if (kctl) + strcpy(kctl->id.name, "Speaker Playback Switch"); + break; + } +} + enum { ALC269_FIXUP_SONY_VAIO, ALC275_FIXUP_SONY_VAIO_GPIO2, @@ -3480,6 +3530,7 @@ enum { ALC269_FIXUP_LIMIT_INT_MIC_BOOST, ALC269VB_FIXUP_ORDISSIMO_EVE2, ALC283_FIXUP_CHROME_BOOK, + ALC282_FIXUP_ASUS_TX300, }; static const struct hda_fixup alc269_fixups[] = { @@ -3735,6 +3786,10 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc283_fixup_chromebook, }, + [ALC282_FIXUP_ASUS_TX300] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc282_fixup_asus_tx300, + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -3784,6 +3839,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x1983, "HP Pavilion", ALC269_FIXUP_HP_MUTE_LED_MIC1), SND_PCI_QUIRK(0x103c, 0x21ed, "HP Falco Chromebook", ALC283_FIXUP_CHROME_BOOK), SND_PCI_QUIRK_VENDOR(0x103c, "HP", ALC269_FIXUP_HP_MUTE_LED), + SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC282_FIXUP_ASUS_TX300), SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x1043, 0x115d, "Asus 1015E", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_DMIC), -- 1.8.4

1 0