June 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ASoC: wm8994: Don't suspend accessory detection
by Mark Brown 26 Jun '12

26 Jun '12

Leave it up to the machine driver to disable accessory detection if desired, the common pattern is to have accessory detection be a wake source. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 37 ------------------------------------- 1 file changed, 37 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 6474bae..a4aafdb 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -2967,23 +2967,8 @@ static struct snd_soc_dai_driver wm8994_dai[] = { static int wm8994_codec_suspend(struct snd_soc_codec *codec) { struct wm8994_priv *wm8994 = snd_soc_codec_get_drvdata(codec); - struct wm8994 *control = wm8994->wm8994; int i, ret; - switch (control->type) { - case WM8994: - snd_soc_update_bits(codec, WM8994_MICBIAS, WM8994_MICD_ENA, 0); - break; - case WM1811: - snd_soc_update_bits(codec, WM8994_ANTIPOP_2, - WM1811_JACKDET_MODE_MASK, 0); - /* Fall through */ - case WM8958: - snd_soc_update_bits(codec, WM8958_MIC_DETECT_1, - WM8958_MICD_ENA, 0); - break; - } - for (i = 0; i < ARRAY_SIZE(wm8994->fll); i++) { memcpy(&wm8994->fll_suspend[i], &wm8994->fll[i], sizeof(struct wm8994_fll_config)); @@ -3033,28 +3018,6 @@ static int wm8994_codec_resume(struct snd_soc_codec *codec) i + 1, ret); } - switch (control->type) { - case WM8994: - if (wm8994->micdet[0].jack || wm8994->micdet[1].jack) - snd_soc_update_bits(codec, WM8994_MICBIAS, - WM8994_MICD_ENA, WM8994_MICD_ENA); - break; - case WM1811: - if (wm8994->jackdet && wm8994->jack_cb) { - /* Restart from idle */ - snd_soc_update_bits(codec, WM8994_ANTIPOP_2, - WM1811_JACKDET_MODE_MASK, - WM1811_JACKDET_MODE_JACK); - break; - } - break; - case WM8958: - if (wm8994->jack_cb) - snd_soc_update_bits(codec, WM8958_MIC_DETECT_1, - WM8958_MICD_ENA, WM8958_MICD_ENA); - break; - } - return 0; } #else -- 1.7.10

1 0

[alsa-devel] [PATCH] davinci:mcasp: Fix codec pll configure bug
by Hebbar, Gururaja 26 Jun '12

26 Jun '12

In sound/soc/codecs/tlv320aic3x.c data = snd_soc_read(codec, AIC3X_PLL_PROGA_REG); snd_soc_write(codec, AIC3X_PLL_PROGA_REG, data | (pll_p << PLLP_SHIFT)); In the above code, pll-p value is OR'ed with previous value without clearing it. Bug is not seen if pll-p value doesn't change across Sampling frequency. However on some platforms (like AM335x EVM-SK), pll-p may have different values across different sampling frequencies. In such case, above code configures the pll with a wrong value. Because of this bug, when a audio stream is played with pll value different from previous stream, audio is heard as stretched. Fix the same by clearing the mask and then writing the value. Signed-off-by: Hebbar, Gururaja <gururaja.hebbar(a)ti.com> --- sound/soc/codecs/tlv320aic3x.c | 2 +- sound/soc/codecs/tlv320aic3x.h | 1 + 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index d0dbac1..8c1977b 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -963,7 +963,7 @@ static int aic3x_hw_params(struct snd_pcm_substream *substream, } found: - data = snd_soc_read(codec, AIC3X_PLL_PROGA_REG); + data = snd_soc_read(codec, AIC3X_PLL_PROGA_REG) & ~PLLP_MASK; snd_soc_write(codec, AIC3X_PLL_PROGA_REG, data | (pll_p << PLLP_SHIFT)); snd_soc_write(codec, AIC3X_OVRF_STATUS_AND_PLLR_REG, diff --git a/sound/soc/codecs/tlv320aic3x.h b/sound/soc/codecs/tlv320aic3x.h index 06a1978..16d9999 100644 --- a/sound/soc/codecs/tlv320aic3x.h +++ b/sound/soc/codecs/tlv320aic3x.h @@ -166,6 +166,7 @@ /* PLL registers bitfields */ #define PLLP_SHIFT 0 +#define PLLP_MASK 7 #define PLLQ_SHIFT 3 #define PLLR_SHIFT 0 #define PLLJ_SHIFT 2 -- 1.7.1

1 1

[alsa-devel] [PATCH] ALSA: hda - Add Realtek ALC280 codec support
by David Henningsson 26 Jun '12

26 Jun '12

This chip looks very similar to ALC269 and ALC27* variants. The bug reporter has verified that sound was working after this patch had been applied. Cc: stable(a)kernel.org BugLink: https://bugs.launchpad.net/bugs/1017017 Tested-by: Richard Crossley <richardcrossley(a)o2.co.uk> Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) Alsa info available at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1017017/+attachment/32… diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 41475ae..a5534b3 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6800,6 +6800,7 @@ static const struct hda_codec_preset snd_hda_preset_realtek[] = { { .id = 0x10ec0272, .name = "ALC272", .patch = patch_alc662 }, { .id = 0x10ec0275, .name = "ALC275", .patch = patch_alc269 }, { .id = 0x10ec0276, .name = "ALC276", .patch = patch_alc269 }, + { .id = 0x10ec0280, .name = "ALC280", .patch = patch_alc269 }, { .id = 0x10ec0861, .rev = 0x100340, .name = "ALC660", .patch = patch_alc861 }, { .id = 0x10ec0660, .name = "ALC660-VD", .patch = patch_alc861vd }, -- 1.7.9.5

2 1

Re: [alsa-devel] Using UCM with PulseAudio
by Arun Raghavan 25 Jun '12

25 Jun '12

On Thu, 2012-06-21 at 16:30 +0800, Feng Wei wrote: > 2012/6/20 Arun Raghavan <arun.raghavan(a)collabora.co.uk>: > > Liam, > > Thanks for clearing things up. > > > > On Fri, 2012-06-15 at 18:08 +0100, Liam Girdwood wrote: > > [...] > >> > The first problem is mutual exclusivity of verbs. From what I can > >> > understand, verbs are intended to be mutually exclusive -- if you have a > >> > HiFi verb and a VoiceCall verb, only one may be used at a time. We have > >> > mapped verbs to card profiles, which offer the same guarantee. However, > >> > on Android (which is a fair example of the kind of audio policy we might > >> > want), the HiFi verb PCMs maybe used while the VoiceCall PCMs are open. > >> > This is done, for example, to play an end-of-call tone from the CPU > >> > while the modem PCMs are still held open. Is there some way to do this > >> > with UCM? > >> > > >> > >> A verb is not tied to any specific PCM device here. It's intended to be > >> the highest level of audio use case where it can configure any audio > >> resource (including multiple cards) to enable the use case action. > >> > >> So for OMAP4 we would have the HiFi verb for all use case where we are > >> playing or capturing HiFi quality and the voice call verb where we are > >> making a telephone voice call. > >> > >> UCM provides the "modifier" to allow ad-hoc modifications to the audio > >> use case like above where we want to play an end of call tone. In this > >> case the verb is still VoiceCall, but PA would enable the "PlayTone" > >> modifer to play the tone (UCM can also tell Pulseaudio the sink PCM and > >> volume control for the tone data). > > > > Just as an observation, I think the Android HAL just uses PCM 0 and not > > the PCM 3, but in the PA case, I'll do it the way you describe since > > that makes more sense. > > > >> > The second problem is having separate PCMs for modifiers. In the OMAP4 > >> > profile, ringtone playback is exposed via a PlayTone modifier which > >> > corresponds to a separate PCM from regular HiFi playback. In the UCM-PA > >> > mapping we decided on, modifiers were implemented as device intended > >> > roles on a sink, so that when a stream with that role came in, we could > >> > enable the modifier, and disable it when such a stream ends. However, > >> > this doesn't account for switching the PCM on which playback is > >> > occurring. Should we be creating a separate sink for such modifiers > >> > (with lower priority, so they're not routed to unless there's a stream > >> > with the required role coming in)? Or should we be reopening the PCM for > >> > this? > >> > >> The intention for modifiers that use separate ALSA PCM sinks/sources > >> from the verb is to keep the main stream on the verb PCM source/sink and > >> the modifier stream will use the modifier PCM sink/source (this can be > >> the same PCM for some hardware). > >> > >> e.g. MP3 will be played to pcm 0 sink and ringtone to pcm 1 sink. The HW > >> will then mix both streams before they are rendered. > > > > Okay, so what this means is that we need to extend the current UCM work > > to create a second, lower priority sink for each modifier that has a > > distinct PlaybackPCM, and let the role-based routing pick that in cases > > where it makes sense. It's good that this doesn't change how we've > > mapped existing concepts -- just adds to it. > Sounds fine to me. The only problem is can we always open the modifier > pcm when modifier is not enabled. If not, I prefer to create/destroy > the sink by events. The alternative is to always add the sink and enable/disable the modifier in the I/O thread since we will get a message when a sink-input is added/removed. I'm just hacking this bit up, and will post patches if it all works out. There is another question here -- whether the modifier sink should have any ports or not. If I understand this correctly, we could let the actual routing be handled by the "main" sink's port and have the modifier sinks not touch that at all by not having any ports. In the ideal world though, it would be nice to have the ability to mark ports as being "dependent" somehow, so that port changes on the main sink would reflect in all others. This would be particularly useful for sinks and sources that have correlated paths like they do in the OMAP4 case. -- Arun

1 1

Re: [alsa-devel] Possible message repeat
by Clemens Ladisch 25 Jun '12

25 Jun '12

Brent Weatherall wrote: > our goal is to specify a special XU that WOULD require vendors > supporting it to modify their firmware. We fully expect a vendor to > modify their firmware to support our specification. That being said, > is there a simple way to use ALSA to communicate with a vendor > specific XU as long as the software understands the XU? For example, > in the video4linux2 world, we can specify a UVC XU with a set of > controls for special processing, then vendors that want to support it > modify their firmware to support it. Then anyone can use our custom > user-space drivers to easily talk to the video device. V4L2 has > controls made for using XUs in this manner. The audio class specification does not define any mechanism for a device to specify what those controls would be. And because nobody has ever needed to use XUs so far, the current ALSA driver has no other way to create such controls. If you insist on not changing ALSA, you must bypass it. Regards, Clemens

2 1

[alsa-devel] wm8994 trivial merge fix
by Takashi Iwai 25 Jun '12

25 Jun '12

FYI, the patch below is what I applied from Jaroslav's tree. I simply picked it up directly into my tree (fix/asoc and for-linus branches) because of triviality. Takashi --- From 6cab3e1e65bfe070f09bb091eeda182b171d5929 Mon Sep 17 00:00:00 2001 From: Jaroslav Kysela <perex(a)perex.cz> Date: Mon, 28 May 2012 11:14:33 +0200 Subject: [PATCH] ASoC: wm8994: remove duplicate code It seems that the code duplication was added at a merge operation. Signed-off-by: Jaroslav Kysela <perex(a)perex.cz> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/soc/codecs/wm8994.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index aa8c98b..1436b6c 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -727,9 +727,6 @@ static void wm1811_jackdet_set_mode(struct snd_soc_codec *codec, u16 mode) if (!wm8994->jackdet || !wm8994->jack_cb) return; - if (!wm8994->jackdet || !wm8994->jack_cb) - return; - if (wm8994->active_refcount) mode = WM1811_JACKDET_MODE_AUDIO; -- 1.7.10.4

2 1

[alsa-devel] [PATCH] ASoC: dwc: Bodge around continuing absence of clock API stubs
by Mark Brown 25 Jun '12

25 Jun '12

The patches for stubbing out the generic clock API still haven't been applied so we need to either add ifdefs here or add a dependency until someone decides to actually apply them. Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/dwc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig index 93e9fc3..e334900 100644 --- a/sound/soc/dwc/Kconfig +++ b/sound/soc/dwc/Kconfig @@ -1,5 +1,6 @@ config SND_DESIGNWARE_I2S tristate "Synopsys I2S Device Driver" + depends on CLKDEV_LOOKUP help Say Y or M if you want to add support for I2S driver for Synopsys desigwnware I2S device. The device supports upto -- 1.7.10

1 0

[alsa-devel] [PATCH] ASoC: dmaengine_pcm: fix typo in comment
by Uwe Kleine-König 25 Jun '12

25 Jun '12

Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> --- sound/soc/soc-dmaengine-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c index 4756952..5647449 100644 --- a/sound/soc/soc-dmaengine-pcm.c +++ b/sound/soc/soc-dmaengine-pcm.c @@ -243,7 +243,7 @@ static int dmaengine_pcm_request_channel(struct dmaengine_pcm_runtime_data *prtd * Note that this function will use private_data field of the substream's * runtime. So it is not availabe to your pcm driver implementation. If you need * to keep additional data attached to a substream use - * snd_dmaeinge_pcm_{set,get}_data. + * snd_dmaengine_pcm_{set,get}_data. */ int snd_dmaengine_pcm_open(struct snd_pcm_substream *substream, dma_filter_fn filter_fn, void *filter_data) -- 1.7.10

2 1

[alsa-devel] [RFC PATCH] Inverted internal mic
by David Henningsson 25 Jun '12

25 Jun '12

Hi, One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output. This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output. There are various ways we can work around this in both the kernel, alsa-lib and PulseAudio layers. It's a matter of picking the right one. I'm leaning towards trying to fix it in the kernel's codec drivers, because 1) we already have quirking infrastructure there 2) we already have some working quirks already in that layer 3) it would benefit other sound applications that use ALSA directly. The downside to that is really that we're silencing out one channel for everyone, leading to no application being able to use both channels, even if they would implement some kind of "auto-detect-and-reverse-one-channel" functionality. For the most part, this has been some Acer Aspire machines running Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we have proc coefs we can set, but for the other two these proc coefs, if they exist, are unknown to us. Recently I came across a Conexant as well, and I decided to write a patch for it, that would take the approach that the internal mic is forced mono on the kcontrol, and make sure the right channel is always muted. The patch is verified by the reporter to fix this problem. It could use some perfection though - it would make sense to to the same to the internal mic boost as well, and the strcmp('Internal Mic') call could maybe be turned into something more elegant. But before going ahead with that, I'd like to hear your opinion on the matter, if you agree that this is a good approach to the problem? References: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/903853/+attachme… https://bugs.launchpad.net/bugs/903853 -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

5 38

[alsa-devel] Exclusive access to capture device
by Guy Rutenberg 24 Jun '12

24 Jun '12

Hi, Is there a way to open a capture device exclusively? E.g. I want to capture audio and be sure no other application can capture from that device at the same time. I've went through the API and searched the mailing list and haven't found a way to do so. Thanks a lot, Guy ---- http://www.guyrutenberg.com/

2 3