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

Re: [alsa-devel] Problem with aloop
by Benjamin van den Hout 09 May '08

09 May '08

Gustavo da Silva Serra wrote: > I am developing an application that captures sound and send it > through a network, just like a sound server. To test it I am using > kaffeine with alsa output plugin. After some time playing continuously, > or if I keep moving the position slider backward and forward, I get > choppy sound. If I close and reopen the capture stream opened by my > sound server, the sound is restored to good quality. Sometimes I have to > reopen many times before I get a good sound. When I use kaffeine oss > output plugin I don't have this issue. I don't have an audio sound card, > so I don't know if this is an *aloop* issue. > Here are some details: >- RedHat EL 4 kernel 2.6.9.55-ELsmp 64bit >- Alsa 1.0.16 >- Xinelib 1.1.12 Hi all, I'm experiencing the same problem as Gustavo. In my case I have a SIP client calling to another PC and I'm injecting audio with aplay (or amarok, no difference there) into that SIP call. About 8/10 times everything goes well, the other two times the audio that comes out at the other PC sounds really choppy. Both PC's are on the same local network so that is probably not the problem. What I found out is that if I patch aloop-kernel.c in the 'static struct snd_pcm_hardware snd_card_loopback_info' to have ".formats = (SNDRV_PCM_FMTBIT_S8 )," this problem goes away. But then I'm stuck with 8 bit audio. It sounds a bit like the aloop device sometimes doesn't properly synchronise the 16 bit (or 32bit, tried that as well) samples on both PCM devices and things get mis-aligned. I'm quite new to ALSA so please don't laugh too hard if I'm missing something here :) Any input is greatly appreciated! Kind regards, Benjamin van den Hout

2 1

[alsa-devel] [PATCH v2.6.26-rc1] ASoC: Fix TLV320AIC3X mono line output interconnect
by Mark Brown 09 May '08

09 May '08

From: Jarkko Nikula <jarkko.nikula(a)nokia.com> There is no endpoint called MONOLOUT but MONO_LOUT. Signed-off-by: Jarkko Nikula <jarkko.nikula(a)nokia.com> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.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 6e4bc69..957996e 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -553,8 +553,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.5.1

2 2

[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