December 2014 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] linux-next: Tree for Dec 12 (sound/soc/codecs/rt5640)
by Randy Dunlap 12 Dec '14

12 Dec '14

On 12/11/14 23:35, Stephen Rothwell wrote: > Hi all, > > Please do not add any code destined for v3.20 to your linux-next included > trees/branches until after v3.19-rc1 is released. > > Changes since 20141211: on i386: When CONFIG_ACPI is not enabled & CONFIG_I2C is not enabled: warning: (SND_SOC_INTEL_BYTCR_RT5640_MACH && SND_SOC_INTEL_CHT_BSW_RT5672_MACH) selects SND_SST_IPC_ACPI which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && ACPI) ../sound/soc/codecs/rt5640.c:2252:1: warning: data definition has no type or storage class [enabled by default] module_i2c_driver(rt5640_i2c_driver); ^ ../sound/soc/codecs/rt5640.c:2252:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int] ../sound/soc/codecs/rt5640.c:2252:1: warning: parameter names (without types) in function declaration [enabled by default] ../sound/soc/codecs/rt5640.c:2241:26: warning: 'rt5640_i2c_driver' defined but not used [-Wunused-variable] static struct i2c_driver rt5640_i2c_driver = { ^ cc1: some warnings being treated as errors Full randconfig file is attached. Can (should) SND_SOC_INTEL_BYTCR_RT5640_MACH depend on I2C? -- ~Randy

1 0

[alsa-devel] [PATCH] ASoC: soc-dapm: Fix comparison of pointers
by Rasmus Villemoes 12 Dec '14

12 Dec '14

The idiom 'return a - b;' often used in comparison functions is wrong unless one is certain the values being compared lie in a sufficiently small range. In this case dapm_seq_compare would also return 0 if the ->dapm pointers happened to differ by a multiple of 2^32. Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> --- Notes: I don't know if the other occurences of the idiom in this function are ok; that depends on whether the values always lie in [0, 2^31-1]. sound/soc/soc-dapm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index c61cb9cedbcd..a894a7c71557 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -1255,8 +1255,10 @@ static int dapm_seq_compare(struct snd_soc_dapm_widget *a, } if (a->reg != b->reg) return a->reg - b->reg; - if (a->dapm != b->dapm) - return (unsigned long)a->dapm - (unsigned long)b->dapm; + if (a->dapm < b->dapm) + return -1; + if (a->dapm > b->dapm) + return 1; return 0; } -- 2.1.3

2 3

[alsa-devel] [PATCH] ASoC: wm8750: Make VREF a VMID instead of OUTPUT widget
by Lars-Peter Clausen 12 Dec '14

12 Dec '14

Commit 04489eeb02a4 ("ALSA: wm8750: add missing VREF output") added the previously missing VREF widget. And while adding the widget as OUTPUT widget silences the error of the missing widget it should have rather been a VMID widget. The VREF widget is only used internally as a source for the VREF input of the Out3 Mux. Selecting that input means that the path should be kept powered up at the VREF/VMID voltage, but that there is no actual audio signal. Using a VMID widget will do this, whereas using a OUTPUT widget will simply cause the path to completely power down. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/codecs/wm8750.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm8750.c b/sound/soc/codecs/wm8750.c index f6847fd..eb0a164 100644 --- a/sound/soc/codecs/wm8750.c +++ b/sound/soc/codecs/wm8750.c @@ -323,7 +323,7 @@ static const struct snd_soc_dapm_widget wm8750_dapm_widgets[] = { SND_SOC_DAPM_OUTPUT("ROUT2"), SND_SOC_DAPM_OUTPUT("MONO1"), SND_SOC_DAPM_OUTPUT("OUT3"), - SND_SOC_DAPM_OUTPUT("VREF"), + SND_SOC_DAPM_VMID("VREF"), SND_SOC_DAPM_INPUT("LINPUT1"), SND_SOC_DAPM_INPUT("LINPUT2"), -- 1.8.0

3 2

[alsa-devel] [PATCH] ASoC: samsung: Fix non-DT use of I2S controller
by Mark Brown 12 Dec '14

12 Dec '14

The changes in commit a5a56871f804e (ASoC: samsung: add support for exynos7 I2S controller) introduce a new variant_regs structure in the driver data which is now mandatory for accessing registers. Unfortunately this is only hooked up for DT platforms so non-DT platforms like my primary development platform for audio are broken by this change and crash on boot. Since the only non-DT user of these device is s3c64xx fix this by making the standard samsung-i2s device be of type I2Sv3 and add a new I2Sv4 name to the platform data section, currently using the I2Sv5 information which should be about right. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/samsung/i2s.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index e1ace5270a8b..25919e090983 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -1418,10 +1418,13 @@ static const struct samsung_i2s_dai_data samsung_dai_type_sec = { static struct platform_device_id samsung_i2s_driver_ids[] = { { .name = "samsung-i2s", - .driver_data = (kernel_ulong_t)&samsung_dai_type_pri, + .driver_data = (kernel_ulong_t)&i2sv3_dai_type, }, { .name = "samsung-i2s-sec", .driver_data = (kernel_ulong_t)&samsung_dai_type_sec, + }, { + .name = "samsung-i2sv4", + .driver_data = (kernel_ulong_t)&i2sv5_dai_type_i2s1, }, {}, }; -- 2.1.3

2 6

[alsa-devel] [BUG] dmix reports channel layouts that are not supported
by wm4 11 Dec '14

11 Dec '14

Opening a dmix device (i.e. "default" on most distros), and calling snd_pcm_query_chmaps() on it, returns some surround audio channel maps, for example 5.1. Trying to set it with snd_pcm_set_chmap() will fail with ENXIO. Only setting the stereo channel map succeeds, and I suppose dmix supports stereo only. I think this should be considered a bug. dmix probably merely passes through the channel layout of the underlying device, even though it supports stereo only - this behavior makes no sense at all. Any device should strictly report supported channel maps only. To make matters worse, if you intend to play 5.1, and dmix fails in the manner described above, then it will report "FL FR NA NA NA NA" as channel map. This would require the application to pad stereo with 4 channels of silence, which requires extra code and is generally just stupid.

1 0

Re: [alsa-devel] [Patch v2 02/11] ASoC: qcom: Add device tree binding docs
by Kenneth Westfield 11 Dec '14

11 Dec '14

On Tue, December 9, 2014 7:37 am, Mark Brown wrote: > On Mon, Dec 08, 2014 at 02:01:04PM -0800, Kenneth Westfield wrote: >> From: Kenneth Westfield <kwestfie(a)codeaurora.org> >> Add documentation to the sound directory of the >> device-tree bindings for IPQ806x audio drivers. > Please don't send multiple separate changes in a single patch. One change per patch. In an effort to reduce the number of patches, would it be possible to package the DT doc with its respective driver in one patch? Or does the DT doc need to be in a patch by itself? I've seen examples of both. Also, I will combine the partial addition of each driver to its respective Kconfig/Makefile entries. For this, I believe I need to start with an empty Kconfig/Makefile in the first patch? -- Kenneth Westfield Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[alsa-devel] [PATCH 1/4] sound: oss: Remove SoftOSS documentation
by Jarkko Nikula 11 Dec '14

11 Dec '14

SoftOSS has been removed before kernel git history but not this documentation part. Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> --- Documentation/sound/oss/README.OSS | 46 -------------------------------------- 1 file changed, 46 deletions(-) diff --git a/Documentation/sound/oss/README.OSS b/Documentation/sound/oss/README.OSS index 4be259428a1c..ad261dd602ce 100644 --- a/Documentation/sound/oss/README.OSS +++ b/Documentation/sound/oss/README.OSS @@ -516,52 +516,6 @@ Yamaha OPL3-SA1 use the standard MSS, MPU401 and OPL3 options with these chips and to activate the card using isapnptools. -4Front Technologies SoftOSS - - SoftOSS is a software based wave table emulation which works with - any 16 bit stereo sound card. Due to its nature a fast CPU is - required (P133 is minimum). Although SoftOSS does _not_ use MMX - instructions it has proven out that recent processors (which appear - to have MMX) perform significantly better with SoftOSS than earlier - ones. For example a P166MMX beats a PPro200. SoftOSS should not be used - on 486 or 386 machines. - - The amount of CPU load caused by SoftOSS can be controlled by - selecting the CONFIG_SOFTOSS_RATE and CONFIG_SOFTOSS_VOICES - parameters properly (they will be prompted by make config). It's - recommended to set CONFIG_SOFTOSS_VOICES to 32. If you have a - P166MMX or faster (PPro200 is not faster) you can set - CONFIG_SOFTOSS_RATE to 44100 (kHz). However with slower systems it - recommended to use sampling rates around 22050 or even 16000 kHz. - Selecting too high values for these parameters may hang your - system when playing MIDI files with hight degree of polyphony - (number of concurrently playing notes). It's also possible to - decrease CONFIG_SOFTOSS_VOICES. This makes it possible to use - higher sampling rates. However using fewer voices decreases - playback quality more than decreasing the sampling rate. - - SoftOSS keeps the samples loaded on the system's RAM so much RAM is - required. SoftOSS should never be used on machines with less than 16 MB - of RAM since this is potentially dangerous (you may accidentally run out - of memory which probably crashes the machine). - - SoftOSS implements the wave table API originally designed for GUS. For - this reason all applications designed for GUS should work (at least - after minor modifications). For example gmod/xgmod and playmidi -g are - known to work. - - To work SoftOSS will require GUS compatible - patch files to be installed on the system (in /dos/ultrasnd/midi). You - can use the public domain MIDIA patchset available from several ftp - sites. - - ********************************************************************* - IMPORTANT NOTICE! The original patch set distributed with the Gravis - Ultrasound card is not in public domain (even though it's available from - some FTP sites). You should contact Voice Crystal (www.voicecrystal.com) - if you like to use these patches with SoftOSS included in OSS/Free. - ********************************************************************* - PSS based cards (AD1848 + ADSP-2115 + Echo ESC614 ASIC) Analog Devices and Echo Speech have together defined a sound card architecture based on the above chips. The DSP chip is used -- 2.1.3

2 4

[alsa-devel] [PATCH v3 0/2] Disable the ThinkPad HW mute/level control when possible
by Andy Lutomirski 11 Dec '14

11 Dec '14

This series is being resurrected after several years, and it's quite different from before, so I'm restarting the version numbers :) ThinkPad volume and mute controls are a mess. For whatever reason, ThinkPads have mute buttons that send KEY_MUTE *and* control an invisible-to-ALSA mute switch. Some of them have volume controls that interact with this switch as well. This is a perennial source of problems. On most ThinkPads, if you press mute and then unmute using GUI controls, you have no sound, because userspace and ALSA state gets out of sync with the hardware switch. There's a separate "sound card" that exposes the hardware switch, but userspace code generally doesn't understand that. There are already a few _OSI(Linux) overrides to turn all the hardware buttons into regular buttons. Rather than quirking ACPI everywhere, just teach thinkpad-acpi to program the buttons for full software control and to disable hardware controls. That allows us to remove the ACPI quirks and have normal mute controls. This approach should be much simpler than adding even more kludgey ALSA integration for questionable gain. Tested on an X200s (with latching mute by default) and an X220 (with a mute light and toggle mute by default). Everything works as expected. Changes from v2: - Don't try to change the mute mode on IBM ThinkPads. - Further minor cleanups. - Try to restore the mode on module unload. Changes from v1: - Simplified the code a bit. - Improved suspend/hibernate behavior. Andy Lutomirski (2): thinkpad-acpi: Try to use full software mute control acpi: Remove _OSI(Linux) for ThinkPads drivers/acpi/blacklist.c | 54 ---------------- drivers/platform/x86/thinkpad_acpi.c | 116 ++++++++++++++++++++++++++++++++--- 2 files changed, 106 insertions(+), 64 deletions(-) -- 1.9.3

3 11

Re: [alsa-devel] Laptop Asus Z99He internal speaker not working until I enable EAPD with HDA-Analizer
by Takashi Iwai 11 Dec '14

11 Dec '14

At Thu, 11 Dec 2014 11:53:16 +0300, Dmitry V. Zimin wrote: > > This patch will be applied only to the latest kernel version or to all versions of the long-term ? The commit contains a Cc to stable kernel, so that the stable kernel maintainers will pick it up. Which one to apply depends on the stable kernel maintainer. Takashi > > > Wed, 10 Dec 2014 14:45:58 +0100 от Takashi Iwai <tiwai(a)suse.de>: > >At Wed, 10 Dec 2014 15:28:09 +0300, > >Dmitry V. Zimin wrote: > >> > >> > >> Yes, it works. Thank you so much! > > > >Good to hear, the patch is queued now. > > > > > >Takashi > > > >> > >> > >> Tue, 09 Dec 2014 20:01:36 +0100 от Takashi Iwai < tiwai(a)suse.de >: > >> >At Tue, 09 Dec 2014 18:01:44 +0300, > >> >Dmitry V. Zimin wrote: > >> >> > >> >> Hello! > >> >> > >> >> I have laptop Asus Z99He and internal speaker doesn't work until I enable EAPD through HDA-Analyzer by hand. After connect and disconnect external headphones EAPD setting reset again. > >> >> How to enable it permanently? > >> >> model=eapd, laptop-eapd or many other does not change anything. > >> >> http://www.alsa-project.org/db/?f=df83e22e0c9a047db3778f394c1aa73376dfaf39 > >> >> > >> >> Also I try old Live CD with OpenELEC. He is working properly . http://www.alsa-project.org/db/?f=a5e75412c8230afe9516f0ebf6404afb18d9040c > >> > > >> >Could you try the patch below? > >> > > >> > > >> >Takashi > >> > > >> >-- 8< -- > >> >From: Takashi Iwai < tiwai(a)suse.de > > >> >Subject: [PATCH] ALSA: hda - Add EAPD fixup for ASUS Z99He laptop > >> > > >> >The same fixup to enable EAPD is needed for ASUS Z99He with AD1986A > >> >codec like another ASUS machine. > >> > > >> >Reported-by: Dmitry V. Zimin < pfzim(a)mail.ru > > >> >Cc: < stable(a)vger.kernel.org > > >> >Signed-off-by: Takashi Iwai < tiwai(a)suse.de > > >> >--- > >> > sound/pci/hda/patch_analog.c | 1 + > >> > 1 file changed, 1 insertion(+) > >> > > >> >diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c > >> >index 06275f8807a8..28815efeab06 100644 > >> >--- a/sound/pci/hda/patch_analog.c > >> >+++ b/sound/pci/hda/patch_analog.c > >> >@@ -332,6 +332,7 @@ static const struct hda_fixup ad1986a_fixups[] = { > >> > > >> > static const struct snd_pci_quirk ad1986a_fixup_tbl[] = { > >> > SND_PCI_QUIRK(0x103c, 0x30af, "HP B2800", AD1986A_FIXUP_LAPTOP_IMIC), > >> >+ SND_PCI_QUIRK(0x1043, 0x1443, "ASUS Z99He", AD1986A_FIXUP_EAPD), > >> > SND_PCI_QUIRK(0x1043, 0x1447, "ASUS A8JN", AD1986A_FIXUP_EAPD), > >> > SND_PCI_QUIRK_MASK(0x1043, 0xff00, 0x8100, "ASUS P5", AD1986A_FIXUP_3STACK), > >> > SND_PCI_QUIRK_MASK(0x1043, 0xff00, 0x8200, "ASUS M2", AD1986A_FIXUP_3STACK), > >> >-- > >> >2.2.0 > >> > > >> > >> > >> > >> [2 <text/html; utf-8 (base64)>] > >> > > >

1 0

[alsa-devel] About SNDRV_PCM_HW_PARAM_TICK_TIME
by Lars-Peter Clausen 10 Dec '14

10 Dec '14

Hi, I was trying to figure out what exactly SNDRV_PCM_HW_PARAM_TICK_TIME does, but couldn't find too much. Is it safe to say that nowadays this is unused and deprecated and the only reason it is kept around is for ABI reasons? Thanks, - Lars

2 1