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

Re: [alsa-devel] Request for Realtek patch - Nvidia MCP51 HDA / ALC883 (10de:026c) Notebook component
by Björn van der Meer 09 May '08

09 May '08

> At Fri, 9 May 2008 15:35:50 +0200, > > Björn van der Meer wrote: > > > At Mon, 5 May 2008 08:43:16 +0200, > > > > > > Björn van der Meer wrote: > > > > Hello Everyone, > > > > > > > > I have above component in my laptop and lack the expertise to add it > > > > to to patch_realtek.c myself. > > > > > > > > I think I have collected all the relevant information if one of the > > > > developers wants to give it a try. > > > > > > > > My Notebook: Medion 98300 (a.k.a. WAM2030) > > > > (Please note: Medion is not an OEM. The board is nVidia based, OEM > > > > thought to be Wistron. Apparently rarely used sound component?) > > > > > > > > Internal speakers > > > > Internal mic - unknown > > > > three jacks: headphone, mic, SPDIF(dual use jack). > > > > Jack Sensing under Windows. > > > > 5.1 surround (sounds like the setup should be supported by > > > > 3stack-6ch-dig) > > > > > > > > lspci: > > > > 00:10.1 Audio device [0403]: nVidia Corporation MCP51 High Definition > > > > Audio [10de:026c] (rev a2) > > > > Subsystem: Wistron Corp. Unknown device [17c0:4079] > > > > Flags: 66MHz, fast devsel, IRQ 20 > > > > Memory at c0000000 (32-bit, non-prefetchable) [size=16K] > > > > Capabilities: [44] Power Management version 2 > > > > Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ > > > > Queue=0/0 Enable- > > > > Capabilities: [6c] HyperTransport: MSI Mapping > > > > > > > > hwinfo: > > > > 22: PCI 10.1: 0403 Audio device > > > > [Created at pci.296] > > > > UDI: /org/freedesktop/Hal/devices/pci_10de_26c > > > > Unique ID: wRyD.X7XJ3rTjrR3 > > > > SysFS ID: /devices/pci0000:00/0000:00:10.1 > > > > SysFS BusID: 0000:00:10.1 > > > > Hardware Class: sound > > > > Model: "Wistron MCP51 High Definition Audio" > > > > Vendor: pci 0x10de "nVidia Corporation" > > > > Device: pci 0x026c "MCP51 High Definition Audio" > > > > SubVendor: pci 0x17c0 "Wistron Corp." > > > > SubDevice: pci 0x4079 > > > > Revision: 0xa2 > > > > Driver: "HDA Intel" > > > > Driver Modules: "snd_hda_intel" > > > > Memory Range: 0xc0000000-0xc0003fff (rw,non-prefetchable) > > > > IRQ: 20 (195693 events) > > > > Module Alias: > > > > "pci:v000010DEd0000026Csv000017C0sd00004079bc04sc03i00" Driver Info > > > > #0: > > > > Driver Status: snd_hda_intel is active > > > > Driver Activation Cmd: "modprobe snd_hda_intel" > > > > Config Status: cfg=new, avail=yes, need=no, active=unknown > > > > > > > > alsa-info.sh output is at http://pastebin.com/f49962c92. > > > > > > > > > > > > > > > > Currently the only thing working is output via the internal speakers. > > > > > > And doesn't this still work with the latest ALSA HG driver? > > > > > > > > > Takashi > > > > Thanks for your answer. Latest HG does not compile on my system, throws > > memalloc.c errors. (Could be me doing something wrong though - out on a > > limp) > > > > CC [M] /home/bvdm/alsa-driver/acore/memalloc.o > > /home/bvdm/alsa-driver/acore/memalloc.c: In function ‘snd_mem_init’: > > /home/bvdm/alsa-driver/acore/memalloc.c:729: error: implicit declaration > > of function ‘proc_create’ > > /home/bvdm/alsa-driver/acore/memalloc.c:730: warning: assignment makes > > pointer from integer without a cast > > make[3]: *** [/home/bvdm/alsa-driver/acore/memalloc.o] Error 1 > > make[2]: *** [/home/bvdm/alsa-driver/acore] Error 2 > > make[1]: *** [_module_/home/bvdm/alsa-driver] Error 2 > > make[1]: Leaving directory `/usr/src/linux-headers-2.6.24-16-generic' > > > > > > > > I see references to similar errors on the list, had to do with processor > > identification? > > > > > > Configure detects this: > > checking for processor type... i586 > > checking for i386 machine type... default > > > > /proc/cpuinfo starts with: > > [...] > > vendor_id : AuthenticAMD > > cpu family : 15 > > model : 72 > > model name : AMD Turion(tm) 64 X2 Mobile Technology TL-50 > > [...] > > It's a problem in alsa-driver build stub. I fixed it right now on HG > tree. > > > I have also just lifted patch_realtek.c from the current hg and compiled > > it in a working tarball (actually labelled alsa-driver-hg20080502.tar > > from the realtek site), which compiles, looks a bit better. > > Gives me: > > - Different set of mixer controls (not 5.1 though) > > OK, I'll need a newer alsa-info.sh with the latest driver. New alsa-info.sh is at http://pastebin.ca/1012744 > > > - headphone output in the strange dual-use SPDIF jack only (headphone > > jack only goes 2/3 of the way in) > > Please elaborate? I don't understand your description. hehe, yes. I didn't believe it either. This laptop has three jacks. - light blue, symbol "headphone", normal 3.5mm jack - pink, symbol "microphone", normal 3.5mm jack - black, symbol line out, normal 3.5mm (that only goes in 2/3 of the way) jack AND SPDIF (yes, now glowing red) Actually. Seeing is believing. www.chronovault.net/static/medion98300jacks.jpg > > - but with jack-sensing working in that jack, with the boxes turning off > > when I insert the headphone into the SPDIF. > This sounds good -- do you mean that you have another headphone jacks? > > > Takashi Thank you very much Just hg'ed again compile runs fine. This is without any "options snd-hda-intel model=XXXX" line in /etc/modprobe.d/alsa-base - I now put my headphone into the black jack and get sound, boxes turn off. - light blue jack is without function now. - mixer option "headphone" is without function. - mixer now has master, headphone,pcm,front,frontmic,line,mic,micboost,digital - only master,pcm and front work, all regulate master volume on SPDIF-used-as-headphone-jack and the internal boxes - dont have a mic right here to try out Should I try options there now? Is /etc/init.d/alsasound stop / start a good way to cycle through options? -- Björn van der Meer bvdm(a)chronovault.net

2 1

[alsa-devel] My issues with the ALSA API
by Lennart Poettering 09 May '08

09 May '08

Heya! A while back I compiled a list of issues I found with the ALSA API while I was hacking PulseAudio. I kept it up to date ever since. It has the title "Why I hate ALSA", but this is merely a catchy title, I am not trying to offend anyone, nor do I think that the ALSA API is particularly bad. Back at FOMS in January this year, I showed this list to James. He acknowledged most of those issues. But I am sure that the other ALSA devs might be interested too: http://pulseaudio.org/wiki/WhyIHateALSA Comments welcome! Thank you, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

4 9

[alsa-devel] Request for Realtek patch - Nvidia MCP51 HDA / ALC883 (10de:026c) Notebook component
by Björn van der Meer 09 May '08

09 May '08

Hello Everyone, I have above component in my laptop and lack the expertise to add it to to patch_realtek.c myself. I think I have collected all the relevant information if one of the developers wants to give it a try. My Notebook: Medion 98300 (a.k.a. WAM2030) (Please note: Medion is not an OEM. The board is nVidia based, OEM thought to be Wistron. Apparently rarely used sound component?) Internal speakers Internal mic - unknown three jacks: headphone, mic, SPDIF(dual use jack). Jack Sensing under Windows. 5.1 surround (sounds like the setup should be supported by 3stack-6ch-dig) lspci: 00:10.1 Audio device [0403]: nVidia Corporation MCP51 High Definition Audio [10de:026c] (rev a2) Subsystem: Wistron Corp. Unknown device [17c0:4079] Flags: 66MHz, fast devsel, IRQ 20 Memory at c0000000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable- Capabilities: [6c] HyperTransport: MSI Mapping hwinfo: 22: PCI 10.1: 0403 Audio device [Created at pci.296] UDI: /org/freedesktop/Hal/devices/pci_10de_26c Unique ID: wRyD.X7XJ3rTjrR3 SysFS ID: /devices/pci0000:00/0000:00:10.1 SysFS BusID: 0000:00:10.1 Hardware Class: sound Model: "Wistron MCP51 High Definition Audio" Vendor: pci 0x10de "nVidia Corporation" Device: pci 0x026c "MCP51 High Definition Audio" SubVendor: pci 0x17c0 "Wistron Corp." SubDevice: pci 0x4079 Revision: 0xa2 Driver: "HDA Intel" Driver Modules: "snd_hda_intel" Memory Range: 0xc0000000-0xc0003fff (rw,non-prefetchable) IRQ: 20 (195693 events) Module Alias: "pci:v000010DEd0000026Csv000017C0sd00004079bc04sc03i00" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Config Status: cfg=new, avail=yes, need=no, active=unknown alsa-info.sh output is at http://pastebin.com/f49962c92. Currently the only thing working is output via the internal speakers. Thank you very much, B. -- Björn van der Meer bvdm(a)chronovault.net

2 3

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