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

[alsa-devel] Edirol M-16DX workaround found.
by Rick Kirk 26 Oct '12

26 Oct '12

Hi Everyone. I recently purchased an Edirol M-16DX digital Mixer and am using it with Arch Linux. Alsa version is 1.0.26. After searching the internet and in particular the alsa-devel archives I came across some discussion about this particular device dating back to 2008/09. The device has a built in USB sound card. A patch was added a long time to allow the device to function with the Alsa usb audio driver. Everything worked as expected except for a playback issue that results in a ring modulation like distortion of the audio at fixed intervals (dependant on the frequency in use). At the time those investigating the issue didn't recieve any information back from testers and were unable to resolve the issue and the patch was released with the understanding that device was not fully functional. The proposed fix at the time was to make the device capture audio during playback, even if no recording was being made, thereby using the interal capture clock to sync playback. This was never implemented for various reasons. I have found a workaround for this issue. The device has a digital SPDIF input. With the USB outputs on the device not working it made sense to use my onboard audio card via SPDIF to create a digital path from the PC to the mixer to allow use of PC sound with the mixer. I found upon connecting the SPDIF that the Edirol immediately synced to the external PC clock signal via the coax SPDIF connection. As a result the audio distortion was gone, making the device function as intended. (tested at 48khz though I expect it will work for 44.1khz and 96khz also). The downside to this is that I have lost a stereo input (input 14 is SPDIF or stereo in, not both). I now have 2 ways of using PC based audio with the machine (USB and SPDIF), or none if I stop using the SPDIF connection. This discovery proves that the playback issue is purely a lack of clock sync. I have tested this by setting the internal card to 44.1khz and the edirol to 48khz. The edirol loses external sync and shows on screen that the device switches back to "internal clock". The distortion resurfaces until I force the PC onboard audio back to 48khz, providing a useful external clock source to the edirol via the SPDIF signal. It would appear that the previously proposed fix of capturing while playing back may not be needed and my hope is that the fix might be far simpler to implement. I hope that this information is useful to those previoulsy involved. I would like to as what would be required to enable a clock sync via the USB connection between the PC and mixer? I would be happy to help with beta testing for anyone interested in taking a look at this issue. I have also read that there are other devices that suffer from this same fault so there is potential that any fix may apply to more than this one device. Alternately, if no-one has the time/interest to work directly on the problem then perhaps someone could suggest how the sync might be accomplished and where in the code to start looking? I can then attempt to patch the code myself, though it is likely well beyond my abilities. Thanks for any assistance. Regards, Rick. P.S. I have also requested technical documentation from Roland for this device in the hope they will provide it as the device in now out of production. I am yet to hear anything back.

2 1

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