September 2016 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] No speaker output on Skylake SoC
by infernix 12 Sep '16

12 Sep '16

Hi, On a Skylake based Samsung Tabpro S tablet I am having two alsa issues on 4.7.0 and 4.8.0-rc5: - no output on speaker with any possible configuration, but audio over headphone jack works - playback speed/pitch is doubled (audible over headphones) Sound works fine in Windows obviously, but rebooting from Windows to Linux (as opposed to cold boot) doesn't seem to have any influence on these issues. I've tried modprobing with all the various ALC model quirks to no avail. I've tried toggling various options with amixer (Auto Mute, various speaker related values with amixer cset) and even played with hda-analyzer.py but was unable to get anything from the speakers whatsoever. Since this is Sunrise Point-LP HD Audio, I realize it's fairly new and there may be new quirks required to make this work. I've attached alsa-info.txt; I'm happy to patch and test if someone can give me some direction on what to try, but any help would be much appreciated. Thanks.

1 0

Re: [alsa-devel] Switching from default to plughw:0,0
by Clemens Ladisch 11 Sep '16

11 Sep '16

Gonzalo Garramuño wrote: > El 10/09/16 a las 20:46, Clemens Ladisch escribió: >> Gonzalo Garramuño wrote: >>> My problem is that when I choose the default, which is equivalent to plughw:0,0 >> >> The default actually is PulseAudio or dmix. > > dmix is not installed in my system It's part of ALSA. > Do I have to deal with the pulseaudio api, instead of the ALSA api? When PulseAudio is configured as the default, it can be accessed through the ALSA API. Anyway, the correct name for the default device is "default". To get a list of devices, see "aplay -L". Regards, Clemens

2 1

[alsa-devel] Fwd: HT Omega Claro II support
by German Gomez 11 Sep '16

11 Sep '16

Hello, I've sent this email to Clemens Ladisch, that appears as the developer of the snd-oxygen driver, but just in case he is not the actual maintainer of the driver, I'm forwarding it here. Thanks, - german -------- Forwarded Message -------- Subject: HT Omega Claro II support Date: Thu, 8 Sep 2016 00:32:36 -0700 From: German Gomez <gergomez(a)gmail.com> To: Clemens Ladisch <clemens(a)ladisch.de> Hello, I've read in the alsa-users mailing-list (https://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg29284.html) that there is no support for the HT Omega Claro II card and that you should have to reverse engineer the windows driver to add it. I have that soundcard, although I has been able to use the onboard HDA audio when booting to Linux. But now my onboard audio is not working (it is dead, not working either under Windows) so I'm trying to make the Claro II working under Linux. I've contacted the HT Omega support and to my surprise they actually answered with some useful information. I've attached the email. The summary is that the Claro II should be exactly the same as the other cards by HT Omega using the CMI8788 except that the GPIO for initializing the card is #6. I have compared specs for both Claro (http://www.htomega.com/claro.html) and Claro II (http://www.htomega.com/claro2.html), and there are more differences, the Claro uses AK4396VF and WM8785G chips while the Claro II uses AK4396VF and CS4362 (+ CS5361 for line input). I've checked the code under sound/pci/oxygen and it seems that we have support for the CS4362 for the Xonar D1/DX soundcard. I don't know if having the GPIO pin for initialization and all the other chips already there is enough to add support, of course I'm willing to test any patch that you could provide. I've taken a look at the code, as I'm not bad with C, but audio driver development is completely outside my skills and domain, so I'm quite lost, if you don't have time or if it is not trivial to add support for the Claro II I would understand it, but the card is a really good one and it is quite easy to find in the US, it would be awesome to have support for it in ALSA. Thank you for your time! - german* *

1 0

[alsa-devel] [PATCH] ALSA: hda - Fix headset mic detection problem for several Dell laptops
by Hui Wang 11 Sep '16

11 Sep '16

One of the laptops has the codec ALC256 on it, applying the ALC255_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem, the rest of laptops have the codec ALC295 on them, they are similar to machines with ALC225, applying the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 575cefd..32cbcf8 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5806,6 +5806,13 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {0x14, 0x90170110}, \ {0x15, 0x0221401f} +#define ALC295_STANDARD_PINS \ + {0x12, 0xb7a60130}, \ + {0x14, 0x90170110}, \ + {0x17, 0x21014020}, \ + {0x18, 0x21a19030}, \ + {0x21, 0x04211020} + #define ALC298_STANDARD_PINS \ {0x12, 0x90a60130}, \ {0x21, 0x03211020} @@ -5911,6 +5918,10 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = { {0x14, 0x90170120}, {0x21, 0x02211030}), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x14, 0x90170110}, + {0x21, 0x02211020}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ALC256_STANDARD_PINS), SND_HDA_PIN_QUIRK(0x10ec0280, 0x103c, "HP", ALC280_FIXUP_HP_GPIO4, {0x12, 0x90a60130}, @@ -6021,6 +6032,8 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = { SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE, ALC292_STANDARD_PINS, {0x13, 0x90a60140}), + SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, + ALC295_STANDARD_PINS), SND_HDA_PIN_QUIRK(0x10ec0298, 0x1028, "Dell", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE, ALC298_STANDARD_PINS, {0x17, 0x90170110}), -- 1.9.1

2 1

[alsa-devel] Switching from default to plughw:0,0
by Gonzalo Garramuño 11 Sep '16

11 Sep '16

I have coded an application that uses ALSA and plays back movie's audios, together with their videos. I have pulseaudio installed by default as it comes with Ubuntu Xenian. My goal is to provide the user with an easy pull-down where they can select the audio device to play the audio in. The first audio device is "default" and defaults to ALSA's default in the Ubuntu Sound Preferences. All that works fine. I can change the Ubuntu Sound Preferences and the default driver immediately picks up the other cards or outputs in the system. My problem is that when I choose the default, which is equivalent to plughw:0,0, when I go to force select in my program the plughw:0,0 (HDA Intel PCH: ALC1150 Analog), I get a Device or resource busy. Sure enough, if I do: $ fuser -v /dev/snd/* USUARIO ORDEN DE ACCESO PID /dev/snd/controlC0: gga 3594 F.... pulseaudio /dev/snd/controlC1: gga 3594 F.... pulseaudio /dev/snd/pcmC0D0p: gga 4821 F...m pulseaudio I am very careful in closing the audio before reopening it again. However the resource remains busy for about 7 seconds. Then it turns into: USUARIO ORDEN DE ACCESO PID /dev/snd/controlC0: gga 3594 F.... pulseaudio /dev/snd/controlC1: gga 3594 F.... pulseaudio /dev/snd/pcmC0D0p: gga 4821 F...m mrViewer and the audio works again. My close function looks like: bool ALSAEngine::close() { if ( _pcm_handle ) { int err = snd_pcm_drop( _pcm_handle ); if ( err < 0 ) { std::cerr << "ERROR: [alsa] snd_pcm_drop failed with " << snd_strerror(err) << std::endl; } err = snd_pcm_close( _pcm_handle ); if ( err < 0 ) { std::cerr << "ERROR: [alsa] snd_pcm_close failed with " << snd_strerror(err) << std::endl; } _pcm_handle = NULL; } return true; } and the open function (simplified till it fails). bool ALSAEngine::open( const unsigned channels, const unsigned freq, const AudioFormat format, const unsigned bits ) { try { close(); int status; unsigned int test_format = (unsigned int) format; char buf[256]; /* Open the audio device */ /* Name of device should depend on # channels in spec */ _pcm_handle = NULL; status = snd_pcm_open(&_pcm_handle, device().c_str(), SND_PCM_STREAM_PLAYBACK, 0); if ( status < 0 || _pcm_handle == NULL ) { sprintf( buf, _("Couldn't open audio device %s: %s"), device().c_str(), snd_strerror(status)); THROW(buf); } ....snip..... }

2 2

[alsa-devel] [RFC][PATCH 0/2] ALSA: control: limit life time of user-defined element set
by Takashi Sakamoto 10 Sep '16

10 Sep '16

Hi, This patchset is an example to implement an idea mentioned in this thread: [alsa-devel] [PATCH] Softvol: Allow per process volume control. http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/095026.html ALSA control core allows applications to add arbitrary element sets to an instance of control device, while removal of the element sets is voluntarily done by some applications. This is not convenient to certain situations. For example, an application adds some element sets, then aborted due to programming mistakes, and restart. Needless elements can be added one after another. This patchset limits life time of user-defined element set. Basically, the life time is corresponding to a file descriptor opened by a process to add element sets. However, elements can be locked by the other processes. For this case, this patchset counts locked elements, then judge to remove an element set including these elements. My large concern is whether there's any applications to open a file descriptor just to add any element sets. In this case, added element sets are removed immediately at closing the file descriptor unexpectedly to the application, and unavailable to the other processes anymore. In this point, this patchset is intrusive. (But I'm a bit optimistic because use-defined element set is long abandoned not to work well in several items, and there may be probably few consumers in user space. Perhaps, this change is acceptable, I hope.) To reviewers, my aim for this patchset is to show attempts to synchronize life time of user-defined element set to file descriptors. Any objections are welcome. Then, I'd like to receive alternative ideas, especially for definition of the life time. Takashi Sakamoto (2): ALSA: control: limit life time of user-defined element set ALSA: control: bump up protocol version to 2.0.8 include/uapi/sound/asound.h | 2 +- sound/core/control.c | 101 +++++++++++++++++++++++++++++++++++++------- 2 files changed, 87 insertions(+), 16 deletions(-) -- 2.7.4

3 7

[alsa-devel] [RFC][PATCH 0/2] ALSA: control: export all of TLV related macros to user land
by Takashi Sakamoto 10 Sep '16

10 Sep '16

2 7

[alsa-devel] [PATCH] ASoC: da7219: make sure the valid event when startup
by Xing Zheng 09 Sep '16

09 Sep '16

We need to ensure the master bias and jack detection to be enabled before reporting event at the da7219_aad_irq_thread. Otherwise, we may acquire the incorrect the unplug event when the DUT startup with a plugged headphone. Signed-off-by: Xing Zheng <zhengxing(a)rock-chips.com> --- sound/soc/codecs/da7219-aad.c | 7 +++++++ sound/soc/codecs/da7219-aad.h | 1 + 2 files changed, 8 insertions(+) diff --git a/sound/soc/codecs/da7219-aad.c b/sound/soc/codecs/da7219-aad.c index 4e369a1..cef17c0d 100644 --- a/sound/soc/codecs/da7219-aad.c +++ b/sound/soc/codecs/da7219-aad.c @@ -38,6 +38,7 @@ void da7219_aad_jack_det(struct snd_soc_codec *codec, struct snd_soc_jack *jack) da7219->aad->jack = jack; da7219->aad->jack_inserted = false; + da7219->aad->accdet_en = false; /* Send an initial empty report */ snd_soc_jack_report(jack, 0, DA7219_AAD_REPORT_ALL_MASK); @@ -46,6 +47,8 @@ void da7219_aad_jack_det(struct snd_soc_codec *codec, struct snd_soc_jack *jack) snd_soc_update_bits(codec, DA7219_ACCDET_CONFIG_1, DA7219_ACCDET_EN_MASK, (jack ? DA7219_ACCDET_EN_MASK : 0)); + + da7219->aad->accdet_en = true; } EXPORT_SYMBOL_GPL(da7219_aad_jack_det); @@ -293,6 +296,10 @@ static irqreturn_t da7219_aad_irq_thread(int irq, void *data) u8 statusa; int i, report = 0, mask = 0; + /* Ensure the master bias to be enabled */ + if (!da7219_aad->accdet_en) + return IRQ_NONE; + /* Read current IRQ events */ regmap_bulk_read(da7219->regmap, DA7219_ACCDET_IRQ_EVENT_A, events, DA7219_AAD_IRQ_REG_MAX); diff --git a/sound/soc/codecs/da7219-aad.h b/sound/soc/codecs/da7219-aad.h index 4fccf67..5641965 100644 --- a/sound/soc/codecs/da7219-aad.h +++ b/sound/soc/codecs/da7219-aad.h @@ -200,6 +200,7 @@ struct da7219_aad_priv { struct snd_soc_jack *jack; bool jack_inserted; + bool accdet_en; }; /* AAD control */ -- 1.9.1

2 1

[alsa-devel] [PATCH 00/13] ASoC: topology: Remaining kernel patches
by mengdong.lin＠linux.intel.com 09 Sep '16

09 Sep '16

From: Mengdong Lin <mengdong.lin(a)linux.intel.com> This series contains all remaining kernel patches of topology, including some ABI update to PCM (FrontEnds) and link (BackEnds) objects. We don't user more series. User will be able to create BE DAIs and DAI links, configure more for FE links. Code are verified and can cover reqeust of Intel pre-release platforms for next year, so ABI should be stable. Current kernel topology code does not really touch Codec-Codec links since there is no user requst atm. We can add support for CC links later by reusing code and data structures for BE links, and no need to revise ABI. Guneshwor Singh (1): ASoC: topology: Add FE DAIs only if not already added Mengdong Lin (12): ASoC: topology: Able to create BE DAIs ASoC: topology: ABI - Add sig_bits to stream caps ASoC: topology: ABI - Define DPCM trigger ordering for PCM ASoC: topology: ABI - Add flags to PCM ASoC: topology: ABI - Add private data to PCM ASoC: topology: ABI - Add name & component info to BE/CC links ASoC: topology: ABI - Define DAI physical PCM data formats ASoC: topology: ABI - Add HW configurations to BE/CC links ASoC: topology: ABI - Add flags and private data to BE/CC links ASoC: Define API to find a dai link by id ASoC: Probe link components after finding new links ASoC: topology: Able to create BE DAI links include/sound/soc-dai.h | 15 +- include/sound/soc-dpcm.h | 13 -- include/sound/soc-topology.h | 1 + include/sound/soc.h | 2 + include/uapi/sound/asoc.h | 106 ++++++++++++- sound/soc/soc-core.c | 36 ++++- sound/soc/soc-topology.c | 359 ++++++++++++++++++++++++++++++++++++++----- 7 files changed, 466 insertions(+), 66 deletions(-) -- 2.5.0

3 25

[alsa-devel] [PATCH] ASoC: sgtl5000: add headphone and LINEOUT mute controls
by Richard Leitner 09 Sep '16

09 Sep '16

These controls mute/unmute the LINEOUT and headphone outputs of SGTL5000 using its CHIP_ANA_CTRL register. Signed-off-by: Richard Leitner <dev(a)g0hl1n.net> --- sound/soc/codecs/sgtl5000.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index 527b759..a6af65d 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -411,6 +411,8 @@ static const struct snd_kcontrol_new sgtl5000_snd_controls[] = { 0, 8, 0x7f, 1, headphone_volume), + SOC_SINGLE("Headphone Playback Switch", SGTL5000_CHIP_ANA_CTRL, + 4, 1, 0), SOC_SINGLE("Headphone Playback ZC Switch", SGTL5000_CHIP_ANA_CTRL, 5, 1, 0), @@ -423,6 +425,7 @@ static const struct snd_kcontrol_new sgtl5000_snd_controls[] = { SGTL5000_LINE_OUT_VOL_RIGHT_SHIFT, 0x1f, 1, lineout_volume), + SOC_SINGLE("Lineout Playback Switch", SGTL5000_CHIP_ANA_CTRL, 8, 1, 0), }; /* mute the codec used by alsa core */ -- 2.9.3

2 3