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

Re: [alsa-devel] [PATCH 2.6.39-rc3] hda_intel: ALSA HD Audio patch for Intel Panther Point DeviceIDs
by Takashi Iwai 09 Oct '12

09 Oct '12

At Wed, 20 Apr 2011 10:59:57 -0700, Seth Heasley wrote: > > This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH. > > Signed-off-by: Seth Heasley <seth.heasley(a)intel.com> Applied now. Thanks. Takashi > --- > --- linux-2.6.39-rc3/sound/pci/hda/hda_intel.c.orig 2011-04-11 17:21:51.000000000 -0700 > +++ linux-2.6.39-rc3/sound/pci/hda/hda_intel.c 2011-04-14 11:44:40.000000000 -0700 > @@ -126,6 +126,7 @@ > "{Intel, ICH10}," > "{Intel, PCH}," > "{Intel, CPT}," > + "{Intel, PPT}," > "{Intel, PBG}," > "{Intel, SCH}," > "{ATI, SB450}," > @@ -2759,6 +2760,8 @@ > { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH }, > /* PBG */ > { PCI_DEVICE(0x8086, 0x1d20), .driver_data = AZX_DRIVER_PCH }, > + /* Panther Point */ > + { PCI_DEVICE(0x8086, 0x1e20), .driver_data = AZX_DRIVER_PCH }, > /* SCH */ > { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH }, > /* Generic Intel */ >

3 2

[alsa-devel] [PATCH] snd-usb-us122l: Fix missing NULL checks
by Karsten Wiese 27 Apr '12

27 Apr '12

Fix missing NULL checks in usb_stream_hwdep_poll() and usb_stream_hwdep_ioctl(). Wake up poll waiters before returning from usb_stream_hwdep_ioctl(). Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de> Cc: stable(a)kernel.org --- sound/usb/usx2y/us122l.c | 41 ++++++++++++++++++++--------------------- 1 files changed, 20 insertions(+), 21 deletions(-) diff --git a/sound/usb/usx2y/us122l.c b/sound/usb/usx2y/us122l.c index 91bb296..7abda8d 100644 --- a/sound/usb/usx2y/us122l.c +++ b/sound/usb/usx2y/us122l.c @@ -269,29 +269,26 @@ static unsigned int usb_stream_hwdep_poll(struct snd_hwdep *hw, struct file *file, poll_table *wait) { struct us122l *us122l = hw->private_data; - struct usb_stream *s = us122l->sk.s; unsigned *polled; unsigned int mask; poll_wait(file, &us122l->sk.sleep, wait); - switch (s->state) { - case usb_stream_ready: - if (us122l->first == file) - polled = &s->periods_polled; - else - polled = &us122l->second_periods_polled; - if (*polled != s->periods_done) { - *polled = s->periods_done; - mask = POLLIN | POLLOUT | POLLWRNORM; - break; + mask = POLLIN | POLLOUT | POLLWRNORM | POLLERR; + if (mutex_trylock(&us122l->mutex)) { + struct usb_stream *s = us122l->sk.s; + if (s && s->state == usb_stream_ready) { + if (us122l->first == file) + polled = &s->periods_polled; + else + polled = &us122l->second_periods_polled; + if (*polled != s->periods_done) { + *polled = s->periods_done; + mask = POLLIN | POLLOUT | POLLWRNORM; + } else + mask = 0; } - /* Fall through */ - mask = 0; - break; - default: - mask = POLLIN | POLLOUT | POLLWRNORM | POLLERR; - break; + mutex_unlock(&us122l->mutex); } return mask; } @@ -377,6 +374,7 @@ static int usb_stream_hwdep_ioctl(struct snd_hwdep *hw, struct file *file, { struct usb_stream_config *cfg; struct us122l *us122l = hw->private_data; + struct usb_stream *s; unsigned min_period_frames; int err = 0; bool high_speed; @@ -422,18 +420,18 @@ static int usb_stream_hwdep_ioctl(struct snd_hwdep *hw, struct file *file, snd_power_wait(hw->card, SNDRV_CTL_POWER_D0); mutex_lock(&us122l->mutex); + s = us122l->sk.s; if (!us122l->master) us122l->master = file; else if (us122l->master != file) { - if (memcmp(cfg, &us122l->sk.s->cfg, sizeof(*cfg))) { + if (!s || memcmp(cfg, &s->cfg, sizeof(*cfg))) { err = -EIO; goto unlock; } us122l->slave = file; } - if (!us122l->sk.s || - memcmp(cfg, &us122l->sk.s->cfg, sizeof(*cfg)) || - us122l->sk.s->state == usb_stream_xrun) { + if (!s || memcmp(cfg, &s->cfg, sizeof(*cfg)) || + s->state == usb_stream_xrun) { us122l_stop(us122l); if (!us122l_start(us122l, cfg->sample_rate, cfg->period_frames)) err = -EIO; @@ -444,6 +442,7 @@ unlock: mutex_unlock(&us122l->mutex); free: kfree(cfg); + wake_up_all(&us122l->sk.sleep); return err; } -- 1.7.2.3

2 5

[alsa-devel] [PATCH] ALSA: HDA: Remove unconnected PCM devices for Intel HDMI
by David Henningsson 01 Feb '12

01 Feb '12

Since I'm a little new in HDMI land and the patch is non-trivial, I wouldn't mind some comments on this one. Also thanks to Jaroslav who cleared a few things out about the logical and physical devices which helped me figure out what I should do about it :-) Anyway, here's the patch. Some newer chips have more than one HDMI output, but usually not all of them are exposed as physical jacks. Removing the unused PCM devices (as indicated by BIOS in the pin config default) will reduce user confusion as they currently have to choose between several HDMI devices, some of them not working anyway. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

4 14

Re: [alsa-devel] [patch][saa7134] do not change mute state for capturing audio
by Mauro Carvalho Chehab 03 Dec '11

03 Dec '11

Em 24-07-2011 14:45, Stas Sergeev escreveu: > 23.07.2011 19:09, Mauro Carvalho Chehab wrote: >> > In this case, it will not be autounmuted after tuning. >> Hard to tell about your solution without seeing a patch. > OK, it turns out the automute code is already there, > but it doesn't work. The driver for some reasons > starts the scan on initialization, finds the carrier: > --- > saa7134[0]/audio: found PAL main sound carrier @ 6.000 MHz [3969/324] > --- > and, because of that, disables the automute. If the > real mute is not enabled at that point, you get the > white noise right away. The automute code works fine. Maybe you have a strong interference at the default tuning frequency, leading into saa7134 miss-detection. For saa7134 driver: 1) There is an audio carrier; 2) an application wants to listen audio; 3) the device is at automute mode. So, when there's an audio carrier, it will unmute the audio at streaming start. The driver is doing the _right_ thing by letting the audio to flow to PA, when it starts the capture. Unfortunately, on your specific device, starting audio capture also enables audio at the audio output pin. So, you're noticing a problem. People with a saa7134 device without alsa stream won't notice it (old devices). People with alsa stream without anything connected to the LINE OUT people aren't noticing it, if PA is not copying the saa7134 PCM IN stream to the sound card PCM out device (the default, for PA). So, only people that has saa7134 with alsa stream that opted to wire the saa7134 device to the sound card, and with a strong interference at the default tunning frequency (400 MHz) would notice a problem. > Since I have no idea why it finds some carrier, I can't > fix that in any way. Or, maybe, not to call the scan > on driver init? What will that break? Analog tuners need to be tuned at the device init on a high frequency according with their datasheets, otherwise the PLL may fail. > Anyway, as long as the automute code is broken, > we should either start fixing it, or fix PA, or fix mplayer... As I always said, the fix should be at PA, as it makes no sense to start capturing at saa7134 without first configuring it. So, or PA should be converted into a V4L2-aware application, in order to properly init the device (with seems to be the wrong approach) or it _SHOULD_NOT_ automatically enable capture on those devices, as this may cause undesired side effects, on the devices that have the capture pin directly wired to the output pin, witch seems to be the case of your device. PS.: it seems that you've removed Lennart/alsa people from the c/c. I'm re-adding them, as I'm expecting a fix from their side. > Dunno. I wonder how come so many bugs left unfixed > for so long, resulting in a white noise to people... You're the first one that reported it, and the code is there for _years_. So, this is not a commonly noticed problem at all. Mauro.

2 15

Re: [alsa-devel] max channels of 3 jacks 6 channels motherboard using model=auto realtek codec
by Takashi Iwai 20 Oct '11

20 Oct '11

At Sun, 10 Jul 2011 08:47:46 +0200, Takashi Iwai wrote: > > At Sun, 10 Jul 2011 11:31:44 +0800, > Raymond Yau wrote: > > > > 2011/7/6 Takashi Iwai <tiwai(a)suse.de>: > > > At Wed, 6 Jul 2011 11:53:47 +0800, > > > Raymond Yau wrote: > > >> > > >> Refer to commit ce764ab22e40a046065c9417ee5f04ad2a816ac1 > > >> > > >> ALSA: hda - Add channel-mode support to Realtek auto-parser > > >> > > >> It seem that max channel is six instead of two when the channel mode > > >> is 2ch for those 3 jacks motherboard > > >> > > >> using hda-emu and alsa-info from > > >> http://thread.gmane.org/gmane.linux.alsa.devel/86816 > > >> > > >> > PCM 0 p 44100 2 16 > > >> Open PCM ALC887 Analog for play > > >> Available PCM parameters: > > >> channels: 2/6 > > >> formats: S16_LE S32_LE > > >> rates: 44100 48000 96000 192000 > > >> Prepare PCM, rate=44100, channels=2, format=16 bits > > >> > > >> > > >> because > > >> > > >> spec->multiout.max_channels = spec->multiout.num_dacs * 2; > > >> > > >> is assigned after alc_auto_add_multi_channel_mode() increase > > >> spec->multiout.num_dacs from 1 to 3 > > >> > > >> spec->multiout.num_dacs = num_pins + 1; > > > > > > Right, and this is intentional. Since there should be enough amount > > > of DACs, the driver keeps using the surround DACs statically. > > > In that way, apps can keep opening the device in the surround mode > > > while user can switch the outputs on the fly via channel-mode mixer > > > enum. > > > > > > > > > > How can the driver support 6 channels when the input jacks have not > > been retasked as output ? > > Even if the pins aren't retasked, DACs can receive data. And then > you can change the pins and routing on the fly. > > You can open a two-channel PCM stream even if the master or (any > other) volume is muted. A similar reason. > > > This behaviour seem different from model=3stack-6ch or > > model=3stack-6ch-dig or those via codec with smart51 "OFF" The smart51 case is a bit different (we prefer DAC unused because of independent HP control), but the 3stack-6ch case is a regression, indeed. This was just because of dropped code snippet. Now I fixed with the patch below. thanks, Takashi --- From: Takashi Iwai <tiwai(a)suse.de> Subject: [PATCH] ALSA: hda - Re-add need_dac_fix check for multi-io jacks of Realtek codecs During the rewrite, the check of spec->need_dac_fix and the corresponding num_dacs change was dropped from the channel-mode control. This patch re-adds it, and also enables need_dac_fix for ALC880 as default, as this feature was originally introduced to fix h/w bugs of this chip. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_realtek.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 124c63f..52ce075 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3196,6 +3196,8 @@ static int alc_auto_ch_mode_put(struct snd_kcontrol *kcontrol, for (i = 0; i < spec->multi_ios; i++) alc_set_multi_io(codec, i, i < ch); spec->multiout.max_channels = spec->ext_channel_count; + if (spec->need_dac_fix && !spec->const_channel_count) + spec->multiout.num_dacs = spec->multiout.max_channels / 2; return 1; } @@ -3642,6 +3644,7 @@ static int patch_alc880(struct hda_codec *codec) codec->spec = spec; spec->mixer_nid = 0x0b; + spec->need_dac_fix = 1; board_config = alc_board_config(codec, ALC880_MODEL_LAST, alc880_models, alc880_cfg_tbl); -- 1.7.6

2 1

[alsa-devel] [PATCH] ASoC: WM8903: Implement DMIC support
by Stephen Warren 14 Oct '11

14 Oct '11

In addition to the currently supported analog capture path, the WM8903 also supports digital mics. The analog and digital capture paths are exclusive; a mux is present to select the capture source. Logically, the mux exists to select the decimator's input, from either the ADC or DMIC block outputs. However, the ADC power domain also includes the DMIC interface. Consequently, this change represents the mux as existing immediately before the ADC, and selecting between the Input PGA and DMIC block outputs. An alternative might be to represent the mux in its correct location, and associate the ADC power enable controls with both the real ADC, and a fake ADC for the DMIC? Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/codecs/wm8903.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8903.c b/sound/soc/codecs/wm8903.c index d53f206..f3cab84 100644 --- a/sound/soc/codecs/wm8903.c +++ b/sound/soc/codecs/wm8903.c @@ -634,6 +634,13 @@ static const struct soc_enum lsidetone_enum = static const struct soc_enum rsidetone_enum = SOC_ENUM_SINGLE(WM8903_DAC_DIGITAL_0, 0, 3, sidetone_text); +static const char *adcinput_text[] = { + "ADC", "DMIC" +}; + +static const struct soc_enum adcinput_enum = + SOC_ENUM_SINGLE(WM8903_CLOCK_RATE_TEST_4, 9, 2, adcinput_text); + static const char *aif_text[] = { "Left", "Right" }; @@ -767,6 +774,9 @@ static const struct snd_kcontrol_new lsidetone_mux = static const struct snd_kcontrol_new rsidetone_mux = SOC_DAPM_ENUM("DACR Sidetone Mux", rsidetone_enum); +static const struct snd_kcontrol_new adcinput_mux = + SOC_DAPM_ENUM("ADC Input", adcinput_enum); + static const struct snd_kcontrol_new lcapture_mux = SOC_DAPM_ENUM("Left Capture Mux", lcapture_enum); @@ -817,6 +827,7 @@ SND_SOC_DAPM_INPUT("IN2L"), SND_SOC_DAPM_INPUT("IN2R"), SND_SOC_DAPM_INPUT("IN3L"), SND_SOC_DAPM_INPUT("IN3R"), +SND_SOC_DAPM_INPUT("DMICDAT"), SND_SOC_DAPM_OUTPUT("HPOUTL"), SND_SOC_DAPM_OUTPUT("HPOUTR"), @@ -842,6 +853,9 @@ SND_SOC_DAPM_MUX("Right Input Mode Mux", SND_SOC_NOPM, 0, 0, &rinput_mode_mux), SND_SOC_DAPM_PGA("Left Input PGA", WM8903_POWER_MANAGEMENT_0, 1, 0, NULL, 0), SND_SOC_DAPM_PGA("Right Input PGA", WM8903_POWER_MANAGEMENT_0, 0, 0, NULL, 0), +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), + SND_SOC_DAPM_ADC("ADCL", NULL, WM8903_POWER_MANAGEMENT_6, 1, 0), SND_SOC_DAPM_ADC("ADCR", NULL, WM8903_POWER_MANAGEMENT_6, 0, 0), @@ -979,6 +993,11 @@ static const struct snd_soc_dapm_route wm8903_intercon[] = { { "Left Input PGA", NULL, "Left Input Mode Mux" }, { "Right Input PGA", NULL, "Right Input Mode Mux" }, + { "Left ADC Input", "ADC", "Left Input PGA" }, + { "Left ADC Input", "DMIC", "DMICDAT" }, + { "Right ADC Input", "ADC", "Right Input PGA" }, + { "Right ADC Input", "DMIC", "DMICDAT" }, + { "Left Capture Mux", "Left", "ADCL" }, { "Left Capture Mux", "Right", "ADCR" }, @@ -988,9 +1007,9 @@ static const struct snd_soc_dapm_route wm8903_intercon[] = { { "AIFTXL", NULL, "Left Capture Mux" }, { "AIFTXR", NULL, "Right Capture Mux" }, - { "ADCL", NULL, "Left Input PGA" }, + { "ADCL", NULL, "Left ADC Input" }, { "ADCL", NULL, "CLK_DSP" }, - { "ADCR", NULL, "Right Input PGA" }, + { "ADCR", NULL, "Right ADC Input" }, { "ADCR", NULL, "CLK_DSP" }, { "Left Playback Mux", "Left", "AIFRXL" }, -- 1.7.1

4 4

[alsa-devel] [PATCH] ASoC: sdp4430: Fix string for FM input name
by Peter Ujfalusi 26 Sep '11

26 Sep '11

The name contains invalid valid character (/), which causes problems when trying to create the debugfs directory structure: ASoC: Failed to create Aux/FM Stereo In debugfs file Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/omap/sdp4430.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/omap/sdp4430.c b/sound/soc/omap/sdp4430.c index a951774..d462f1a 100644 --- a/sound/soc/omap/sdp4430.c +++ b/sound/soc/omap/sdp4430.c @@ -88,7 +88,7 @@ static const struct snd_soc_dapm_widget sdp4430_twl6040_dapm_widgets[] = { SND_SOC_DAPM_MIC("Headset Mic", NULL), SND_SOC_DAPM_HP("Headset Stereophone", NULL), SND_SOC_DAPM_SPK("Earphone Spk", NULL), - SND_SOC_DAPM_INPUT("Aux/FM Stereo In"), + SND_SOC_DAPM_INPUT("FM Stereo In"), }; static const struct snd_soc_dapm_route audio_map[] = { @@ -113,8 +113,8 @@ static const struct snd_soc_dapm_route audio_map[] = { {"Earphone Spk", NULL, "EP"}, /* Aux/FM Stereo In: AFML, AFMR */ - {"AFML", NULL, "Aux/FM Stereo In"}, - {"AFMR", NULL, "Aux/FM Stereo In"}, + {"AFML", NULL, "FM Stereo In"}, + {"AFMR", NULL, "FM Stereo In"}, }; static int sdp4430_twl6040_init(struct snd_soc_pcm_runtime *rtd) -- 1.7.6

3 4

[alsa-devel] [PATCH 0/3] Fallback mechanism for pulse plugin
by Takashi Iwai 25 Sep '11

25 Sep '11

Hi, the following are experimental patches for implementing the fallback option of PCM / control pulse plugin. When the connection to PA server fails, the plugin tries to open the fallback name. For achieving this, I added the new standard definition "sysdefault", which is equal with the normal "default" PCM / control definitions. The difference is only the name, i.e. it won't be overridden by other setups. Then two new API functions for opening a fallback PCM / control, and finally a patch for pulse-plugin will follow. All changes are relatively small and easy. Let me know if you have any suggestions or a better idea. thanks, Takashi

5 23

[alsa-devel] [PATCHv2] ASoC: omap-mcbsp: Do not attempt to change DAI sysclk if stream is active
by Jarkko Nikula 23 Sep '11

23 Sep '11

Attempt to change McBSP CLKS source while another stream is active is not safe after commit d135865 ("OMAP: McBSP: implement functional clock switching via clock framework") in 2.6.37. CLKS parent clock switching using clock framework have to idle the McBSP before switching and then activate it again. This short break can cause a DMA transaction error to already running stream which halts and recovers only by closing and restarting the stream. This goes more fatal after commit e2fa61d ("OMAP3: l3: Introduce l3-interconnect error handling driver") in 2.6.39 where l3 driver detects a severe timeout error and does BUG_ON(). Fix this by not changing any configuration in omap_mcbsp_dai_set_dai_sysclk if the McBSP is already active. This test should have been here just from the beginning anyway. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> Cc: stable(a)kernel.org --- v2: - Returns -EBUSY from omap_mcbsp_dai_set_dai_sysclk if the input clock rate doesn't match with another stream's configuration and 0 otherwise. For 2.6.37 and onward. This issue is valid to those machine drivers that use the McBSP as a DAI link master and are configuring the CLKS source (like sound/soc/omap/omap3pandora.c in mainline). --- sound/soc/omap/omap-mcbsp.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 07b7723..4b82290 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -516,6 +516,12 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai, struct omap_mcbsp_reg_cfg *regs = &mcbsp_data->regs; int err = 0; + if (mcbsp_data->active) + if (freq == mcbsp_data->in_freq) + return 0; + else + return -EBUSY; + /* The McBSP signal muxing functions are only available on McBSP1 */ if (clk_id == OMAP_MCBSP_CLKR_SRC_CLKR || clk_id == OMAP_MCBSP_CLKR_SRC_CLKX || -- 1.7.4.4

4 5

[alsa-devel] Noise on snd-hda-intel
by Sune Mølgaard 18 Sep '11

18 Sep '11

Plugging almost any headset into the front headset jacks on my machine results in noise in the headphones as well as in Skype conversations and/or recording. Said noise is, however not head in the regular speakers (except when playing back recordings, of course. lspci -vvnn gives 00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller [8086:3a3e] Subsystem: ASUSTeK Computer Inc. Device [1043:82ea] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 256 bytes Interrupt: pin A routed to IRQ 70 Region 0: Memory at f7ff8000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel and aplay -l gives **** List of PLAYBACK Hardware Devices **** card 0: Device [USB Multimedia Audio Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 I have tried with no modules options as well as options snd_hda_intel model=6stack and options snd_hda_intel model=6stack-dig Best regards, Sune Mølgaard -- You buy Windows, and you put it on your machine-you can't do a whole lot with it. - Bob Muglia, Microsoft Senior Vice President

4 14