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

[alsa-devel] [PATCH v2 7/9] ALSA: usb-audio: remove is_playback from implicit feedback quirks
by Eldad Zack 03 Aug '13

03 Aug '13

An implicit feedback endpoint can only be a capture source. The consumer (sink) of the implicit feedback endpoint is therefore limited to playback EPs. Check if the target endpoint is a playback first and remove redundant checks. Signed-off-by: Eldad Zack <eldad(a)fogrefinery.com> --- sound/usb/pcm.c | 40 +++++++++++++++++++--------------------- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index bb2e0f5..af30e08 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -334,41 +334,39 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, { struct usb_host_interface *alts; struct usb_interface *iface; - int is_playback = subs->direction == SNDRV_PCM_STREAM_PLAYBACK; int implicit_fb = 0; unsigned int ep; + /* Implicit feedback sync EPs consumers are always playback EPs */ + if (subs->direction != SNDRV_PCM_STREAM_PLAYBACK) + return 0; + switch (subs->stream->chip->usb_id) { case USB_ID(0x0763, 0x2030): /* M-Audio Fast Track C400 */ case USB_ID(0x0763, 0x2031): /* M-Audio Fast Track C600 */ - if (is_playback) { - implicit_fb = 1; - ep = 0x81; - iface = usb_ifnum_to_if(dev, 3); + implicit_fb = 1; + ep = 0x81; + iface = usb_ifnum_to_if(dev, 3); - if (!iface || iface->num_altsetting == 0) - return -EINVAL; + if (!iface || iface->num_altsetting == 0) + return -EINVAL; - alts = &iface->altsetting[1]; - goto add_sync_ep; - } + alts = &iface->altsetting[1]; + goto add_sync_ep; break; case USB_ID(0x0763, 0x2080): /* M-Audio FastTrack Ultra */ case USB_ID(0x0763, 0x2081): - if (is_playback) { - implicit_fb = 1; - ep = 0x81; - iface = usb_ifnum_to_if(dev, 2); + implicit_fb = 1; + ep = 0x81; + iface = usb_ifnum_to_if(dev, 2); - if (!iface || iface->num_altsetting == 0) - return -EINVAL; + if (!iface || iface->num_altsetting == 0) + return -EINVAL; - alts = &iface->altsetting[1]; - goto add_sync_ep; - } + alts = &iface->altsetting[1]; + goto add_sync_ep; } - if (is_playback && - attr == USB_ENDPOINT_SYNC_ASYNC && + if (attr == USB_ENDPOINT_SYNC_ASYNC && altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && altsd->bInterfaceProtocol == 2 && altsd->bNumEndpoints == 1 && -- 1.8.1.5

1 3

[alsa-devel] pcm1792a codec driver
by Michael Trimarchi 03 Aug '13

03 Aug '13

Hi Mark Yesterday I have done the pcm1792a codec driver and tested connected to the pandaboard es. The driver is working using spi/i2s connection with the codec and support l/r attenuation and digital mute. Other fmt are supported but not tested. Anyway it's a base of the complete driver. Hope that I can take again the hardware for feature release. Can I submit this initial support patch of it? Michael

1 0

[alsa-devel] end of playback ... design question
by Knut Petersen 02 Aug '13

02 Aug '13

Hi everybody! Although I looked at quite a bit of source code and documentation I have to admit that I am confused about one question: How should alsa playback be stopped in a way that _guarantees_ that no artifacts remaining in the drivers ringbuffer are played back again? Let´s assume we play stereo 16bit audio data using the rme96 driver, period size set to 0x800 frames. At the end of the penultimate frame playing will not be stopped even if there is only one frame of audio data remaining. Obviously that means 0x7ff frames of already played data is played again after that one valid frame, plus possibly a few that are played during the short time from interrupt request to the real stop of the playback hardware (about 5 frames on an old Pentium-M 1.2GHz). Now that could be fixed in different ways: A: Always ensure that there is a bit of silence (at least hardware buffer size plus a few frames) at the end of all audio data. Easy for the user , but only a workaround. B: At the rme96 driver level that condition can be detected and the relevant part of the buffer can be filled with zeros. I did that in an experimental change. It does work, but it´s definitely only a hack as it fixes the problem for only one device. C: The application playing audio data could pad all audio data to the period size with zeros. That would prevent playback of that max 0x7ff frames of garbage, but the few samples that are played during the time from interrupt request to the execution of the stop trigger do escape D: Don´t try to drain the buffer but pad with zeros and set a stop threshold. Workaround for applications should also work with older kernels. E: The alsa core could detect that condition and solve it equivalent to solution D I think that´s the proper solution. Did I miss something or do you agree? cu, Knut

3 2

Re: [alsa-devel] HBR audio with intel HDA
by Anssi Hannula 02 Aug '13

02 Aug '13

02.08.2013 19:14, Ashecrow kirjoitti: > > Le 2 août 2013 à 15:42, Anssi Hannula a écrit : > >> 02.08.2013 16:11, Ashecrow kirjoitti: >>> Hi Anssi, >>> Thanks for your answer >>> >>> Test on kernel 3.8 + non-pcm bit in AES0: >>> aplay -D hdmi:CARD=PCH,DEV=0,AES0=0x06 -c8 -fs16_le -r192000 dts.spdif >>> => same result: no signal >> >> Hmh, OK. >> >>> With kernel upgrade to 3.9: same result >>> >>> >>> Note that I have tested with alsa* 1.025 and intel-hda driver included in kernel >>> >>> Do you have any other idea? >> >> You could try DEV=1 instead of DEV=0 (according to your log DEV=0 is >> correct, though), and truehd (thd.spdif from ffmpeg samples). >> >> If neither of those work, could you provide another alsa-info while >> playing back using AES0=0x06 (with alsa debug enabled again)? >> > I have already tried DEV=1 but it does the same. Moreover, let me note that I play DTS and dolby fine with DEV=0 in xbmc. So I guess it is the right device. OK. Note that in some cases you can hear stereo audio or AC-3/DTS even when using wrong DEV=x (but HBR or multichannel audio would not work). > see attached alsa-info.txt_dev0_kernel-3.8_aes0_dts-hd which is result of playing dts-hd spdif encapsulated with kernel 3.8 in debug mode and AES0=0x06 through command bellow > > aplay -D hdmi:CARD=PCH,DEV=0,AES0=0x06 -c8 -fs16_le -r192000 dts.spdif > > see attached alsa-info.txt_dev0_kernel-3.8_aes0_true-hd which is result of playing dts-hd spdif encapsulated with kernel 3.8 in debug mode and AES0=0x06 through command bellow > > aplay -D hdmi:CARD=PCH,DEV=0,AES0=0x06 -c8 -fs16_le -r192000 thd.spdif > Looks like your kernel is definitely too old to have working HBR on Intel (the "ASP channel x => slot y" messages should have x=y), so you'll need 3.9+. Unfortunately I don't see anything else wrong (and HBR+intel works for me), so I don't have anything else to suggest at the moment. Sorry. > Thanks for your help > >> >> >>> Thanks >>> >>> >>> Le 1 août 2013 à 18:37, Anssi Hannula a écrit : >>> >>>> 01.08.2013 19:29, ashecrow42(a)free.fr kirjoitti: >>>>> Hi there, >>>> >>>> Hi! >>>> >>>>> I have troubles using HBR audio (DTS-HD and Dolby TrueHD). With every >>>>> test, I get no signal in the AV receiver. I have tested using a dts-hd >>>>> encapsulated in spdif sample file (found there >>>>> http://samples.mplayerhq.hu/hdmi/) and commands bellow >>>>> >>>>> - aplay -D hdmi devices >>>>> - aplay -D hw devices >>>>> - aplay -D plughw devices >>>> >>>> You need to set the non-pcm bit in AES0. Use e.g. "-D hdmi:AES0=0x06". >>>> >>>>> Note that I use ubuntu raring with 3.8 kernel that includes Xingchao's >>>>> HBR kernel patches. >>>>> >>>>> >>>>> A. Configurations I have tested: >>>>> >>>>> >>>>> - hda driver upgrade (alsa devel ubuntu team daily builds) >>>>> >>>>> - upgrade alsa-lib & alsa-utils (alsa-testing launchpad) >>>>> >>>>> - kernel upgrade to 3.9 >>>> >>>> IIRC 3.9 (or newer) may indeed be needed since you have both hdmi and spdif. >>>> >>>>> - snd_hda_codec_realtek module backlist (to try to disable SPDIF) >>>>> /etc/modprobe.d/blacklist.conf >>>>> >>>>> - snd_hda_codec_realtek index = -2 in /etc/modprobe.d/alsa-base.conf >>>>> >>>>> - fresh new ubuntu raring install with no modifications at all: still >>>>> no signal >>>>> >>>>> B. Info: >>>>> >>>>> cat /proc/asound/card0/codec* | grep Codec >>>>> Codec: Realtek ALC892 >>>>> Codec: Intel CougarPoint HDMI >>>>> >>>>> I use zotac ZBOX ID82 (intel HM65 chipset with hdmi and spdif) >>>>> >>>>> with alsa debug and alsa debug verbose enabled in kernel I got the >>>>> alsa-info.txt attached file produced on raring with no modification >>>>> while playing dts-hd sample file with command: >>>>> >>>>> >>>>> aplay -D hdmi:CARD=PCH,DEV=0 -c8 -fs16_le -r192000 dts.spdif >>>> >>>> As per above you need to use >>>> aplay -D hdmi:CARD=PCH,DEV=0,AES0=0x06 -c8 -fs16_le -r192000 dts.spdif >>>> >>>>> >>>>> C. I add that: >>>>> >>>>> - In every test I have non HD audio protocols (DTS and dolby) working >>>>> well in the same configuration >>>>> >>>>> - I have tried with windows just to see if my hardware is broken and I >>>>> get DTS-HD audio with no problem >>>>> >>>>> - Takashi, I've read your HD-Audio.txt file and as far as I see, I have >>>>> no known error message in kernel log >>>>> >>>>> >>>>> => I and Wingchao Wang have conclued that it is driver or codec >>>>> related. Can you help me please? >>>>> >>>>> Thanks a lot >>>>> PS: sorry if you receive this email twice, I have sent it again as I >>>>> was not member of the list the first time. >>>> >>>> >>>> -- >>>> Anssi Hannula >>> >> >> >> -- >> Anssi Hannula > -- Anssi Hannula

2 1

[alsa-devel] [PATCH] ASoC: dapm: Fix empty list check in dapm_new_mux()
by Lars-Peter Clausen 02 Aug '13

02 Aug '13

list_first_entry() will always return a valid pointer, even if the list is empty. So the check whether path is NULL will always be false. So we end up calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points right in the middle of the widget struct and by trying to modify the path the widgets memory will become corrupted. Fix this by using list_emtpy() to check if the widget doesn't have any paths. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- This is the real fix for the rt5640 crash. --- sound/soc/soc-dapm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 5f64c16..196cea7 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -747,13 +747,14 @@ static int dapm_new_mux(struct snd_soc_dapm_widget *w) return -EINVAL; } - path = list_first_entry(&w->sources, struct snd_soc_dapm_path, - list_sink); - if (!path) { + if (list_empty(&w->sources)) { dev_err(dapm->dev, "ASoC: mux %s has no paths\n", w->name); return -EINVAL; } + path = list_first_entry(&w->sources, struct snd_soc_dapm_path, + list_sink); + ret = dapm_create_or_share_mixmux_kcontrol(w, 0, path); if (ret < 0) return ret; -- 1.8.0

3 4

[alsa-devel] HBR audio with intel HDA
by ashecrow42＠free.fr 02 Aug '13

02 Aug '13

Hi there, I have troubles using HBR audio (DTS-HD and Dolby TrueHD). With every test, I get no signal in the AV receiver. I have tested using a dts-hd encapsulated in spdif sample file (found there http://samples.mplayerhq.hu/hdmi/) and commands bellow - aplay -D hdmi devices - aplay -D hw devices - aplay -D plughw devices Note that I use ubuntu raring with 3.8 kernel that includes Xingchao's HBR kernel patches. A. Configurations I have tested: - hda driver upgrade (alsa devel ubuntu team daily builds) - upgrade alsa-lib & alsa-utils (alsa-testing launchpad) - kernel upgrade to 3.9 - snd_hda_codec_realtek module backlist (to try to disable SPDIF) /etc/modprobe.d/blacklist.conf - snd_hda_codec_realtek index = -2 in /etc/modprobe.d/alsa-base.conf - fresh new ubuntu raring install with no modifications at all: still no signal B. Info: cat /proc/asound/card0/codec* | grep Codec Codec: Realtek ALC892 Codec: Intel CougarPoint HDMI I use zotac ZBOX ID82 (intel HM65 chipset with hdmi and spdif) with alsa debug and alsa debug verbose enabled in kernel I got the alsa-info.txt attached file produced on raring with no modification while playing dts-hd sample file with command: aplay -D hdmi:CARD=PCH,DEV=0 -c8 -fs16_le -r192000 dts.spdif C. I add that: - In every test I have non HD audio protocols (DTS and dolby) working well in the same configuration - I have tried with windows just to see if my hardware is broken and I get DTS-HD audio with no problem - Takashi, I've read your HD-Audio.txt file and as far as I see, I have no known error message in kernel log => I and Wingchao Wang have conclued that it is driver or codec related. Can you help me please? Thanks a lot PS: sorry if you receive this email twice, I have sent it again as I was not member of the list the first time.

3 3

[alsa-devel] [PATCH 01/10] ASoC: dapm: Move snd_soc_dapm_update from dapm context to card
by Lars-Peter Clausen 02 Aug '13

02 Aug '13

The update field of a DAPM context is only assigned while the card's dapm_mutex is locked, the field is also cleared again while the mutex is stil locked. So there will only ever be one DAPM context at a time with a non-NULL update field. So it is safe to move the update field from the DAPM context struct to the card struct. Doing so will allow further cleanups in this area. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- include/sound/soc-dapm.h | 2 -- include/sound/soc.h | 1 + sound/soc/soc-dapm.c | 22 +++++++++++----------- 3 files changed, 12 insertions(+), 13 deletions(-) diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index e77c6f5..3397292 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -575,8 +575,6 @@ struct snd_soc_dapm_context { struct delayed_work delayed_work; unsigned int idle_bias_off:1; /* Use BIAS_OFF instead of STANDBY */ - struct snd_soc_dapm_update *update; - void (*seq_notifier)(struct snd_soc_dapm_context *, enum snd_soc_dapm_type, int); diff --git a/include/sound/soc.h b/include/sound/soc.h index 6eabee7..b1e1f96 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1042,6 +1042,7 @@ struct snd_soc_card { /* Generic DAPM context for the card */ struct snd_soc_dapm_context dapm; struct snd_soc_dapm_stats dapm_stats; + struct snd_soc_dapm_update *update; #ifdef CONFIG_DEBUG_FS struct dentry *debugfs_card_root; diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 366daef..7449e27 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -1425,7 +1425,7 @@ static void dapm_seq_run(struct snd_soc_dapm_context *dapm, static void dapm_widget_update(struct snd_soc_dapm_context *dapm) { - struct snd_soc_dapm_update *update = dapm->update; + struct snd_soc_dapm_update *update = dapm->card->update; struct snd_soc_dapm_widget_list *wlist; struct snd_soc_dapm_widget *w = NULL; unsigned int wi; @@ -1959,9 +1959,9 @@ int snd_soc_dapm_mux_update_power(struct snd_soc_dapm_context *dapm, int ret; mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME); - dapm->update = update; + card->update = update; ret = soc_dapm_mux_update_power(dapm, kcontrol, mux, e); - dapm->update = NULL; + card->update = NULL; mutex_unlock(&card->dapm_mutex); if (ret > 0) soc_dpcm_runtime_update(card); @@ -2002,9 +2002,9 @@ int snd_soc_dapm_mixer_update_power(struct snd_soc_dapm_context *dapm, int ret; mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME); - dapm->update = update; + card->update = update; ret = soc_dapm_mixer_update_power(dapm, kcontrol, connect); - dapm->update = NULL; + card->update = NULL; mutex_unlock(&card->dapm_mutex); if (ret > 0) soc_dpcm_runtime_update(card); @@ -2693,11 +2693,11 @@ int snd_soc_dapm_put_volsw(struct snd_kcontrol *kcontrol, update.mask = mask; update.val = val; - widget->dapm->update = &update; + card->update = &update; soc_dapm_mixer_update_power(widget->dapm, kcontrol, connect); - widget->dapm->update = NULL; + card->update = NULL; } mutex_unlock(&card->dapm_mutex); @@ -2775,11 +2775,11 @@ int snd_soc_dapm_put_enum_double(struct snd_kcontrol *kcontrol, update.reg = e->reg; update.mask = mask; update.val = val; - widget->dapm->update = &update; + card->update = &update; soc_dapm_mux_update_power(widget->dapm, kcontrol, mux, e); - widget->dapm->update = NULL; + card->update = NULL; } mutex_unlock(&card->dapm_mutex); @@ -2928,11 +2928,11 @@ int snd_soc_dapm_put_value_enum_double(struct snd_kcontrol *kcontrol, update.reg = e->reg; update.mask = mask; update.val = val; - widget->dapm->update = &update; + card->update = &update; soc_dapm_mux_update_power(widget->dapm, kcontrol, mux, e); - widget->dapm->update = NULL; + card->update = NULL; } mutex_unlock(&card->dapm_mutex); -- 1.8.0

2 15

[alsa-devel] [PATCH] ALSA: hda - Fix missing fixup for Mac Mini with STAC9221
by Takashi Iwai 02 Aug '13

02 Aug '13

A fixup for Apple Mac Mini was lost during the adaption to the generic parser because the fallback for the generic ID 8384:7680 was dropped, and it resulted in the silence output (and maybe other problems). Unfortunately, just adding the missing subsystem ID wasn't enough, in this case. The subsystem ID of this machine is 0000:0100 (what Apple thought...?), and since snd_hda_pick_fixup() doesn't take the vendor id zero into account, the driver ignored this entry. Now it's fixed to regard the vendor id zero as a valid value. Reported-and-tested-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: <stable(a)vger.kernel.org> [v3.9+] Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_auto_parser.c | 2 +- sound/pci/hda/patch_sigmatel.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_auto_parser.c b/sound/pci/hda/hda_auto_parser.c index 7c11d46..48a9d00 100644 --- a/sound/pci/hda/hda_auto_parser.c +++ b/sound/pci/hda/hda_auto_parser.c @@ -860,7 +860,7 @@ void snd_hda_pick_fixup(struct hda_codec *codec, } } if (id < 0 && quirk) { - for (q = quirk; q->subvendor; q++) { + for (q = quirk; q->subvendor || q->subdevice; q++) { unsigned int vendorid = q->subdevice | (q->subvendor << 16); unsigned int mask = 0xffff0000 | q->subdevice_mask; diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 92b9b43..6d1924c 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -2819,6 +2819,7 @@ static const struct hda_pintbl ecs202_pin_configs[] = { /* codec SSIDs for Intel Mac sharing the same PCI SSID 8384:7680 */ static const struct snd_pci_quirk stac922x_intel_mac_fixup_tbl[] = { + SND_PCI_QUIRK(0x0000, 0x0100, "Mac Mini", STAC_INTEL_MAC_V3), SND_PCI_QUIRK(0x106b, 0x0800, "Mac", STAC_INTEL_MAC_V1), SND_PCI_QUIRK(0x106b, 0x0600, "Mac", STAC_INTEL_MAC_V2), SND_PCI_QUIRK(0x106b, 0x0700, "Mac", STAC_INTEL_MAC_V2), -- 1.8.3.1

1 0

[alsa-devel] [PATCH 1/2] ASoC: dapm: Check return value of snd_soc_cnew()
by Lars-Peter Clausen 01 Aug '13

01 Aug '13

snd_soc_cnew() can return NULL, so we should check the result before trying to use it. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/soc-dapm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index d74c356..b4fae87 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -671,8 +671,10 @@ static int dapm_create_or_share_mixmux_kcontrol(struct snd_soc_dapm_widget *w, kcontrol = snd_soc_cnew(&w->kcontrol_news[kci], NULL, name, prefix); - kcontrol->private_free = dapm_kcontrol_free; kfree(long_name); + if (!kcontrol) + return -ENOMEM; + kcontrol->private_free = dapm_kcontrol_free; ret = dapm_kcontrol_data_alloc(w, kcontrol); if (ret) { -- 1.8.0

2 4

[alsa-devel] [PATCH] ASoC: rt5640: remove unused mux
by bardliao＠realtek.com 01 Aug '13

01 Aug '13

From: Bard Liao <bardliao(a)realtek.com> Remove unused "INL Mux" and "INR Mux". Signed-off-by: Bard Liao <bardliao(a)realtek.com> --- I meet a kernel panic issue if I don't remove the unused widget and modify something in rt5640_dapm_widgets[] and/or rt5640_dapm_routes[]. The message is "Unable to handle kernel paging request at virtual address 6b6b6bd3". PC is at dapm_clear_walk_output+0x18/0x7c LR is at dapm_clear_walk_output+0x18/0x7c If I remove those unused widget, ie. not appear in rt5640_dapm_routes[], everything is fine. So I think they should be removed. --- sound/soc/codecs/rt5640.c | 26 -------------------------- 1 file changed, 26 deletions(-) diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index ce585e3..4db7314 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -737,29 +737,6 @@ static const struct snd_kcontrol_new rt5640_mono_mix[] = { RT5640_M_BST1_MM_SFT, 1, 1), }; -/* INL/R source */ -static const char * const rt5640_inl_src[] = { - "IN2P", "MONOP" -}; - -static const SOC_ENUM_SINGLE_DECL( - rt5640_inl_enum, RT5640_INL_INR_VOL, - RT5640_INL_SEL_SFT, rt5640_inl_src); - -static const struct snd_kcontrol_new rt5640_inl_mux = - SOC_DAPM_ENUM("INL source", rt5640_inl_enum); - -static const char * const rt5640_inr_src[] = { - "IN2N", "MONON" -}; - -static const SOC_ENUM_SINGLE_DECL( - rt5640_inr_enum, RT5640_INL_INR_VOL, - RT5640_INR_SEL_SFT, rt5640_inr_src); - -static const struct snd_kcontrol_new rt5640_inr_mux = - SOC_DAPM_ENUM("INR source", rt5640_inr_enum); - /* Stereo ADC source */ static const char * const rt5640_stereo_adc1_src[] = { "DIG MIX", "ADC" @@ -1005,9 +982,6 @@ static const struct snd_soc_dapm_widget rt5640_dapm_widgets[] = { RT5640_PWR_IN_L_BIT, 0, NULL, 0), SND_SOC_DAPM_PGA("INR VOL", RT5640_PWR_VOL, RT5640_PWR_IN_R_BIT, 0, NULL, 0), - /* IN Mux */ - SND_SOC_DAPM_MUX("INL Mux", SND_SOC_NOPM, 0, 0, &rt5640_inl_mux), - SND_SOC_DAPM_MUX("INR Mux", SND_SOC_NOPM, 0, 0, &rt5640_inr_mux), /* REC Mixer */ SND_SOC_DAPM_MIXER("RECMIXL", RT5640_PWR_MIXER, RT5640_PWR_RM_L_BIT, 0, rt5640_rec_l_mix, ARRAY_SIZE(rt5640_rec_l_mix)), -- 1.8.1.1.439.g50a6b54

4 3