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

Re: [alsa-devel] Question about move atmel audio part to DT support
by Bo Shen 26 Oct '12

26 Oct '12

Cc: linux-arm-kernel mailing list devicetree-discuss mailing list alsa-devel mailing list linux-sound mailing list On 10/19/2012 14:38, Bo Shen wrote: > Hi Mark Brown, > Now, I am trying to move atmel audio part to DT support. I meet the > following issue. > > Atmel audio part has three platform device: > -> atmel ssc: ssc library (different SOC has different number) > -> atmel ssc dai: dai for audio > -> atmel pcm: for pdc or dma transfer (now only support pdc, dma > support will add soon) > > In DT support kernel, I don't find any similar case. So, if I want to > keep ssc as library, and use dai to register pcm. Then the dts file will > like: > ---<8--- > ssc0: ssc@fffbc000 { > status = "okay"; > }; > > dai0: dai { > compatible = "atmel,atmel-ssc-dai"; > }; > > sound { > compatible = "atmel,at91sam9g20-audio"; > atmel,model = "wm8731 @ sam9g20ek"; > > atmel,audio-routing = > "Ext Spk", "LHPOUT", > "Int Mic", "MICIN"; > > atmel,audio-codec = <&wm8731>; > atmel,dai = <&dai>; > }; > --->8--- > > Would this be OK? > If not, may I add some code for ssc which dedicate for audio into > sound/soc/atmel (using audio-ssc and ssc to distiguish which dedicate > for audio, which used for ssc library)? This will broken the exist code > for audio (only sam9g20-wm8731). > Any suggestion?

2 2

[alsa-devel] ASoC updates for v3.7
by Mark Brown 25 Oct '12

25 Oct '12

The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.7 for you to fetch changes up to 456ba5a7802e58eccb5aa9751b3ab515ef99b9ca: Merge remote-tracking branches 'asoc/fix/ux500' and 'asoc/fix/wm8994' into for-3.7 (2012-10-25 17:36:02 +0100) ---------------------------------------------------------------- ASoC: Fixes for v3.7 A couple of driver fixes, one that improves the interoperability of WM8994 with controllers that are sensitive to extra BCLK cycles and some build break fixes for ux500. ---------------------------------------------------------------- Lee Jones (2): ASoC: Ux500: Dispose of device nodes correctly ASoC: ux500_msp_i2s: Fix devm_* and return code merge error Mark Brown (2): ASoC: wm8994: Only enable extra BCLK cycles when required Merge remote-tracking branches 'asoc/fix/ux500' and 'asoc/fix/wm8994' into for-3.7 sound/soc/codecs/wm8994.c | 18 +++++++++++++++++- sound/soc/codecs/wm8994.h | 1 + sound/soc/ux500/mop500.c | 17 +++++++++++++++++ sound/soc/ux500/ux500_msp_i2s.c | 8 +++----- 4 files changed, 38 insertions(+), 6 deletions(-)

2 1

Re: [alsa-devel] [PATCH] ASoC: supply and micbiases shoud bring "up to" STANDBY
by Mark Brown 25 Oct '12

25 Oct '12

On Wed, Oct 24, 2012 at 02:19:35PM -0700, Shaoming Feng wrote: > /* Supplies and micbiases only bring the > * context up to STANDBY as unless something > * else is active and passing audio they > * generally don't require full power. Signal > * generators are virtual pins and have no > * power impact themselves. > */ > According to the comment, the target bias level shouldn't be higher than STANDBY. > case snd_soc_dapm_clock_supply: > case snd_soc_dapm_micbias: > - if (d->target_bias_level < SND_SOC_BIAS_STANDBY) > + if (d->target_bias_level > SND_SOC_BIAS_STANDBY) > d->target_bias_level = SND_SOC_BIAS_STANDBY; This will do the wrong thing - it'll mean that if we've already found that we need a bias level over _STANDBY we'll pull back to only selecting _STANDBY. The intention here is that we should raise to _STANDBY but this shouldn't distrupt operation of other widgets.

1 0

[alsa-devel] [PATCH] ASoC: wm5102: Correct micbias DAPM supplies
by Charles Keepax 25 Oct '12

25 Oct '12

ARIZONA_MICB1_ENA_SHIFT was used for micbias 2 and 3. This change correctly uses the ARIZONA_MICBX_ENA_SHIFT for each corresponding DAPM supply. This should not have caused any problems as the micbias enables are in the same place in each register. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm5102.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index 1722b58..8714d62 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -344,9 +344,9 @@ SND_SOC_DAPM_PGA_E("IN3R PGA", ARIZONA_INPUT_ENABLES, ARIZONA_IN3R_ENA_SHIFT, SND_SOC_DAPM_SUPPLY("MICBIAS1", ARIZONA_MIC_BIAS_CTRL_1, ARIZONA_MICB1_ENA_SHIFT, 0, NULL, 0), SND_SOC_DAPM_SUPPLY("MICBIAS2", ARIZONA_MIC_BIAS_CTRL_2, - ARIZONA_MICB1_ENA_SHIFT, 0, NULL, 0), + ARIZONA_MICB2_ENA_SHIFT, 0, NULL, 0), SND_SOC_DAPM_SUPPLY("MICBIAS3", ARIZONA_MIC_BIAS_CTRL_3, - ARIZONA_MICB1_ENA_SHIFT, 0, NULL, 0), + ARIZONA_MICB3_ENA_SHIFT, 0, NULL, 0), SND_SOC_DAPM_PGA("Noise Generator", ARIZONA_COMFORT_NOISE_GENERATOR, ARIZONA_NOISE_GEN_ENA_SHIFT, 0, NULL, 0), -- 1.7.2.5

2 1

Re: [alsa-devel] sound/pci/au88x0/au88x0_core.c:2464 vortex_interrupt() warn: if();
by Raymond Yau 25 Oct '12

25 Oct '12

2012-10-23 下午10:35 於 "Takashi Iwai" <tiwai(a)suse.de> 寫道： > > At Tue, 23 Oct 2012 22:16:42 +0800, > Fengguang Wu wrote: > > > > Hi, > > > > smatch warns about a weird "if();" in sound/pci/au88x0/au88x0_core.c > > Any ideas to fix it? > > > > 2461 #ifndef CHIP_AU8810 > > 2462 for (i = 0; i < NR_WT; i++) { > > 2463 if (vortex->dma_wt[i].fifo_status == FIFO_START) { > > ==> 2464 if (vortex_wtdma_bufshift(vortex, i)) ; > > 2465 spin_unlock(&vortex->lock); > > 2466 snd_pcm_period_elapsed(vortex->dma_wt[i]. > > 2467 substream); > > 2468 spin_lock(&vortex->lock); > > 2469 } > > 2470 } > > 2471 #endif > > A quick fix is below, but I'm not 100% sure about it yet. > Let's see. using aplay with VORTEX_PCM_WT , only a very low high frequency signal is heard and after 10 seconds aplay: pcm_write:1702: write error: Input/output error refer to the patent 6167465 the wavetable DMA channels operate slightly different from the non-wavetable DMA channels it seem that the driver still cannot send the increment wavetable pointer signal and the increment count signal , thus fifo controller does not reach the trigger level to request for a dma transfer may need some code to use the sound card's timer interrupt to send increment wavetable pointer signal to provide pitching by perform sample rate conversion on the data through interpolation and looping BTW au88x0 still missing channel map /* pre-allocation of Scatter-Gather buffers */ snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci_dev), 0x10000, 0x10000); +if (VORTEX_PCM_TYPE(pcm) == VORTEX_PCM_ADB) { + err = snd_pcm_add_chmap_ctls(pcm, SNDRV_PCM_STREAM_PLAYBACK, + snd_pcm_std_chmaps, 4, 0, NULL); + if (err < 0) + return err; + } if (VORTEX_PCM_TYPE(pcm) == VORTEX_PCM_SPDIF) { http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=3fc13d6f5b08edee… how about capture stream since test/chmap can open capture stream ? case 's': if (*optarg == 'c' || *optarg == 'C') stream = SND_PCM_STREAM_CAPTURE; else stream = SND_PCM_STREAM_PLAYBACK; break; do VORTEX_PCM_A3D need a mono channel map since device 2 only support mono playback with spatalization to stereo output ? how about the mono channel map of emu10k1 and trident ? > > > thanks, > > Takashi > > --- > diff --git a/sound/pci/au88x0/au88x0_core.c b/sound/pci/au88x0/au88x0_core.c > index 525f881..3fe3dbe 100644 > --- a/sound/pci/au88x0/au88x0_core.c > +++ b/sound/pci/au88x0/au88x0_core.c > @@ -2461,7 +2461,8 @@ static irqreturn_t vortex_interrupt(int irq, void *dev_id) > #ifndef CHIP_AU8810 > for (i = 0; i < NR_WT; i++) { > if (vortex->dma_wt[i].fifo_status == FIFO_START) { > - if (vortex_wtdma_bufshift(vortex, i)) ; > + if (!vortex_wtdma_bufshift(vortex, i)) > + continue; > spin_unlock(&vortex->lock); > snd_pcm_period_elapsed(vortex->dma_wt[i]. > substream);

2 1

[alsa-devel] 191dB Master Playback Volume
by Raymond Yau 25 Oct '12

25 Oct '12

>> Something wild is merged in his system. It has a wrong "Master" >> control without suffix. Also a strange "Pre-Amp" control is found >> there, too. The string doesn't fix in kernel or alsa-lib codes at >> all. > The softvol master volume must have been from a try > with asound.rc config, but it didn't help. > Here is updated alsa-info script without asound.rc: > http://www.alsa-project.org/db/?f=ab5362501881befcdaee94e44278820d43bf92f1 > Meanwhile, in order to test sound, I have tried > severeal live distros including: Ubuntu/Lubuntu 12.10, > Mint, Crunchbang and the result is the same: no > sound or sound that is very low with a lot of noise. > Tried to update alsa to 1.0.25 following this tutorial: > http://ubuntuforums.org/showthread.php?t=1681577 > but that also failed, resulting with "no driver to compile". > Don't know what else to try, and cannot believe that > after more than 7 years with Linux now when I finally > have completely Intel based computer the sound is > making this much trouble. it is not easy to remove the softvol since it is recreated by "alsactl restore" and you still have those softvol controls and a 191dB Master playback volume there must be a bug in alsa lib when you have a stereo softvol master and a mono virtual master playback volume when both softvol without suffix "playback volume" , the capability of pre-amp is volume(global) but master is pvolume Amixer output !!------------- !!-------Mixer controls for card 0 [Intel] Card hw:0 'Intel'/'HDA Intel at 0xfeaf8000 irq 43' Mixer name: 'Realtek ALC887-VD' Components: 'HDA:10ec0887,10438445,00100302' Controls : 43 Simple ctrls : 22 Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [191.00dB] [on] Front Right: Playback 255 [100%] [191.00dB] [on] Simple mixer control 'Pre-Amp',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 5 Front Left: 5 [100%] Front Right: 5 [100%] control.32 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 64' comment.dbmin -6400 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value 64 } control.40 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 255 value.1 255 } control.42 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 5' comment.tlv '0000000100000008fffffe0c000001f4' comment.dbmin -500 comment.dbmax 2000 iface MIXER name Pre-Amp value.0 5 value.1 5 } control.43 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name Master value.0 255 value.1 255

1 0

[alsa-devel] customized IOCTL in pcm platform driver.
by gsantosh＠codeaurora.org 25 Oct '12

25 Oct '12

Hi All, will ALSA framework provide any customized IOCTL functionality in PCM platform driver. in my system there is a requirement to get some information from DSP to user space and I am thinking to add IOCTL's, is there any method to accommodate or how we can address this issue? Regards, Santosh

2 8

Re: [alsa-devel] VOIP xrun problem
by Jamey Drennan 24 Oct '12

24 Oct '12

Maybe I don't quite understand your question but I use RTP (oRTP library) to manage the sending/receiving of the audio streams. On Mon, Oct 22, 2012 at 4:45 PM, Florian Faber <faber(a)faberman.de> wrote: > On 10/22/12 22:40, Jamey Drennan wrote: > > Now in the second phase, events are timed due to specification > > requirements. The same Alsa setup code is used yet xruns (mostly > > underruns) are all over the place. The underruns are periodic and can be > > reduced by increasing the period size and number of periods (this also > > increases the latency obviously and is undersirable) but never removed > > completely. > > > > My question is how to reduce/remove the xruns. > > How do you synchronize the streams? You will either have to synchronize > the media clocks or do some sort of SRC. > > > Flo > -- > Machines can do the work, so people have time to think. > public key B3B9226C x-hkp://wwwkeys.eu.pgp.net >

2 5

Re: [alsa-devel] [PATCH 2/2] ASoC: ux500_msp_i2s: Fix devm_* and return code merge error
by Mark Brown 24 Oct '12

24 Oct '12

On Wed, Oct 24, 2012 at 11:34:00AM +0200, Ulf Hansson wrote: > Acked-by: Ulf Hansson <ulf.hansson(a)linaro.org> > > I assume this shall go into 3.7, right? > > Kind regards > Ulf Hansson You may recall that only yesterday I reminded you not to top post...

1 0

[alsa-devel] [PATCH] ASoC: wm8994: Lower AIFnCLK divisor when dropping to 32kHz
by Mark Brown 24 Oct '12

24 Oct '12

When lowering SYSCLK to 50kHz for accessory detection also lower the AIFnCLK divisor to normalise the clocking configuration within the device. This will not disrupt audio as we cannot support active audio with such a low SYSCLK. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 0932d7a..c16a9a3 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -2443,6 +2443,18 @@ static int wm8994_set_dai_sysclk(struct snd_soc_dai *dai, configure_clock(codec); + /* + * If SYSCLK will be less than 50kHz adjust AIFnCLK dividers + * for detection. + */ + if (max(wm8994->aifclk[0], wm8994->aifclk[1]) < 50000) { + dev_dbg(codec->dev, "Configuring AIFs for 128fs\n"); + snd_soc_update_bits(codec, WM8994_AIF1_RATE, + WM8994_AIF1CLK_RATE_MASK, 0x1); + snd_soc_update_bits(codec, WM8994_AIF2_RATE, + WM8994_AIF2CLK_RATE_MASK, 0x1); + } + return 0; } -- 1.7.10.4

1 0