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

[alsa-devel] [PATCH 2.6.26-rc1] ASoC: Fix TLV320AIC3X mono line output interconnect
by Jarkko Nikula 09 May '08

09 May '08

There is no endpoint called MONOLOUT but MONO_LOUT. Signed-off-by: Jarkko Nikula <jarkko.nikula(a)nokia.com> --- sound/soc/codecs/tlv320aic3x.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index 630684f..09b1661 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -539,8 +539,8 @@ static const char *intercon[][3] = { {"HPRCOM", NULL, "Right HP Com"}, /* Mono Output */ - {"MONOLOUT", NULL, "Mono Out"}, - {"MONOLOUT", NULL, "Mono Out"}, + {"MONO_LOUT", NULL, "Mono Out"}, + {"MONO_LOUT", NULL, "Mono Out"}, /* Left Input */ {"Left Line1L Mux", "single-ended", "LINE1L"}, -- 1.5.4.4

2 1

[alsa-devel] Patch - ESI Maya44 driver
by Rainer Zimmermann 09 May '08

09 May '08

Hi Takashi, here's the maya44 patch. This is a patch against the current alsa-kernel tree. I did add 2 definitions to ice1712.h (snd_ice1724_get_route_val and snd_ice1724_put_route_val), which allowed me to move some of the maya44 specific code to maya44.c . There are still a few maya44 special cases in ice1724.c, because maya44 uses the "con" channel and routing switches differently. This is not really clean style I think, but I would suggest sorting this out later, as it would again require larger changes to ice1724.c and testing with other hardware. Hope everything is ok with you, for now. This patch does *not* limit the sampling rate to 96kHz for capture, as discussed before. best regards, -Rainer -- Lightshed IT Services Löfflerstr. 27, 22765 Hamburg, Germany * mail(a)lightshed.de * www.lightshed.de

3 6

[alsa-devel] [PATCH] soc - fsl_ssi.c fix "BUG: scheduling while atomic"
by Mark Brown 09 May '08

09 May '08

From: Anton Vorontsov <avorontsov(a)ru.mvista.com> This patch fixes following bug caught with PREEMPT enabled: root@b1:~# cat /dev/dsp > /dev/null BUG: scheduling while atomic: cat/965/0x00000003 Call Trace: [df165ce0] [c0008e84] show_stack+0x4c/0x1ac (unreliable) [df165d20] [c001c18c] __schedule_bug+0x64/0x78 [df165d30] [c02b3344] schedule+0x2d8/0x334 [df165d70] [c02b3674] schedule_timeout+0x64/0xe4 [df165db0] [c002c05c] msleep+0x1c/0x34 [df165dc0] [c01f2fe0] fsl_ssi_trigger+0x130/0x144 [df165dd0] [c01ece54] soc_pcm_trigger+0x94/0xb8 [df165df0] [c01da764] snd_pcm_do_start+0x48/0x60 [df165e00] [c01da630] snd_pcm_action_single+0x4c/0xb4 [df165e20] [c01e0f50] snd_pcm_lib_read1+0x2a0/0x2d4 [df165e70] [c01ec274] snd_pcm_oss_read3+0xf0/0x13c [df165eb0] [c01ec2e4] snd_pcm_oss_read2+0x24/0x4c [df165ec0] [c01ec4ac] snd_pcm_oss_read+0x1a0/0x1f0 [df165ef0] [c0076478] vfs_read+0xb4/0x108 [df165f10] [c00768cc] sys_read+0x4c/0x90 [df165f40] [c00117a4] ret_from_syscall+0x0/0x38 Acked-by: Timur Tabi <timur(a)freescale.com> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/fsl/fsl_ssi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index b2a11b0..f588545 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -416,7 +416,7 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd) * to put data into its FIFO. Without it, ALSA starts * to complain about overruns. */ - msleep(1); + mdelay(1); } break; -- 1.5.5.1

2 1

[alsa-devel] [PATCH] emux midi synthesizer doesn't honor SOFT_PEDAL-release event
by maximilian attems 09 May '08

09 May '08

When the hardware wavetable synthesizer of an Creative SB Audigy or SB Live! card (with emu10k chip) receives the MIDI SOFT_PEADAL-press event (?? 67 127) the appropriate voice is attenuted. Unfortunately when the pedal is released (event ?? 67 0) the voice does not get it's original volume again. Boolean MIDI controls should interpret 0..63 as false and 64..127 as true. Thanks to Clemens Ladisch for review and correction. Original patch from "Uwe KrÃ#ger" <uwe_debbug(a)arcor.de> Submitted to http://bugs.debian.org/474312 Signed-off-by: maximilian attems <max(a)stro.at> Cc: uwe_debbug(a)arcor.de Cc: Clemens Ladisch <clemens(a)ladisch.de> --- sound/synth/emux/emux_synth.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/sound/synth/emux/emux_synth.c b/sound/synth/emux/emux_synth.c index 478369b..b343818 100644 --- a/sound/synth/emux/emux_synth.c +++ b/sound/synth/emux/emux_synth.c @@ -341,8 +341,12 @@ snd_emux_control(void *p, int type, struct snd_midi_channel *chan) case MIDI_CTL_SOFT_PEDAL: #ifdef SNDRV_EMUX_USE_RAW_EFFECT /* FIXME: this is an emulation */ - snd_emux_send_effect(port, chan, EMUX_FX_CUTOFF, -160, + if (chan->control[type] >= 64) + snd_emux_send_effect(port, chan, EMUX_FX_CUTOFF, -160, EMUX_FX_FLAG_ADD); + else + snd_emux_send_effect(port, chan, EMUX_FX_CUTOFF, 0, + EMUX_FX_FLAG_OFF); #endif break; -- 1.5.5.1

2 1

[alsa-devel] [PATCH] emux midi synthesizer doesn't honor SOFT_PEDAL-release event
by maximilian attems 09 May '08

09 May '08

When the hardware wavetable synthesizer of an Creative SB Audigy or SB Live! card (with emu10k chip) receives the MIDI SOFT_PEADAL-press event (?? 67 127) the appropriate voice is attenuted. Unfortunately when the pedal is released (event ?? 67 0) the voice does not get it's original volume again. The attached patch fixes this problem by analysing the value (0 or 127) of the midi control event and resetting the effect register in case of a release event. I'm not 100% sure if the code to reset the register is correct but at least it works. Original patch from "Uwe KrÃ#ger" <uwe_debbug(a)arcor.de> Submitted to http://bugs.debian.org/474312 Cc: uwe_debbug(a)arcor.de Signed-off-by: maximilian attems <max(a)stro.at> --- sound/synth/emux/emux_synth.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/sound/synth/emux/emux_synth.c b/sound/synth/emux/emux_synth.c index 478369b..f81e081 100644 --- a/sound/synth/emux/emux_synth.c +++ b/sound/synth/emux/emux_synth.c @@ -341,8 +341,12 @@ snd_emux_control(void *p, int type, struct snd_midi_channel *chan) case MIDI_CTL_SOFT_PEDAL: #ifdef SNDRV_EMUX_USE_RAW_EFFECT /* FIXME: this is an emulation */ - snd_emux_send_effect(port, chan, EMUX_FX_CUTOFF, -160, + if (chan->control[type]) + snd_emux_send_effect(port, chan, EMUX_FX_CUTOFF, -160, EMUX_FX_FLAG_ADD); + else + snd_emux_send_effect(port, chan, EMUX_FX_CUTOFF, 0, + EMUX_FX_FLAG_OFF); #endif break; -- 1.5.5.1

2 1

[alsa-devel] [patch] snd-pcsp: relax dependancy on CONFIG_INPUT
by Stas Sergeev 09 May '08

09 May '08

Hello. The attached patch makes an input driver part of snd-pcsp optional. Would it be possible to apply that?

2 6

[alsa-devel] [PATCH] [ALSA] soc - fsl_ssi.c fix "BUG: scheduling while atomic"
by Anton Vorontsov 08 May '08

08 May '08

This patch fixes following bug caught with PREEMPT enabled: root@b1:~# cat /dev/dsp > /dev/null BUG: scheduling while atomic: cat/965/0x00000003 Call Trace: [df165ce0] [c0008e84] show_stack+0x4c/0x1ac (unreliable) [df165d20] [c001c18c] __schedule_bug+0x64/0x78 [df165d30] [c02b3344] schedule+0x2d8/0x334 [df165d70] [c02b3674] schedule_timeout+0x64/0xe4 [df165db0] [c002c05c] msleep+0x1c/0x34 [df165dc0] [c01f2fe0] fsl_ssi_trigger+0x130/0x144 [df165dd0] [c01ece54] soc_pcm_trigger+0x94/0xb8 [df165df0] [c01da764] snd_pcm_do_start+0x48/0x60 [df165e00] [c01da630] snd_pcm_action_single+0x4c/0xb4 [df165e20] [c01e0f50] snd_pcm_lib_read1+0x2a0/0x2d4 [df165e70] [c01ec274] snd_pcm_oss_read3+0xf0/0x13c [df165eb0] [c01ec2e4] snd_pcm_oss_read2+0x24/0x4c [df165ec0] [c01ec4ac] snd_pcm_oss_read+0x1a0/0x1f0 [df165ef0] [c0076478] vfs_read+0xb4/0x108 [df165f10] [c00768cc] sys_read+0x4c/0x90 [df165f40] [c00117a4] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe9a8d4 LR = 0x10002b24 We must not sleep with irqs disabled, so replace msleep with mdelay. Signed-off-by: Anton Vorontsov <avorontsov(a)ru.mvista.com> --- sound/soc/fsl/fsl_ssi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index b2a11b0..f588545 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -416,7 +416,7 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd) * to put data into its FIFO. Without it, ALSA starts * to complain about overruns. */ - msleep(1); + mdelay(1); } break; -- 1.5.5.1

2 3

[alsa-devel] softvol plugin question
by Will Wagner 08 May '08

08 May '08

Hi, I have successfully set up alsa for my custom hardware and am using sofvol plugin to do volume control as my hardware does not support it. The problem I am having is that the softvol control does not appear to amixer until I have first used the softvol plugin with aplay. Is there a simple way of 'loading' the softvol plugin at startup so that the control gets created immediately? Thanks, Will. -- ------------------------------------------------------------------------ Will Wagner will_wagner(a)carallon.com Senior Project Engineer Office Tel: +44 (0)20 7371 2032 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ------------------------------------------------------------------------

3 3

[alsa-devel] ALSA vs. non coherent DMA
by Benjamin Herrenschmidt 08 May '08

08 May '08

Hi Takashi ! I'm bringing up an old thread as I'm just discovering that the problem still hasn't been fixed. There seem to be a few issues with ALSA current usage of mmap vs. non cache coherent architecture, such as embedded PowerPC's. I can see at least two with a quick look to pcm-native.c, one I don't understand and one I think I do: - The control/status mapping. Can you elaborate a bit on what this is actually doing and why it shouldn't be done on "non coherent" architectures ? Currently this -is- done on all powerpc's, whether they are coherent or not and I want to understand what the underlying issue is. - The mmap of DMA pages. Here, the problem appears two fold: * Use of virt_to_page() on virtual addresses returned by dma_alloc_coherent(). * No using the appropriate page protection for a DMA coherent mapping to userspace. It seems like you have solved that in part with implementing a generic dma_mmap_coherent() in the past that for some reason you never merged upstream (I can track that to about 2 years ago). Is there a reason ? I think we need to at least apply a band-aid today as it's becoming a nasty issue for several non-coherent powerpc platforms. It could be in the form of implementing dma_mmap_coherent() and changing Alsa to use it with the appropriate ifdef, or just adding an ifdef CONFIG_PPC with the right code in there for now until a better solution is found. It should be trivial though. Getting the PFN from the DMA address is easy if we have the dma handle and the virtual address, though that -is- definitely platform specific. I can implement a function for that if you need. As for the pgprot, we can come up with something like pgprot_mmap_dma(). Either that or I can fold it all in a powerpc wide implementation of a dma_mmap_coherent() like we envisioned initially. Let me know what approach is preferred here and I'll come up with patches ASAP. As far as I'm concerned, this is a bug and thus must be fixed now for .26 and possibly backported to stable even if we can come up with a non invasive solution). I'm annoyed because it represents a trivial amount of code, this problem should have been fixed a long time ago. Cheers, Ben.

4 5

[alsa-devel] [PATCH] snd_usb_caiaq: add support for "Session I/O" interface
by Daniel Mack 08 May '08

08 May '08

Hi, this patch adds support for "Session I/O". As it certainly won't break anything it could still go for 2.6.26, right? Thanks, Daniel

2 2