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

Re: [alsa-devel] [PATCH 2/2] ALSA: hda - Fix microphone for Sony VAIO Pro 13 (Haswell model)
by Hendrik-Jan Heins 25 Dec '13

25 Dec '13

Dear Takashi, David, it looks like this quirk also appears on the 11 Inch model of the Sony Vaio pro ( SVP112A1CM ). However, the device addess is different. Instead of: SND_PCI_QUIRK(0x104d, 0x90b6, "Sony VAIO Pro 13", ALC286_FIXUP_SONY_MIC_NO_PRESENCE), I see address 0x90b5 (no clue where I should find the 0x104d, can you please send me a pointer how to find this one?). Would it be possible to please also incorporate the fix for the 11 inch Vaio? Thanks, Hendrik-Jan Heins

1 0

[alsa-devel] [PATCH] ALSA: Add params_width() helpers
by Mark Brown 24 Dec '13

24 Dec '13

From: Mark Brown <broonie(a)linaro.org> Add helpers for obtaining the width of a format directly from params since this is expected to become a common operation in ASoC. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- include/sound/pcm_params.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/include/sound/pcm_params.h b/include/sound/pcm_params.h index 37ae12e..6b1c78f 100644 --- a/include/sound/pcm_params.h +++ b/include/sound/pcm_params.h @@ -354,4 +354,16 @@ params_period_bytes(const struct snd_pcm_hw_params *p) params_channels(p)) / 8; } +static inline int +params_width(const struct snd_pcm_hw_params *p) +{ + return snd_pcm_format_width(params_format(p)); +} + +static inline int +params_physical_width(const struct snd_pcm_hw_params *p) +{ + return snd_pcm_format_physical_width(params_format(p)); +} + #endif /* __SOUND_PCM_PARAMS_H */ -- 1.8.5.2

2 1

Re: [alsa-devel] linux-next: Tree for Dec 23 (sound/soc/soc-io.c)
by Randy Dunlap 24 Dec '13

24 Dec '13

On 12/22/13 21:19, Stephen Rothwell wrote: > Hi all, > > There will be no linux-next releases between Dec 25 and Jan 5 inclusive - > unless I get extremely bored. > > Changes since 20131220: > on x86_64: sound/built-in.o: In function `snd_soc_codec_set_cache_io': (.text+0x244ca): undefined reference to `regmap_init_i2c' CONFIG_REGMAP=y CONFIG_REGMAP_I2C=m Full randconfig file is attached. -- ~Randy

1 0

[alsa-devel] [PATCH] ALSA: Add params_width() helper
by Mark Brown 23 Dec '13

23 Dec '13

From: Mark Brown <broonie(a)linaro.org> Add a helper for obtaining the width of a format directly from params since this is expected to become a common operation in ASoC. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- Just starting on the ASoC changes to use this; I'm not 100% sure on the lack of prefixing for the name but it's consistent with the other uses so... include/sound/pcm_params.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/sound/pcm_params.h b/include/sound/pcm_params.h index 37ae12e..47b03b4 100644 --- a/include/sound/pcm_params.h +++ b/include/sound/pcm_params.h @@ -354,4 +354,10 @@ params_period_bytes(const struct snd_pcm_hw_params *p) params_channels(p)) / 8; } +static inline unsigned int +params_width(const struct snd_pcm_hw_params *p) +{ + return snd_pcm_format_width(params_format(p)); +} + #endif /* __SOUND_PCM_PARAMS_H */ -- 1.8.5.2

2 1

[alsa-devel] ALSA: hiface: Fix typo in 352800 rate definition
by Michael Trimarchi 23 Dec '13

23 Dec '13

The Vaughan device support the 352800 rate and not the 352000 Cc: Takashi Iwai <tiwai(a)suse.de> Cc: Antonio Ospite <ao2(a)amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael(a)amarulasolutions.com> --- sound/usb/hiface/pcm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/usb/hiface/pcm.c b/sound/usb/hiface/pcm.c index c21a3df..2c44139 100644 --- a/sound/usb/hiface/pcm.c +++ b/sound/usb/hiface/pcm.c @@ -110,7 +110,7 @@ static const struct snd_pcm_hardware pcm_hw = { #define HIFACE_RATE_96000 0x4a #define HIFACE_RATE_176400 0x40 #define HIFACE_RATE_192000 0x48 -#define HIFACE_RATE_352000 0x58 +#define HIFACE_RATE_352800 0x58 #define HIFACE_RATE_384000 0x68 static int hiface_pcm_set_rate(struct pcm_runtime *rt, unsigned int rate) @@ -141,8 +141,8 @@ static int hiface_pcm_set_rate(struct pcm_runtime *rt, unsigned int rate) case 192000: rate_value = HIFACE_RATE_192000; break; - case 352000: - rate_value = HIFACE_RATE_352000; + case 352800: + rate_value = HIFACE_RATE_352800; break; case 384000: rate_value = HIFACE_RATE_384000; -- 1.8.1.2 -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL |

2 1

[alsa-devel] HD-Audio/HDMI: avoid missing start of audio stream on audio reconfiguation or after S3
by Lin, Mengdong 23 Dec '13

23 Dec '13

Hi Takashi, We hope to continue discussing the workaround to avoid HDMI data missing when audio configuration changes (eg. stereo ->5.1 channel) or after S3. The basic idea is to insert silent audio stream playback on audio configuration changes. Please see updates below ... > -----Original Message----- > From: Takashi Iwai [mailto:tiwai@suse.de] > Sent: Thursday, December 19, 2013 9:27 PM > To: Lin, Mengdong > Cc: Wu, Fengguang; Li, Jocelyn; Girdwood, Liam R; Chehab, John > Subject: Re: Could you share some advice to check missing start of audio > stream in HDMI audio playback? > > At Thu, 19 Dec 2013 12:45:03 +0000, > Lin, Mengdong wrote: > > > > Many thanks, Takashi and Fengguang! > > > > Windows team met same issue. They also confirmed the latency for > monitor/AV receiver to reconfigure audio setup is not avoidable. > > > > And their workaround is to send silent audio data after each stream > reconfiguration, before playing back the valid audio stream. > > > > Do you feel this workaround should be implemented in driver or in > user-space? > > Hard to say. An easier for us would be user-space, but it can be done in > the driver (e.g. in the prepare callback), too, although the implementation > would become tricky. We'd need a static silence page and play it in > hda_intel.c as a special requirement in the prepare, then set the BLD back > to the normal buffer at the end of azx_pcm_prepare(). A bit complex, > but certainly doable. For Intel display engine, including Haswell/Ivybridg/Sandibridge, HW can generate silent audio data on driver request during a link underrun. So for these platforms, we can - enable this "HW internal fabrication" feature in i915 driver. HW supported 32kHz, N*44,1kHz, N*48kHz. - and add specified sleep at the end of azx_pcm_prepare() or generic_hdmi_playback_pcm_prepare() This can avoid audio driver to prepare silent data and transmit over HD-A link. Is it doable? > > Doing this in may generate extra latency to open a stream. And the > length of the steam depends on experience. > > Yes, it's purely depending on the receiver hardware. Can we add a kernel parameter to specify the length of the silent stream? It could be 0 by default, meaning no silent stream insertion and thus no extra latency for playback. > > > And silent streams in different formats need to be prepared since there > can be wrapped compressed stream for playback. > > So I'd like such a workaround in audio middleware in user-space. > > For the compress audio, it's a bit different problem, indeed. We need to check whether HW supports compressed data format. But at least we can apply this feature on PCM format. Thanks Mengdong > > Takashi > > > Thanks > > Mengdong > > > > > -----Original Message----- > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > Sent: Thursday, December 19, 2013 7:55 PM > > > To: Wu, Fengguang > > > Cc: Lin, Mengdong; Li, Jocelyn; Girdwood, Liam R; Chehab, John > > > Subject: Re: Could you share some advice to check missing start of > > > audio stream in HDMI audio playback? > > > > > > At Thu, 19 Dec 2013 15:38:40 +0800, > > > Fengguang Wu wrote: > > > > > > > > Mengdong, > > > > > > > > On Thu, Dec 19, 2013 at 02:30:33PM +0800, Lin, Mengdong wrote: > > > > > Hi Takashi/Fengguang > > > > > > > > > > > > > > > > > > > > Sorry to interrupt. Would you please share some advice to check > > > > > a HDMI audio issue below? > > > > > > > > > > > > > > > > > > > > For HDMI audio playback under Linux on Haswell/Valleyview, start > > > > > of an audio stream (2~4 seconds) may be missing before we can > > > > > hear the > > > sound, in two cases: > > > > > > > > > > - 1^st playback after S3. First several seconds of audio > > > stream can be > > > > > missing for some monitor, while other monitor does not have this > > > issue. > > > > > > > > > > - Switching from playing stereo PCM to 5.1 channel > PCM. > > > About first 2 > > > > > seconds of the 5.1 channel PCM cannot be heard from the AV > receiver. > > > > > > > > > > > > > > > > > > > > It seems some monitor/AV receiver can drop audio data before > > > > > playing sound. We wonder if we could improve in audio/gfx driver. > > > > > > > > > > Have you ever met similar issue on previous platforms? > > > > > > > > > > > > > > > > > > > > We’ll be appreciated if you could share us some tips to check > > > > > this > > > issue. > > > > > > > > > > > > > I once fixed a similar issue, hope it's useful information for you. > > > > > > > > commit 5779191e0efd851fb0d54698c13cb4f5325caca6 > > > > Author: Wu Fengguang <fengguang.wu(a)intel.com> > > > > AuthorDate: Wed Nov 18 12:38:06 2009 +0800 > > > > Commit: Takashi Iwai <tiwai(a)suse.de> > > > > CommitDate: Wed Nov 18 07:46:19 2009 +0100 > > > > > > > > ALSA: intelhdmi - sticky stream id and format > > > > > > > > We tracked down the first-0.5s-hdmi-audio-samples-lost > problem > > > to the > > > > AC_VERB_SET_CHANNEL_STREAMID command. It is suspected > that > > > many HDMI > > > > sinks need some time to adapt to the new state. > > > > > > > > The workaround is to avoid changing stream id/format > whenever > > > possible. > > > > Proposed by David. > > > > > > > > Signed-off-by: David Härdeman <david(a)hardeman.nu> > > > > Signed-off-by: Wu Fengguang <fengguang.wu(a)intel.com> > > > > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > > > > > > Yeah, sounds like a similar problem. > > > > > > In general, such a kind of drop is due to the receiver trying to > > > synchronize the stream at the beginning of the playback. So, the > > > patch above essentially keeps the audio widget untouched as long as > > > it's left unchanged. But, after S3, this can't be avoided. Ditto > > > for changing from stereo to 5.1. It's reconfiguring the audio setup > > > bits, thus it has to be reset. That said, the problem is likely > unavoidable in both situations. > > > > > > Of course, my wile guess might be wrong. I'd apply happily any fix > > > patches :) > > > > > > > > > Takashi

1 0

[alsa-devel] [PATCH 0/6] ASoC: fsl_sai: Fix some minor issues
by Nicolin Chen 21 Dec '13

21 Dec '13

This series patches fix some minor issues in the new fsl_sai driver. @Mark Brown I's so busy these days that I couldn't send these, which should have been review comments, in time. So some of them might be too minor to become a meaningful patch but I still sent them to see if you would like to apply. Thank you. Nicolin Chen (6): ASoC: fsl_sai: Keep symmetry for clk_enable() and clk_disable() ASoC: fsl_sai: Use snd_pcm_format_width() ASoC: fsl_sai: Drop useless channels check in hw_params() ASoC: fsl_sai: Drop useless ret in startup() ASoC: fsl_sai: Make dev_err information neater ASoC: fsl_sai: Sort local variable in general way sound/soc/fsl/fsl_sai.c | 71 ++++++++++++++++--------------------------------- 1 file changed, 23 insertions(+), 48 deletions(-) -- 1.8.4

3 8

[alsa-devel] [PATCH] ASoC: fsl-sai: Use snd_soc_dai_init_dma_data()
by Xiubo Li 21 Dec '13

21 Dec '13

Makes the code slightly shorter Signed-off-by: Xiubo Li <Li.Xiubo(a)freescale.com> --- sound/soc/fsl/fsl_sai.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index 50a797e..9c89f97 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -377,8 +377,8 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai) { struct fsl_sai *sai = dev_get_drvdata(cpu_dai->dev); - cpu_dai->playback_dma_data = &sai->dma_params_tx; - cpu_dai->capture_dma_data = &sai->dma_params_rx; + snd_soc_dai_init_dma_data(cpu_dai, &sai->dma_params_tx, + &sai->dma_params_rx); snd_soc_dai_set_drvdata(cpu_dai, sai); -- 1.8.4

2 1

[alsa-devel] [PATCH] ASoC: fsl-sai: Use devm_snd_dmaengine_pcm_register()
by Xiubo Li 21 Dec '13

21 Dec '13

Makes the code slightly shorter Signed-off-by: Xiubo Li <Li.Xiubo(a)freescale.com> --- sound/soc/fsl/fsl_sai.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index 50a797e..39cb9ee 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -454,19 +454,8 @@ static int fsl_sai_probe(struct platform_device *pdev) if (ret) return ret; - ret = snd_dmaengine_pcm_register(&pdev->dev, NULL, + return devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, SND_DMAENGINE_PCM_FLAG_NO_RESIDUE); - if (ret) - return ret; - - return 0; -} - -static int fsl_sai_remove(struct platform_device *pdev) -{ - snd_dmaengine_pcm_unregister(&pdev->dev); - - return 0; } static const struct of_device_id fsl_sai_ids[] = { @@ -476,8 +465,6 @@ static const struct of_device_id fsl_sai_ids[] = { static struct platform_driver fsl_sai_driver = { .probe = fsl_sai_probe, - .remove = fsl_sai_remove, - .driver = { .name = "fsl-sai", .owner = THIS_MODULE, -- 1.8.4

2 1

[alsa-devel] [PATCH] ASoC: fsl-sai: Remove fsl_sai_remove()
by Xiubo Li 21 Dec '13

21 Dec '13

There is no need of this function and makes the code slightly shorter Signed-off-by: Xiubo Li <Li.Xiubo(a)freescale.com> --- sound/soc/fsl/fsl_sai.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index 50a797e..1868ec3 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -385,19 +385,8 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai) return 0; } -static int fsl_sai_dai_remove(struct snd_soc_dai *cpu_dai) -{ - cpu_dai->playback_dma_data = NULL; - cpu_dai->capture_dma_data = NULL; - - snd_soc_dai_set_drvdata(cpu_dai, NULL); - - return 0; -} - static struct snd_soc_dai_driver fsl_sai_dai = { .probe = fsl_sai_dai_probe, - .remove = fsl_sai_dai_remove, .playback = { .channels_min = 1, .channels_max = 2, -- 1.8.4

2 1