March 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 0/3] ARM: shmobile: armadillo: fixup CPU settings
by Kuninori Morimoto 10 Apr '15

10 Apr '15

Hi Mark, Lars Cc Simon These patches had been posted in ALSA/SH-ARM ML in http://thread.gmane.org/gmane.linux.ports.sh.devel/43079 by Lars. But, he doesn't have armadillo board, and I commented about FSI driver, and no one update these, these patches were marooned. Original 2/3 patch changed behavior for clock inversion on FSI driver. FSI + wm8978 on armadillo800eva worked without any issues, but, I don't know how much effect it has for other board (many board are using FSI). We used this inversion flags on each board for historical reasons, but, almost all these were not needed (except some picky board) on FSI. Maybe Lars's 2/3 patch is correct, but, it is difficult to check/confirm for all boards. And unfortunately, Renesas don't use FSI anymore. So, I think keeping current FSI driver as-is is more safety for old boards. I tested these patches on latest Mark's branch Lars-Peter Clausen (3): ARM: shmobile: armadillo800eva: Properly specify HDMI audio link format ARM: shmobile: armadillo800eva: fix clock inversion ASoC: simple-card: Remove support for setting differing DAI formats arch/arm/mach-shmobile/board-armadillo800eva.c | 3 +-- include/sound/simple_card.h | 1 - sound/soc/generic/simple-card.c | 30 ++++++++---------------------- 3 files changed, 9 insertions(+), 25 deletions(-)

4 10

Re: [alsa-devel] [PATCH 0/4] More aggressive PM for HD-audio
by Takashi Iwai 09 Apr '15

09 Apr '15

At Thu, 26 Mar 2015 20:24:43 +0800, Hui Wang wrote: > > [1 <text/plain; utf-8 (8bit)>] > On 03/21/2015 02:38 PM, Hui Wang wrote: > > On 03/21/2015 12:20 AM, David Henningsson wrote: > >> > >> On 2015-03-18 09:50, Takashi Iwai wrote: > >>> Hi, > >>> > >>> here is a patchset for supporting more aggressive PM for HD-audio. > >>> This allows to change the power state of each widget more dynamically > >>> with jack and stream states. It's activated only when the codec > >>> driver (or via sysfs or f/w patch) sets codec->power_mgmt flag. > >>> > >>> In theory, this should work for the recent Realtek codecs, but > >>> currently I have no machine for test. > >>> > >>> David, could you or your team check whether this works for ALC282 or > >>> such? Just add like: > >>> > >>> --- a/sound/pci/hda/patch_realtek.c > >>> +++ b/sound/pci/hda/patch_realtek.c > >>> @@ -5415,6 +5415,7 @@ static int patch_alc269(struct hda_codec *codec) > >>> > >>> spec = codec->spec; > >>> spec->gen.shared_mic_vref_pin = 0x18; > >>> + codec->power_mgmt = 1; > >>> > >>> snd_hda_pick_fixup(codec, alc269_fixup_models, > >>> alc269_fixup_tbl, alc269_fixups); > >>> > >>> > >>> The patchset is for for-next branch of sound git tree, but they might > >>> be applicable to 4.0-rc (or even older), too. The current patches are > >>> found in topic/hda-power branch. > >> > >> So I hoped to be able to look at this today, but it turns out the > >> machine I was thinking of using for testing has an ALC262 codec, > >> which hardly counts as "new". > >> > >> Hui, is this something you feel like taking on? Otherwise I'll try to > >> talk to someone in Taipei. > >> > > OK， I will look for the machine to do the test next week. > > > > Regards, > > Hui. > > > Sorry for late response, today is my first day in the office back from > vacation, I checked all machines in the Beijing office, none of them has > the ALC282 codec, I will continue to look for the machine from other office. > > And I did the test on the machines with the alc283, alc255, alc292 and > alc269, the testing result were same, there were no sound output from > internal speaker or headphone, and the internal mic or external mic > can't record any sound. The test steps as below: > > 1. power_save_node = 0 > checkout the hda-power branch, build the kernel based on this branch. > Install the kernel to the above machines and boot into the desktop > test internal speaker and internal mic, works very well, plug a headset, > test headphone and external mic, works very well. > run pm_suspend, wait 5 seconds, wakeup the system, redo the above test, > everything works very well. OK, this is expected. The patch shouldn't touch this case. > 2. power_save_node = 1 > enable the power_save_node as below: > @@ -5426,6 +5426,8 @@ static int patch_alc269(struct hda_codec *codec) > > alc_auto_parse_customize_define(codec); > > + codec->power_save_node = 1; > + > if (has_cdefine_beep(codec)) > spec->gen.beep_nid = 0x01; > rebuild the kernel, install the kernel to the above machines and boot > into the desktop > test internal speaker and internal mic, we can play sound to internal > speaker without any errors, but I can't hear any sound from the speaker; > I can use the internal mic to record without errors, but recorded file > did not include any sound pcm (maybe all 0x00 or 0xff) > I plug a headset into the headset jack, the detection works very well, > but I can't hear sound from headphone when play a sound, and I can't use > headset mic to record any sound as well. > > > And I attached 2 alsa-info.txt, one is the power_save_node=0, the other > is the power_save_node=1 Thanks. The alsa-info.sh outputs show no difference but the power state, so the widget attributes seem kept with the power state change, as it seems. Could you give alsa-info.sh output *during* playing with power_save_node=1? Takashi

4 8

[alsa-devel] 1st draft: ALSA Json Gateway and HTML5 UI
by Fulup Ar Foll 07 Apr '15

07 Apr '15

Hi, I would need some help to finish a json version of amixer. Porting cget is done, but for cset I have an issue with "snd_hctl_find_elem (handle, id)". I'm not sure what's the right method to pass it. I've tried every options I could imagine. But if it works on Mint/32bit, it miserably fail on OpenSuse/64. Furthermore amixer.c as this strange comment /* FIXME: Remove it when hctl find works ok !!! */ and they do not use snd_hctl_find_elem. I posted a small C code to highlight the issue at [1]https://gist.github.com/fulup-bzh/891e5627be325150337f My question is simple, did I miss something ? should I move to lower level API ? Note: While the painting for my json-gateway is not dry, I nevertheless pushed a initial running version with cget at [2]https://github.com/fulup-bzh/AlsaJsonGateway I also have a small HTML5/UI at [3]http://breizhme.net/alsajson/mixers/ajg#/scarlett?card=2 While UI code is very dependant on each soundcard [in my case Scarlett/Focurite] the Json-Gateway is 100% independent of the board. If anything one have an idea, please let me know. Fulup References 1. https://gist.github.com/fulup-bzh/891e5627be325150337f 2. https://github.com/fulup-bzh/AlsaJsonGateway 3. http://breizhme.net/alsajson/mixers/ajg#/scarlett?card=2

2 1

[alsa-devel] [PATCH][ASoC]Add ability to remove rate constraints from generic ASoC AC'97 CODEC driver
by Maciej S. Szmigiero 07 Apr '15

07 Apr '15

Add ability to remove rate constraints from generic ASoC AC'97 CODEC driver via passed platform data, make it selectable in config. This way this driver can be used for platforms which don't need specialized AC'97 CODEC drivers while at the same avoiding code duplication from implementing equivalent functionality in a controller driver. There is no change in behavior when no platform data is passed. Signed-off-by: Maciej Szmigiero <mail(a)maciej.szmigiero.name> diff --git a/include/sound/soc-ac97.h b/include/sound/soc-ac97.h new file mode 100644 index 0000000..ceb4e2f --- /dev/null +++ b/include/sound/soc-ac97.h @@ -0,0 +1,17 @@ +/* + * Platform data for generic ASoC AC97 CODEC driver. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#ifndef __LINUX_SND__SOC_AC97_H +#define __LINUX_SND__SOC_AC97_H + +struct snd_soc_ac97_codec_platform_data { + bool playback_rate_constrained; + bool capture_rate_constrained; +}; + +#endif /* __LINUX_SND__SOC_AC97_H */ diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 0bddd92..92d6d39 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -16,7 +16,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_88PM860X if MFD_88PM860X select SND_SOC_L3 select SND_SOC_AB8500_CODEC if ABX500_CORE - select SND_SOC_AC97_CODEC if SND_SOC_AC97_BUS + select SND_SOC_AC97_CODEC select SND_SOC_AD1836 if SPI_MASTER select SND_SOC_AD193X_SPI if SPI_MASTER select SND_SOC_AD193X_I2C if I2C @@ -210,8 +210,9 @@ config SND_SOC_AB8500_CODEC tristate config SND_SOC_AC97_CODEC - tristate + tristate "Build generic ASoC AC97 CODEC driver" select SND_AC97_CODEC + select SND_SOC_AC97_BUS config SND_SOC_AD1836 tristate diff --git a/sound/soc/codecs/ac97.c b/sound/soc/codecs/ac97.c index d0ac723..c3fb845 100644 --- a/sound/soc/codecs/ac97.c +++ b/sound/soc/codecs/ac97.c @@ -20,9 +20,16 @@ #include <sound/core.h> #include <sound/pcm.h> #include <sound/ac97_codec.h> +#include <sound/soc-ac97.h> #include <sound/initval.h> #include <sound/soc.h> +struct ac97_private { + struct snd_ac97 *ac97; + bool playback_rate_constrained; + bool capture_rate_constrained; +}; + static const struct snd_soc_dapm_widget ac97_widgets[] = { SND_SOC_DAPM_INPUT("RX"), SND_SOC_DAPM_OUTPUT("TX"), @@ -33,22 +40,53 @@ static const struct snd_soc_dapm_route ac97_routes[] = { { "TX", NULL, "AC97 Playback" }, }; +static const unsigned int default_rates[] = { + 8000, 11025, 22050, 44100, 48000 +}; + +static const struct snd_pcm_hw_constraint_list default_rate_constraints = { + .count = ARRAY_SIZE(default_rates), + .list = default_rates, +}; + +static int ac97_startup(struct snd_pcm_substream *substream, + struct snd_soc_dai *dai) +{ + struct snd_soc_codec *codec = dai->codec; + struct ac97_private *ac97 = snd_soc_codec_get_drvdata(codec); + bool constrained; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + constrained = ac97->playback_rate_constrained; + else + constrained = ac97->capture_rate_constrained; + + if (!constrained) + return 0; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + snd_pcm_hw_constraint_list(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_RATE, &default_rate_constraints); + else + snd_pcm_hw_constraint_list(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_RATE, &default_rate_constraints); + + return 0; +} + static int ac97_prepare(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { struct snd_soc_codec *codec = dai->codec; - struct snd_ac97 *ac97 = snd_soc_codec_get_drvdata(codec); + struct ac97_private *ac97 = snd_soc_codec_get_drvdata(codec); int reg = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) ? AC97_PCM_FRONT_DAC_RATE : AC97_PCM_LR_ADC_RATE; - return snd_ac97_set_rate(ac97, reg, substream->runtime->rate); + return snd_ac97_set_rate(ac97->ac97, reg, substream->runtime->rate); } -#define STD_AC97_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |\ - SNDRV_PCM_RATE_22050 | SNDRV_PCM_RATE_44100 |\ - SNDRV_PCM_RATE_48000) - static const struct snd_soc_dai_ops ac97_dai_ops = { + .startup = ac97_startup, .prepare = ac97_prepare, }; @@ -58,20 +96,21 @@ static struct snd_soc_dai_driver ac97_dai = { .stream_name = "AC97 Playback", .channels_min = 1, .channels_max = 2, - .rates = STD_AC97_RATES, + .rates = SNDRV_PCM_RATE_KNOT, .formats = SND_SOC_STD_AC97_FMTS,}, .capture = { .stream_name = "AC97 Capture", .channels_min = 1, .channels_max = 2, - .rates = STD_AC97_RATES, + .rates = SNDRV_PCM_RATE_KNOT, .formats = SND_SOC_STD_AC97_FMTS,}, .ops = &ac97_dai_ops, }; static int ac97_soc_probe(struct snd_soc_codec *codec) { - struct snd_ac97 *ac97; + struct ac97_private *ac97 = snd_soc_codec_get_drvdata(codec); + struct snd_ac97_bus *ac97_bus; struct snd_ac97_template ac97_template; int ret; @@ -83,31 +122,28 @@ static int ac97_soc_probe(struct snd_soc_codec *codec) return ret; memset(&ac97_template, 0, sizeof(struct snd_ac97_template)); - ret = snd_ac97_mixer(ac97_bus, &ac97_template, &ac97); + ret = snd_ac97_mixer(ac97_bus, &ac97_template, &ac97->ac97); if (ret < 0) return ret; - snd_soc_codec_set_drvdata(codec, ac97); - return 0; } #ifdef CONFIG_PM static int ac97_soc_suspend(struct snd_soc_codec *codec) { - struct snd_ac97 *ac97 = snd_soc_codec_get_drvdata(codec); + struct ac97_private *ac97 = snd_soc_codec_get_drvdata(codec); - snd_ac97_suspend(ac97); + snd_ac97_suspend(ac97->ac97); return 0; } static int ac97_soc_resume(struct snd_soc_codec *codec) { + struct ac97_private *ac97 = snd_soc_codec_get_drvdata(codec); - struct snd_ac97 *ac97 = snd_soc_codec_get_drvdata(codec); - - snd_ac97_resume(ac97); + snd_ac97_resume(ac97->ac97); return 0; } @@ -129,6 +165,27 @@ static struct snd_soc_codec_driver soc_codec_dev_ac97 = { static int ac97_probe(struct platform_device *pdev) { + struct ac97_private *ac97 = + devm_kzalloc(&pdev->dev, sizeof(struct ac97_private), + GFP_KERNEL); + struct snd_soc_ac97_codec_platform_data *pdata = + pdev->dev.platform_data; + + if (!ac97) + return -ENOMEM; + + if (pdata) { + ac97->playback_rate_constrained = + pdata->playback_rate_constrained; + ac97->capture_rate_constrained = + pdata->capture_rate_constrained; + } else { + ac97->playback_rate_constrained = 1; + ac97->capture_rate_constrained = 1; + } + + platform_set_drvdata(pdev, ac97); + return snd_soc_register_codec(&pdev->dev, &soc_codec_dev_ac97, &ac97_dai, 1); }

2 6

[alsa-devel] bug
by Nikita N. 07 Apr '15

07 Apr '15

is any programmer listening here? -- http://www.fastmail.com - A no graphics, no pop-ups email service

10 35

[alsa-devel] [PATCH] ALSA: hda_intel: add AZX_DCAPS_I915_POWERWELL for skl
by libin.yang＠intel.com 07 Apr '15

07 Apr '15

From: Libin Yang <libin.yang(a)intel.com> HDMI/DP codec on SKL is in the power well. The power well must be turned on before probing the HDMI/DP codec. Signed-off-by: Libin Yang <libin.yang(a)intel.com> --- sound/pci/hda/hda_intel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 15a8299..4744a96 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -298,7 +298,8 @@ enum { AZX_DCAPS_SNOOP_TYPE(SCH)) #define AZX_DCAPS_INTEL_SKYLAKE \ - (AZX_DCAPS_INTEL_PCH | AZX_DCAPS_SEPARATE_STREAM_TAG) + (AZX_DCAPS_INTEL_PCH | AZX_DCAPS_SEPARATE_STREAM_TAG |\ + AZX_DCAPS_I915_POWERWELL) /* quirks for ATI SB / AMD Hudson */ #define AZX_DCAPS_PRESET_ATI_SB \ -- 1.9.1

4 19

[alsa-devel] [PATCH] ALSA: emu10k1: add Audigy 5/Rx
by Michael Gernoth 05 Apr '15

05 Apr '15

The Audigy 5/Rx is essentially an Audigy 4 behind a PLX PCIe- bridge with an additional TOSLINK output. Signed-off-by: Michael Gernoth <michael(a)gernoth.net> --- sound/pci/emu10k1/emu10k1_main.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/sound/pci/emu10k1/emu10k1_main.c b/sound/pci/emu10k1/emu10k1_main.c index b4458a6..8e510e9 100644 --- a/sound/pci/emu10k1/emu10k1_main.c +++ b/sound/pci/emu10k1/emu10k1_main.c @@ -1325,6 +1325,22 @@ static int snd_emu10k1_dev_free(struct snd_device *device) } static struct snd_emu_chip_details emu_chip_details[] = { + /* Audigy 5/Rx SB1550 */ + /* Tested by michael(a)gernoth.net 28 Mar 2015 */ + /* DSP: CA10300-IAT LF + * DAC: Cirrus Logic CS4382-KQZ + * ADC: Philips 1361T + * AC97: Sigmatel STAC9750 + * CA0151: None + */ + {.vendor = 0x1102, .device = 0x0008, .subsystem = 0x10241102, + .driver = "Audigy2", .name = "SB Audigy 5/Rx [SB1550]", + .id = "Audigy2", + .emu10k2_chip = 1, + .ca0108_chip = 1, + .spk71 = 1, + .adc_1361t = 1, /* 24 bit capture instead of 16bit */ + .ac97_chip = 1} , /* Audigy4 (Not PRO) SB0610 */ /* Tested by James(a)superbug.co.uk 4th April 2006 */ /* A_IOCFG bits -- 2.1.4

2 1

[alsa-devel] SoundBlaster X-fi HD SPDIF fix
by Richard Körber 05 Apr '15

05 Apr '15

Hi! I own a Creative USB SoundBlaster X-fi HD and tried to use its SPDIF optical output. However it didn't work with ALSA out of the box. The reason is that for SPDIF output device #1 must be used. The fix is: In /usr/share/alsa/cards/USB-Audio.conf, change the iec958_device block like this: USB-Audio.pcm.iec958_device { "USB Sound Blaster HD" 1 } Digital output works fine for me after that. BTW, I tried this line in /etc/asound.conf cards.USB-Audio.pcm.iec958_device."USB Sound Blaster HD" 1 but it didn't have any effect. Why was that? Thank you! Regards Richard Körber

2 8

[alsa-devel] Support Dell headset mode for ALC256
by Kailang 04 Apr '15

04 Apr '15

Hi Takashi, Dell has new platform with ALC256. Attach patch is support headset mode for ALC256. Thanks. BR, Kailang

2 1

[alsa-devel] dummy codec + simple card combination
by Belisko Marek 03 Apr '15

03 Apr '15

Hi, I'm trying to add audio support for gta04 (for gsm + bt and fm audio). All audio sources are clock masters so basically connection is dummy codecs -> cpu dai (mcbsp ports). For implementing such thing I can see 2 options: 1. simple card driver which can easily describe cpu dai interface but dummy codec cannot because there are no DT bindings (there was sever attempts to add DT bindings for dummy-codec but AFAIK none was accepted) This turns it to only solution to create gta04 soundcard which will get from DT cpu dai links and use in card driver dummy codecs directly. Is my assumption correct? I would like to get some feedback before wasting my time with implementing something which cannot be pushed mainline. Thanks for all suggestions. BR, marek -- as simple and primitive as possible ------------------------------------------------- Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com

4 9