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

[alsa-devel] [PATCH] ASoC: SAMSUNG: Add SND_SOC_DAIFMT_CONT option for snd_soc_set_fmt()
by 박상수 06 Sep '12

06 Sep '12

SND_SOC_DAIFMT_CONT option is now needed because of below commit: ASoC: Allow DAI formats to be specified in the dai_link Otherwise, s3c_pcm_set_fmt() returns -EINVAL. Signed-off-by: Sangsu Park <sangsu4u.park(a)samsung.com> --- sound/soc/samsung/smdk_wm8994pcm.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/samsung/smdk_wm8994pcm.c b/sound/soc/samsung/smdk_wm8994pcm.c index 77ecba9..cb88cbc 100644 --- a/sound/soc/samsung/smdk_wm8994pcm.c +++ b/sound/soc/samsung/smdk_wm8994pcm.c @@ -77,6 +77,7 @@ static int smdk_wm8994_pcm_hw_params(struct snd_pcm_substream *substream, /* Set the cpu DAI configuration */ ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B + | SND_SOC_DAIFMT_CONT | SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_CBS_CFS); if (ret < 0) -- 1.7.1

3 6

[alsa-devel] radeon multi-channel lpcm
by Pierre Ossman 06 Sep '12

06 Sep '12

Hi, I figured I'd have a go at finishing up support for multi-channel lcpm over HDMI on radeon cards. I read a post from the AMD guys stating that the GPU portions were already in place, and it was the audio pieces that were missing. Unfortunately I was unable to figure out exactly what it is that remains to be done. I poked around in patch_hdmi.c, and concluded that the generic code is what's being used for modern radeon cards. The card exposes two widgets (and output widget and a pin complex). But both widgets indicate through their capability registers that they only support stereo. I don't know enough about HDA to have any clue where to go from here. Should the capability field be ignored for HDMI? Or does it need some coaxing to allow more than stereo? The ELD stuff isn't properly updated from the radeon driver, but the code seems to suggest it is just for hints, and not critical. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by FRA, a Swedish intelligence agency. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.

2 7

Re: [alsa-devel] snd-usb: "delay: estimated 0, actual 352"
by Daniel Mack 06 Sep '12

06 Sep '12

On 06.09.2012 08:53, Markus Trippelsdorf wrote: > On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: >> At Thu, 06 Sep 2012 08:33:30 +0200, >> Daniel Mack wrote: >>> >>> On 06.09.2012 08:02, Markus Trippelsdorf wrote: >>>> On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: >>>>> ---------------------------------------------------------------- >>>>> Sound fixes for 3.6-rc5 >>>>> >>>>> There are nothing scaring, contains only small fixes for HD-audio and >>>>> USB-audio: >>>>> - EPSS regression fix and GPIO fix for HD-audio IDT codecs >>>>> - A series of USB-audio regression fixes that are found since 3.5 kernel >>>>> >>>>> ---------------------------------------------------------------- >>>>> Daniel Mack (4): >>>>> ALSA: snd-usb: Fix URB cancellation at stream start >>>>> ALSA: snd-usb: restore delay information >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> The commit fbcfbf5f above causes the following lines to be printed >>>> whenever I start a new song: >>> >>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this >>> patch (fbcfbf5f) brings back now. >>> >>>> delay: estimated 0, actual 352 >>>> delay: estimated 353, actual 705 >>>> >>>> (44.1 * 8 = 352.8) >>>> >>>> This happens with an USB-DAC that identifies itself as "C-Media USB >>>> Headphone Set". >>> >>> And you didn't you see these lines with 3.4? >> >> Maybe the difference of start condition? >> >> Markus, does the patch below fix anything? > > Unfortunately no. > However reverting the following fixes the problem: > > commit 245baf983cc39524cce39c24d01b276e6e653c9e > Author: Daniel Mack <zonque(a)gmail.com> > Date: Thu Aug 30 18:52:30 2012 +0200 > > ALSA: snd-usb: fix calls to next_packet_size > No, this one certainly fixes a problem and does the right thing by restoring the original code. If you wouldn't state that you didn't see the same effect with 3.4(!), before the refactoring done in 3.5, I would believe the device is simply slightly off in its feedback rate and the tighter delay code complains about it while compensating, just as it did before. Are there any more than these two lines? And is audio working at all? Is it distorted in any way? Pierre-Louis, could you check whether I did the right thing when I ported over your delay bits to the new endpoint logic? Maybe I'm missing something here, but I currently don't see it. Thanks, Daniel

1 0

Re: [alsa-devel] [PATCH 2/4] ARM: OMAP: Split plat/hardware.h, introduce local hardware.h and soc.h for omap2+
by Mark Brown 06 Sep '12

06 Sep '12

On Fri, Aug 31, 2012 at 05:26:22PM -0700, Tony Lindgren wrote: > As the plat and mach includes need to disappear for single zImage work, > we need to remove plat/hardware.h. Acked-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> There's a topic/omap branch in ASoC which you can pull in to help reduce conflicts, or I could merge this there if that's sensible.

2 2

[alsa-devel] [PATCH Resend] ASoC: imx-mc13783: use defines instead of numerical address of register
by Gaëtan Carlier 06 Sep '12

06 Sep '12

Forgot to cc Mark Brown, sorry. This uses already defined name of registers and makes code more readable. Signed-off-by: Gaëtan Carlier <gcembed(a)gmail.com> --- sound/soc/codecs/mc13783.c | 58 +++++++++++++++++++++++-------------------- 1 files changed, 31 insertions(+), 27 deletions(-) diff --git a/sound/soc/codecs/mc13783.c b/sound/soc/codecs/mc13783.c index 8f726c0..bbfa553 100644 --- a/sound/soc/codecs/mc13783.c +++ b/sound/soc/codecs/mc13783.c @@ -426,16 +426,16 @@ static int mc13783_set_tdm_slot_sync(struct snd_soc_dai *dai, } static const struct snd_kcontrol_new mc1l_amp_ctl = - SOC_DAPM_SINGLE("Switch", 38, 7, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_TX, 7, 1, 0); static const struct snd_kcontrol_new mc1r_amp_ctl = - SOC_DAPM_SINGLE("Switch", 38, 5, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_TX, 5, 1, 0); static const struct snd_kcontrol_new mc2_amp_ctl = - SOC_DAPM_SINGLE("Switch", 38, 9, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_TX, 9, 1, 0); static const struct snd_kcontrol_new atx_amp_ctl = - SOC_DAPM_SINGLE("Switch", 38, 11, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_TX, 11, 1, 0); /* Virtual mux. The chip does the input selection automatically @@ -461,22 +461,22 @@ static const struct snd_kcontrol_new right_input_mux = SOC_DAPM_ENUM_VIRT("Route", adcr_enum); static const struct snd_kcontrol_new samp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 3, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 3, 1, 0); static const struct snd_kcontrol_new lamp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 5, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 5, 1, 0); static const struct snd_kcontrol_new hlamp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 10, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 10, 1, 0); static const struct snd_kcontrol_new hramp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 9, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 9, 1, 0); static const struct snd_kcontrol_new llamp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 16, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 16, 1, 0); static const struct snd_kcontrol_new lramp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 15, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 15, 1, 0); static const struct snd_soc_dapm_widget mc13783_dapm_widgets[] = { /* Input */ @@ -487,13 +487,13 @@ static const struct snd_soc_dapm_widget mc13783_dapm_widgets[] = { SND_SOC_DAPM_INPUT("RXINL"), SND_SOC_DAPM_INPUT("TXIN"), - SND_SOC_DAPM_SUPPLY("MC1 Bias", 38, 0, 0, NULL, 0), - SND_SOC_DAPM_SUPPLY("MC2 Bias", 38, 1, 0, NULL, 0), + SND_SOC_DAPM_SUPPLY("MC1 Bias", MC13783_AUDIO_TX, 0, 0, NULL, 0), + SND_SOC_DAPM_SUPPLY("MC2 Bias", MC13783_AUDIO_TX, 1, 0, NULL, 0), - SND_SOC_DAPM_SWITCH("MC1L Amp", 38, 7, 0, &mc1l_amp_ctl), - SND_SOC_DAPM_SWITCH("MC1R Amp", 38, 5, 0, &mc1r_amp_ctl), - SND_SOC_DAPM_SWITCH("MC2 Amp", 38, 9, 0, &mc2_amp_ctl), - SND_SOC_DAPM_SWITCH("TXIN Amp", 38, 11, 0, &atx_amp_ctl), + SND_SOC_DAPM_SWITCH("MC1L Amp", MC13783_AUDIO_TX, 7, 0, &mc1l_amp_ctl), + SND_SOC_DAPM_SWITCH("MC1R Amp", MC13783_AUDIO_TX, 5, 0, &mc1r_amp_ctl), + SND_SOC_DAPM_SWITCH("MC2 Amp", MC13783_AUDIO_TX, 9, 0, &mc2_amp_ctl), + SND_SOC_DAPM_SWITCH("TXIN Amp", MC13783_AUDIO_TX, 11, 0, &atx_amp_ctl), SND_SOC_DAPM_VIRT_MUX("PGA Left Input Mux", SND_SOC_NOPM, 0, 0, &left_input_mux), @@ -503,12 +503,12 @@ static const struct snd_soc_dapm_widget mc13783_dapm_widgets[] = { SND_SOC_DAPM_PGA("PGA Left Input", SND_SOC_NOPM, 0, 0, NULL, 0), SND_SOC_DAPM_PGA("PGA Right Input", SND_SOC_NOPM, 0, 0, NULL, 0), - SND_SOC_DAPM_ADC("ADC", "Capture", 40, 11, 0), - SND_SOC_DAPM_SUPPLY("ADC_Reset", 40, 15, 0, NULL, 0), + SND_SOC_DAPM_ADC("ADC", "Capture", MC13783_AUDIO_CODEC, 11, 0), + SND_SOC_DAPM_SUPPLY("ADC_Reset", MC13783_AUDIO_CODEC, 15, 0, NULL, 0), /* Output */ - SND_SOC_DAPM_SUPPLY("DAC_E", 41, 11, 0, NULL, 0), - SND_SOC_DAPM_SUPPLY("DAC_Reset", 41, 15, 0, NULL, 0), + SND_SOC_DAPM_SUPPLY("DAC_E", MC13783_AUDIO_DAC, 11, 0, NULL, 0), + SND_SOC_DAPM_SUPPLY("DAC_Reset", MC13783_AUDIO_DAC, 15, 0, NULL, 0), SND_SOC_DAPM_OUTPUT("RXOUTL"), SND_SOC_DAPM_OUTPUT("RXOUTR"), SND_SOC_DAPM_OUTPUT("HSL"), @@ -516,14 +516,18 @@ static const struct snd_soc_dapm_widget mc13783_dapm_widgets[] = { SND_SOC_DAPM_OUTPUT("LSP"), SND_SOC_DAPM_OUTPUT("SP"), - SND_SOC_DAPM_SWITCH("Speaker Amp", 36, 3, 0, &samp_ctl), + SND_SOC_DAPM_SWITCH("Speaker Amp", MC13783_AUDIO_RX0, 3, 0, &samp_ctl), SND_SOC_DAPM_SWITCH("Loudspeaker Amp", SND_SOC_NOPM, 0, 0, &lamp_ctl), - SND_SOC_DAPM_SWITCH("Headset Amp Left", 36, 10, 0, &hlamp_ctl), - SND_SOC_DAPM_SWITCH("Headset Amp Right", 36, 9, 0, &hramp_ctl), - SND_SOC_DAPM_SWITCH("Line out Amp Left", 36, 16, 0, &llamp_ctl), - SND_SOC_DAPM_SWITCH("Line out Amp Right", 36, 15, 0, &lramp_ctl), - SND_SOC_DAPM_DAC("DAC", "Playback", 36, 22, 0), - SND_SOC_DAPM_PGA("DAC PGA", 37, 5, 0, NULL, 0), + SND_SOC_DAPM_SWITCH("Headset Amp Left", MC13783_AUDIO_RX0, 10, 0, + &hlamp_ctl), + SND_SOC_DAPM_SWITCH("Headset Amp Right", MC13783_AUDIO_RX0, 9, 0, + &hramp_ctl), + SND_SOC_DAPM_SWITCH("Line out Amp Left", MC13783_AUDIO_RX0, 16, 0, + &llamp_ctl), + SND_SOC_DAPM_SWITCH("Line out Amp Right", MC13783_AUDIO_RX0, 15, 0, + &lramp_ctl), + SND_SOC_DAPM_DAC("DAC", "Playback", MC13783_AUDIO_RX0, 22, 0), + SND_SOC_DAPM_PGA("DAC PGA", MC13783_AUDIO_RX1, 5, 0, NULL, 0), }; static struct snd_soc_dapm_route mc13783_routes[] = { -- 1.7.7.4

2 1

Re: [alsa-devel] (no subject)
by Daniel Mack 06 Sep '12

06 Sep '12

On 06.09.2012 08:02, Markus Trippelsdorf wrote: > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: >> ---------------------------------------------------------------- >> Sound fixes for 3.6-rc5 >> >> There are nothing scaring, contains only small fixes for HD-audio and >> USB-audio: >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs >> - A series of USB-audio regression fixes that are found since 3.5 kernel >> >> ---------------------------------------------------------------- >> Daniel Mack (4): >> ALSA: snd-usb: Fix URB cancellation at stream start >> ALSA: snd-usb: restore delay information > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The commit fbcfbf5f above causes the following lines to be printed > whenever I start a new song: Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this patch (fbcfbf5f) brings back now. > delay: estimated 0, actual 352 > delay: estimated 353, actual 705 > > (44.1 * 8 = 352.8) > > This happens with an USB-DAC that identifies itself as "C-Media USB > Headphone Set". And you didn't you see these lines with 3.4? Daniel

2 1

[alsa-devel] About joining codecs together
by Mike Looijmans 06 Sep '12

06 Sep '12

I have multiple codecs (TLV320AIC3256) connected to the McASP of an OMAP L138. I've adapted the drivers a bit so they work with my 2.6.37 kernel and the custom board (similar to a DA850). Currently, I can only use one codec at a time. The mcasp is set up in the board config, and there it determines which AXR lines are active. Each codec is connected to another line. They run on the same clock lines. Question: - How can I forward information from the codec to the mcasp driver, to inform which AXR channel to enable? There seems to be no information exchange between them. When codec 1 is running, the mcasp driver must record from AXR1, and when codec2 is running, AXR2 and so on. What I ultimately want to do is use two (or more) codecs for multichannel recording, so that I can use two codecs for a 4-channel recording. For the McASP side, this would simply mean enabling both AXR inputs (DAVINCI_MCASP_PDIR_REG) and then starting both codecs. Questions: - How does this work in user space? There are two codecs, which are to be configured independently, but there will be only one audio stream coming out. I was thinking to create a sort of "multiswitch", a codec that by itself doesn't really do anything, but presents itself as a single codec with lots of channels. The actual commands will be delivered to the appropriate "real" codecs, so that you can record from the "switch", which then in turn enables two codecs and sets up the DAI to record both streams. Would that be possible at all? What are the alternatives? Met vriendelijke groet / kind regards, Mike Looijmans TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) - (0)499 - 33.69.79 Telefax: (+31) - (0)499 - 33.69.70 E-mail: mike.looijmans(a)topic.nl Website: www.topic.nl Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen. The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.

1 0

[alsa-devel] [PATCH 1/1] [ASoC] Fix v2: Revert 'ASoC: imx-ssi: Remove mono support'.
by Gaëtan Carlier 06 Sep '12

06 Sep '12

When patch of Javier Martin is applied on linux-next-20120824 the patch failed because comment line is missing. Signed-off-by: Gaëtan Carlier <gcembed(a)gmail.com> Signed-off-by: Javier Martin <javier.martin(a)vista-silicon.com> --- sound/soc/fsl/imx-ssi.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c index 7074ae6..3c520c4 100644 --- a/sound/soc/fsl/imx-ssi.c +++ b/sound/soc/fsl/imx-ssi.c @@ -380,14 +380,13 @@ static int imx_ssi_dai_probe(struct snd_soc_dai *dai) static struct snd_soc_dai_driver imx_ssi_dai = { .probe = imx_ssi_dai_probe, .playback = { - /* The SSI does not support monaural audio. */ - .channels_min = 2, + .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { - .channels_min = 2, + .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S16_LE, -- 1.7.7.4

1 1

[alsa-devel] [PATCH] ASoC: Revert 'ASoC: imx-ssi: Remove mono support'
by Fabio Estevam 06 Sep '12

06 Sep '12

From: Javier Martin <javier.martin(a)vista-silicon.com> Revert 0865a75(ASoC: imx-ssi: Remove mono support). The bug this patch is meant to solve doesn't occur in Visstrim_M10 boards. Furthermore, after applying this patch sound in Visstrim_M10 is played at slower rates. Signed-off-by: Javier Martin <javier.martin(a)vista-silicon.com> --- sound/soc/fsl/imx-ssi.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c index 7074ae6..3c520c4 100644 --- a/sound/soc/fsl/imx-ssi.c +++ b/sound/soc/fsl/imx-ssi.c @@ -380,14 +380,13 @@ static int imx_ssi_dai_probe(struct snd_soc_dai *dai) static struct snd_soc_dai_driver imx_ssi_dai = { .probe = imx_ssi_dai_probe, .playback = { - /* The SSI does not support monaural audio. */ - .channels_min = 2, + .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { - .channels_min = 2, + .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S16_LE, -- 1.7.9.5

2 1

[alsa-devel] [PATCH -next] soc: fix wm0010.c printk format warning
by Randy Dunlap 06 Sep '12

06 Sep '12

From: Randy Dunlap <rdunlap(a)xenotime.net> Fix printk format warning: sound/soc/codecs/wm0010.c:411:2: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' Signed-off-by: Randy Dunlap <rdunlap(a)xenotime.net> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: alsa-devel(a)alsa-project.org --- sound/soc/codecs/wm0010.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20120905.orig/sound/soc/codecs/wm0010.c +++ linux-next-20120905/sound/soc/codecs/wm0010.c @@ -408,7 +408,7 @@ static int wm0010_boot(struct snd_soc_co wm0010->state = WM0010_BOOTROM; spin_unlock_irqrestore(&wm0010->irq_lock, flags); - dev_dbg(codec->dev, "Downloading %d byte stage 2 loader\n", fw->size); + dev_dbg(codec->dev, "Downloading %zu byte stage 2 loader\n", fw->size); /* Copy to local buffer first as vmalloc causes problems for dma */ img = kzalloc(fw->size, GFP_KERNEL);

2 3