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

[alsa-devel] [PATCH] ASoC: Drop unnecessary bias level check on resume
by Lars-Peter Clausen 15 May '15

15 May '15

The suspended flag will only be set if the CODEC bias level was either STANDBY or OFF. This means we don't need to check for that on resume since the condition will always be true. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/soc-core.c | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 2373252..95b5f03 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -750,23 +750,10 @@ static void soc_resume_deferred(struct work_struct *work) } list_for_each_entry(codec, &card->codec_dev_list, card_list) { - /* If the CODEC was idle over suspend then it will have been - * left with bias OFF or STANDBY and suspended so we must now - * resume. Otherwise the suspend was suppressed. - */ if (codec->suspended) { - switch (codec->dapm.bias_level) { - case SND_SOC_BIAS_STANDBY: - case SND_SOC_BIAS_OFF: - if (codec->driver->resume) - codec->driver->resume(codec); - codec->suspended = 0; - break; - default: - dev_dbg(codec->dev, - "ASoC: CODEC was on over suspend\n"); - break; - } + if (codec->driver->resume) + codec->driver->resume(codec); + codec->suspended = 0; } } -- 1.8.0

2 1

[alsa-devel] [PATCH 1/8] ASoC: sn95031: Replace direct snd_soc_codec dapm field access
by Lars-Peter Clausen 15 May '15

15 May '15

The dapm field of the snd_soc_codec struct is eventually going to be removed, in preparation for this replace all manual access to codec->dapm.bias_level with snd_soc_codec_get_bias_level(). While we are at it also replace the if(x == A) ... else if(x == B) ... construct with a switch-case. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- Complete series depends on topic/dapm --- sound/soc/codecs/sn95031.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/sn95031.c b/sound/soc/codecs/sn95031.c index e474368..3a7de01 100644 --- a/sound/soc/codecs/sn95031.c +++ b/sound/soc/codecs/sn95031.c @@ -194,7 +194,7 @@ static int sn95031_set_vaud_bias(struct snd_soc_codec *codec, break; case SND_SOC_BIAS_PREPARE: - if (codec->dapm.bias_level == SND_SOC_BIAS_STANDBY) { + if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_STANDBY) { pr_debug("vaud_bias powering up pll\n"); /* power up the pll */ snd_soc_write(codec, SN95031_AUDPLLCTRL, BIT(5)); @@ -205,17 +205,22 @@ static int sn95031_set_vaud_bias(struct snd_soc_codec *codec, break; case SND_SOC_BIAS_STANDBY: - if (codec->dapm.bias_level == SND_SOC_BIAS_OFF) { + switch (snd_soc_codec_get_bias_level(codec)) { + case SND_SOC_BIAS_OFF: pr_debug("vaud_bias power up rail\n"); /* power up the rail */ snd_soc_write(codec, SN95031_VAUD, BIT(2)|BIT(1)|BIT(0)); msleep(1); - } else if (codec->dapm.bias_level == SND_SOC_BIAS_PREPARE) { + break; + case SND_SOC_BIAS_PREPARE: /* turn off pcm */ pr_debug("vaud_bias power dn pcm\n"); snd_soc_update_bits(codec, SN95031_PCM2C2, BIT(0), 0); snd_soc_write(codec, SN95031_AUDPLLCTRL, 0); + break; + default: + break; } break; -- 1.8.0

2 8

[alsa-devel] USB-Audio.conf routing and dmix
by sylvain.bertrand＠gmail.com 15 May '15

15 May '15

Hi, I have a bose USB audio 5.1 device, a generic USB audio device. I noticed that the proper channels routing was missing from the default generic USB pcm, but dmix was used. And for the surround pcms I noticed it was the other way around! I did modify the default pcm to include a routing plugin. I put 8 channels in the routing plugin. I guess the proper way would be to detect the hw card number of channels and select a route plugin configuration with the correct count of channels (maybe their is a function to get that info?). I linked the surround51 and surround71 pcms with the 'disable-able' dmix section from the default pcm. I did not touch the surround40* pcms, surround pcms which are specific to some cards and the iec958 ones. http://filebin.ca/214UTT8fBnUm/USB-Audio.conf regards, -- Sylvain BERTRAND

4 8

[alsa-devel] [PATCH early RFC 0/2] Implement ASoC HDMI codec library
by Jyri Sarha 15 May '15

15 May '15

This is on early RFC and should not be merged yet. The idea is just to share my ideas early on as there has been a lot of development going on around HDMI audio. The I2S DAI of the ASoC side patch is usable already, the spdif support has not been tested and the EDID SADs handling should use Russel's DRM ELD helper when it is ready. The tda998x patch is just to demonstrate the usage of the HDMI-codec-lib. At least the audio related DT-bindings are missing completely and the configuration is hard coded to work on Beaglebone-Black. Jean-Francois, would you consider trying the generic ASoC patch with your HW, as I can not test the spdif functionality with mine? The library could also be implemented as a separate platform driver, but then adding a pointer for private data to struct snd_soc_dai_driver, snd_soc_codec, or to snd_soc_component would be of great help. These patches, my tilcdc refactoring[1], and my latest BCLK fixes for davinci-mcasp diver [2], can found in a branch that produces a working HDMI audio on Beaglebone-Black here: https://github.com/jsarha/linux.git linux-master-bbb-hdmi-20150512 [1] http://lists.freedesktop.org/archives/dri-devel/2015-May/082537.html [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-April/090974.html Jyri Sarha (2): ASoC: hdmi-codec-lib: Add hdmi-codec-lib for external HDMI-encoders drm/i2c: tda998x: HACK Implement primitive HDMI audio with ASoC hdmi-code-lib drivers/gpu/drm/i2c/Kconfig | 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 238 +++++++++++++++++ include/sound/hdmi-codec-lib.h | 105 ++++++++ sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/hdmi-codec-lib.c | 536 ++++++++++++++++++++++++++++++++++++++ 6 files changed, 886 insertions(+) create mode 100644 include/sound/hdmi-codec-lib.h create mode 100644 sound/soc/codecs/hdmi-codec-lib.c -- 1.9.1

2 4

[alsa-devel] No sound from Mac Pro headphone port
by Todd Dailey 15 May '15

15 May '15

https://bugtrack.alsa-project.org/alsa-bug does not work so following instructions to post bug here. Linux 4. Mac Pro 2009. ACL889A codec. No sound from headphone port. Seems to detect plug / unplug OK. Works OK when machine booted to OS X or Windows 7. Have found several bug repors on similar issues with Mac laptops but no fixes. Have written e-mail with David Henningsson on problem but unable to find a solution. ALSA-info output: http://www.alsa-project.org/db/?f=1dc7146eb34af5ad307d029868f775fac5e2764e -- TD todd(a)todddailey.ca

2 5

[alsa-devel] [PATCH 01/11] ASoC: sta32x: Replace direct snd_soc_codec dapm field access
by Lars-Peter Clausen 14 May '15

14 May '15

The dapm field of the snd_soc_codec struct is eventually going to be removed, in preparation for this replace all manual access to codec->dapm.bias_level with snd_soc_codec_get_bias_level(). Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- All patches in this series depend on topic/dapm --- sound/soc/codecs/sta32x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/sta32x.c b/sound/soc/codecs/sta32x.c index 847fb20..60eff36 100644 --- a/sound/soc/codecs/sta32x.c +++ b/sound/soc/codecs/sta32x.c @@ -819,7 +819,7 @@ static int sta32x_set_bias_level(struct snd_soc_codec *codec, break; case SND_SOC_BIAS_STANDBY: - if (codec->dapm.bias_level == SND_SOC_BIAS_OFF) { + if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_OFF) { ret = regulator_bulk_enable(ARRAY_SIZE(sta32x->supplies), sta32x->supplies); if (ret != 0) { -- 1.8.0

2 11

Re: [alsa-devel] Intel DG45ID 5stack (No line in)
by Raymond Yau 14 May '15

14 May '15

> I have been using this MotherBoard for years (it is probably the most reliable one I have ever had): > http://www.intel.com/p/en_US/support/highlights/dsktpboards/dg45id > but from the beginning I had trouble with ALSA and the Line In port - documented here: > http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014825.h… > Mostly this has not been a problem since I only use the Line In port on infrequent occasions but it is annoying that when I do need to use it, sometimes, the method I have found to activate the port does not work and now using it seems to have permanently messed up the configuration for Back Mic for normal use somehow. I have installed Fedora 22 on a new drive (currently using 21) and booting on the new disk cures the introduced problem so it appears not to be permanent sound card damage at all and just some sort of caching or other issue. My procedure for getting the Line In port used to be this (although it didn't work this time and just caused a problem with the Back Mic): > - uninstall PulseAudio (or rename /usr/bin/pulseaudio) > - stop all apps auto starting that use ALSA > - reboot > - systemctl stop alsa-state.service > - echo 0x0c 0x01813021 > /sys/class/sound/hwC0D2/user_pin_configs > - echo 1 > /sys/class/sound/hwC0D2/reconfig > - chmod -R 777 /dev/snd > - systemctl start alsa-state.service > Going through this procedure showed up new controls in xfce4-mixer and everything worked fine for what I wanted to do - a reboot restored the original setup (it could also be done with echoing the original values). It has been some years since I used this technique but now I can't get it to work and some of the new controls that show up in xfce4-mixer ("Capture 1", "Input Source 1") don't disappear with a reboot - even if I: > rm .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-mixer.xml > !? Also, from Audacity I can now no longer select "Default" for the microphone and I can't get any of the other options to record . . > Is anybody able to tell me what is going on? I can just starting using F22 on the new drive and forget about using this procedure in the future but I don't like not knowing why things don't work reliably . . > Any useful information would be appreciated you have to post the output of alsa-info.sh https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=52d… pin fixup seem using [Jack] Speaker instead of [Jack] Line Out at Ext Rear Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green Pin Default 0x01011012: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Black Pin Default 0x01016011: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Orange Line in not assigned correctly https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=4d2… static const struct hda_pintbl intel_dg45id_pin_configs[] = { { 0x0a, 0x02214230 }, { 0x0b, 0x02A19240 }, - { 0x0c, 0x01013214 }, + { 0x0c, 0x01813021 }, { 0x0d, 0x01014210 }, { 0x0e, 0x01A19250 }, { 0x0f, 0x01011212 }, { 0x10, 0x01016211 }, {} };

1 0

Re: [alsa-devel] [PATCH v2 02/17] leds: port locomo leds driver to new locomo core
by Dmitry Torokhov 14 May '15

14 May '15

On Wed, May 13, 2015 at 04:53:03PM +0200, Jacek Anaszewski wrote: > On 05/13/2015 04:14 PM, Dmitry Eremin-Solenikov wrote: > >2015-05-13 13:31 GMT+03:00 Jacek Anaszewski <j.anaszewski(a)samsung.com>: > >>On 05/12/2015 05:35 PM, Dmitry Eremin-Solenikov wrote: > >>> > >>>2015-05-06 18:05 GMT+03:00 Jacek Anaszewski <j.anaszewski(a)samsung.com>: > >>>> > >>>>On 04/28/2015 01:55 AM, Dmitry Eremin-Solenikov wrote: > >>>>> > >>>>> > >>>>>Adapt locomo leds driver to new locomo core setup. > >>>>> > >>>>>Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> > >>>>>--- > >>>>> drivers/leds/Kconfig | 1 - > >>>>> drivers/leds/leds-locomo.c | 119 > >>>>>+++++++++++++++++++++++---------------------- > >>>>> 2 files changed, 61 insertions(+), 59 deletions(-) > >>>>> > >>>>>diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > >>>>>index 966b960..4b4650b 100644 > >>>>>--- a/drivers/leds/Kconfig > >>>>>+++ b/drivers/leds/Kconfig > >>>>>@@ -79,7 +79,6 @@ config LEDS_LM3642 > >>>>> config LEDS_LOCOMO > >>>>> tristate "LED Support for Locomo device" > >>>>> depends on LEDS_CLASS > >>>>>- depends on SHARP_LOCOMO > >>>> > >>>> > >>>> > >>>>Why do you remove this dependency? > >>> > >>> > >>>Because SHARP_LOCOMO is a Kconfig symbol for the old driver. New driver > >>>uses MFD_LOCOMO Kconfig entry. Also the driver now uses generic platform > >>>device and regmap interfaces, so there is no direct dependency on main > >>>LoCoMo driver. And the policy (IIRC) was not to have such dependencies. > >> > >> > >>Ack. Shouldn't you also need "select REGMAP_MMIO" ? > > > >No. Maybe I should add "select REGMAP" instead. > > REGMAP is enabled by default if REGMAP_MMIO is enabled. Having That is unfortunately not how select works: it does not automatically select parents for the selected symbol. Thanks. -- Dmitry

2 1

[alsa-devel] commit b1ef29725865 (ACPI _REV=2) causes sound regression on Dell XPS 13 [Was: Discussion around quirking the _REV behavior for the XPS 13 (2015) until 4.2]
by Dominik Brodowski 13 May '15

13 May '15

Hi, (CC'ing sound experts) indeed, commit b1ef29725865 causes a severe regression -- actually, it causes sound to be totally unusuable on the Dell XPS 13 (2015) on Debian jessie, while it works fine in 4.0 / with b1ef29725865 reverted. According to an off-list discussion, the sound breakage (and not just some jack detection issue) seems to be caused due to alsa-lib being too old. The matter is further complicated by the issue that the driver asks for some firmware blob intel/IntcPP01.bin which (at least) I cannot find anywhere. Under the no-regression rule, this means that either b1ef29725865 needs to be reverted or we need to find another solution to this matter, such as an override. And I think it is needed for longer than just for 4.1, as it will continue to be cause regressions on quite recent userspace. Best, Dominik PS/OT: Probably I'm preaching to the choir, but @Mario: it's a pity the XPS (or some versions of it) with pre-installed Ubuntu actually ships with a Wifi adapter which seems to be unsupported by upstream Linux... On Mon, May 04, 2015 at 06:26:25PM -0500, Mario Limonciello wrote: > > On 04/28/2015 06:21 PM, Mario Limonciello wrote: > >Hi, > > > >Due to b1ef2972586577e0ca9675254ee141f65a8824e5 landing recently as a result of some previous ACPI community discussion, the Dell XPS 13 (2015) no longer has fully functional audio. In case you aren't aware, the XPS 13 (2015) switches audio modes based upon a combination of what's detected for the _OSI string and _REV values. When "Windows 2013" is found with _REV=2 the audio codec will be configured for I2S audio mode. When "Windows 2013" with _REV=5 is found it will be configured for HDA audio mode. > > > >I2S audio is improving, but not as mature as HDA audio mode is at this point. Currently jack detection does not work properly in 4.1 with I2S audio codecs. I've been notified that the support for jack detection will be landing in 4.2. I'd like to discuss the possibility of including a quirk for the _REV behavior when the DMI information corresponding to the Dell XPS 13 (2015) is detected for 4.1. This will let it continue to run in HDA mode until I2S mode is mature. > > > >I'd also like to plan for the quirk to be dropped when jack detection has landed for 4.2 (or if it gets pushed out further when it lands for 4.3). > > > >Would you guys be open to that? > > > >Thanks, > Hello, > > I just wanted to follow up on this, I would like to come up with a solution before it's too late for 4.1 on the XPS 13 (2015). > > Thanks,

4 11

Re: [alsa-devel] [PATCH 2/4] ASoC: rockchip: add rockchip machine driver for max98090
by Mark Brown 13 May '15

13 May '15

On Wed, May 13, 2015 at 09:23:20PM +0800, zhengxing wrote: > On 2015年05月13日 03:26, Mark Brown wrote: > >This looks more like a normal and reasonable machine driver but then why > >have you created the generic rockchip machine driver? It seems like > >this should just be a regular machine driver like other platforms have, > >were it not for that this would be mostly fine apart from a couple of > >nitpicks below. > We just use rockchip_machine_driver to describe the supported codecs base on > origianl way, vendor machine driver(rockchip_max98090) will achieve > functions. Like I said in reply to the other message I just don't understand what you're saying here - take a look at the various Tegra machine drivers for example, they also have per-CODEC handling but they just use normal machine drivers to do it.

1 0