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

[alsa-devel] [PATCH 4/4] ASoC: enable wm8753 in aspenite
by Haojian Zhuang 02 Apr '10

02 Apr '10

2 3

Re: [alsa-devel] mx27_wm9712.c memory leak
by David Lee 02 Apr '10

02 Apr '10

2010/3/31 David Lee <david.lee.csj(a)gmail.com> > Dear alsaers: > > I am doing a test for imx27 platform with wm9712 as its sound card. When my > programe that used for recording audio is running in background, I use top > command to watch system condition. But the memory used and catchedd is > rising as time past.I check my application programe , I dont think there is > any wrong.So I think there's some wrong in audio drivers. > Pleae check attachment for the driver code and my programe . > > Any suggestion will be greatly appreciate. > > Best regards. > > > david sever of GOD >

1 0

[alsa-devel] alsactl restore: unknown hardware: ymf724f
by Angel Tsankov 02 Apr '10

02 Apr '10

Hello, I run 'alsactl restore' on a machine with 2 sound cards -- a built-in Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio Controller] (rev 03) -- and get the following message: Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600" "0x1073" "0x000d" Hardware is initialized using a guess method As a consequence the volume levels of the Yamaha card do not get restored to the levels stored in /etc/asound.state. The volume levels of the built-in card however are properly restored. The asound.state file has been created by executing 'alsactl store'. The kernel has been built with support for ALSA. I've built and installed the kernel modules for both cards (not the ones in the alsa-driver package but those that come with kernel version 2.6.30.2). Any ideas why alsactl cannot find the hardware it has previously identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on? Regards, Angel Tsankov

4 26

[alsa-devel] Memory corruption in ASoC
by Daniel Mack 01 Apr '10

01 Apr '10

Hi, I've been hunting a serious memory corruption in the ASoC core for some time now and finally managed to figure out where the actual problem lies. We're currently using a 2.6.32.10, on a PXA303 based series of devices (see sound/soc/pxa/raumfeld.c). So here's the demo program, reduced to the max: http://caiaq.de/download/tmp/alsa.c The thread launched to call getifaddrs() every 10ms is actually just there because a) this was the way the bug was originally triggered in our application and b) this seems to be a good way to put the kernel's memory management under fire, so you don't have to wait long for a crash. Important to mention is that the bug is only triggered when snd_pcm_set_params() is called for both streams, and only if more than one device is opened. This sources smash my kernel more or less instantly with a backtrace similar to the one at the end of this mail. You might also end up getting hung tasks, and the kernel detector which complains about them after awhile also points out code somewhere in the netlink area (which is of course innocent, we clearly deal with a memory corruption here). So - look at these simplified sniplets: // called for stream #0 pxa_ssp_hw_params(...) { // sound/soc/pxa/pxa-ssp.c ... cpu_dai->dma_data = ssp_get_dma_params(...) ... } // called for stream #1 pxa_ssp_startup(...) { // sound/soc/pxa/pxa-ssp.c ... if (cpu_dai->dma_data) { kfree(cpu_dai->dma_data); ... } } // called for stream #0 __pxa2xx_pcm_hw_free(...) { // sound/arm/pxa2xx-pcm-lib.c ... if (rtd && rtd->params && rtd->params->drcmr) *rtd->params->drcmr = 0; // <-- BOOM ... } So the first stream (PLAYBACK) already exported its dma_data which is now freed by the code initializing the second stream (CAPTURE). This corrupts all existing users of course, and in this particular case, the cleanup in __pxa2xx_pcm_hw_free() dereferences a pointer which is bogus. What I really don't understand is why this didn't crash a lot earlier for many more users. So how is this supposed to be fixed? Should dma_data become a member of some per-stream instance? I believe that also other platforms than PXA are actually affected - am I right? Daniel [ 42.158232] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 42.166289] pgd = c7f14000 [ 42.168970] [00000008] *pgd=a7eff031, *pte=00000000, *ppte=00000000 [ 42.175187] Internal error: Oops: 17 [#1] [ 42.179163] last sysfs file: /sys/devices/virtual/vc/vcsa1/dev [ 42.184950] Modules linked in: [ 42.187983] CPU: 0 Not tainted (2.6.32.10 #99) [ 42.192769] PC is at netlink_dump_start+0x154/0x190 [ 42.197609] LR is at 0x306874 [ 42.200552] pc : [<c029dc38>] lr : [<00306874>] psr: 20000093 [ 42.200562] sp : c7ecdd10 ip : 00000000 fp : c053c648 [ 42.211954] r10: c7844000 r9 : c7ec8200 r8 : 0000045e [ 42.217141] r7 : c7edc140 r6 : c7ec8600 r5 : 00000000 r4 : 00000000 [ 42.223620] r3 : 20000093 r2 : 20000013 r1 : c79df600 r0 : 0000006c [ 42.230102] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 42.237276] Control: 0000397f Table: a7f14018 DAC: 00000015 [ 42.242979] Process alsa (pid: 1118, stack limit = 0xc7ecc278) [ 42.248769] Stack: (0xc7ecdd10 to 0xc7ece000) [ 42.253099] dd00: c0296b94 c7ec8200 00000006 00000000 [ 42.261227] dd20: c7ec8600 c0298118 00000000 c7ecde40 c7ecdd5c c7ed8a80 c005030c c7ec8200 [ 42.269359] dd40: c7ed8a80 c0298040 c7ecdd7c c7ec8600 00000000 00000038 c053c648 c029ea10 [ 42.277493] dd60: c7ed8a80 00000014 c7ed8a80 c0298030 c7844000 c029e6e0 00000014 7fffffff [ 42.285625] dd80: 00000014 00000000 c7ed8a80 c7ec8600 c7ecdf5c c7672580 c7ecde80 00000000 [ 42.293748] dda0: 00000014 c029efb0 00000000 c005118c 00000000 00000000 0000045e 00000000 [ 42.301872] ddc0: 00000000 00000000 00000000 00000000 00000000 c7ecdf5c 00000014 be1ff9ec [ 42.309997] dde0: c7ecc000 0000000c be1ffa84 c027f730 c0069880 c7ecddf4 00000000 00000001 [ 42.318120] de00: ffffffff 00000000 00000000 00000000 00000000 00000000 c7a10f00 00000000 [ 42.326247] de20: 00000000 00000000 be1ff9ec c7a10f00 c0069880 c7ecde34 c7ecde34 00120000 [ 42.334379] de40: 00000014 be1ff9ec c7ecde80 00001000 c7672580 c0050518 c7ecdd68 c7ecdf5c [ 42.342503] de60: 00000000 be1ffa2c c7672580 be1ffa28 be1ffa44 be1ffa44 0000000c 00000000 [ 42.350628] de80: 0000000c c02802c4 c7672580 00000014 c7672580 c0280420 c7ecddb8 c7ecdf5c [ 42.358751] dea0: 00000000 00000000 c027ea8c 00000000 c7ecdedc 00000014 be1ff9ec c7ecdedc [ 42.366876] dec0: 0000000c c7672580 00000000 c7ecdedc 00000014 c027fa08 c00440c4 00000010 [ 42.375001] dee0: 00000000 00000000 0000000c c02802c4 0000000c c7672580 c7ecdf04 c0280690 [ 42.383124] df00: c7ecdf08 00000010 0000045e 00000000 00000000 c76747d8 c7674780 be1fea1c [ 42.391249] df20: 00000fec c7ecdf4c 00000005 c7ec9f80 c7672580 00000000 c03fd590 c027f3d8 [ 42.399373] df40: c03fd590 c0532ab0 c7e8ad80 00000000 00000000 c047c88f 00000005 c7ecdedc [ 42.407497] df60: 0000000c c7ecdf78 00000001 00000000 00000000 00000000 be1ff9ec 00000000 [ 42.415620] df80: 00000001 00000000 00000000 be1ff9ec 0000000c 0000000c 00000122 c00440c4 [ 42.423746] dfa0: 00000000 c0043f40 be1ff9ec 0000000c 00000005 be1ff9d8 00000014 00000000 [ 42.431870] dfc0: be1ff9ec 0000000c 0000000c 00000122 be1ff9ec 00001000 00000000 be1ffa84 [ 42.439995] dfe0: 00000000 be1ff9c0 4011e8a4 40123848 60000010 00000005 00000000 00000000 [ 42.448139] [<c029dc38>] (netlink_dump_start+0x154/0x190) from [<c0298118>] (rtnetlink_rcv_msg+0xd8/0x220) [ 42.457739] [<c0298118>] (rtnetlink_rcv_msg+0xd8/0x220) from [<c029ea10>] (netlink_rcv_skb+0x4c/0xb0) [ 42.466904] [<c029ea10>] (netlink_rcv_skb+0x4c/0xb0) from [<c0298030>] (rtnetlink_rcv+0x1c/0x2c) [ 42.475640] [<c0298030>] (rtnetlink_rcv+0x1c/0x2c) from [<c029e6e0>] (netlink_unicast+0x22c/0x2d0) [ 42.484550] [<c029e6e0>] (netlink_unicast+0x22c/0x2d0) from [<c029efb0>] (netlink_sendmsg+0x260/0x274) [ 42.493806] [<c029efb0>] (netlink_sendmsg+0x260/0x274) from [<c027f730>] (sock_sendmsg+0xa0/0xc4) [ 42.502630] [<c027f730>] (sock_sendmsg+0xa0/0xc4) from [<c027fa08>] (sys_sendto+0xb0/0xd4) [ 42.510866] [<c027fa08>] (sys_sendto+0xb0/0xd4) from [<c0043f40>] (ret_fast_syscall+0x0/0x28) [ 42.519344] Code: ebfffe2e e10f2000 e3823080 e121f003 (e5943008) [ 42.525679] ---[ end trace 3209e05a50ffc8c1 ]---

5 24

[alsa-devel] line in recording w/ alsa - suggestions for a snd card?
by Lars Schotte 01 Apr '10

01 Apr '10

hi folks, i ve given up on that problems w/ recording because it leads to LQ recordings in the best case. so does anybody have a suggestion for a sound card PCI-internal that works w/ ALSA and records HQ from line-in that can be used for digitalizing? frankly, as long as it would work money isnt important but on the other hand it doesnt need to be 192 kHz one for >100 eur. so as long as the card does record HQ in 44/48 kHz would be perfectly OK and the cheaper, the better. thanks. -- ------------------- Lars Schotte @ romy

3 5

[alsa-devel] CA0106
by Lars Schotte 01 Apr '10

01 Apr '10

hi, Clemens wrote that " The CA0106 is supported, and > used on several cheap Sound Blaster cards, e.g. the SB 5.1 VX " CA0106 is supported, but I looked at the website and there is: http://www.alsa-project.org/main/index.php/Matrix:Vendor-Creative_Labs CA0106 Details [PCI] Digital/Analog input does not work yet. Needs more development work. so ... that seems like line in doesnt work yet, but on the unofficial http://alsa.opensrc.org/index.php/Ca0106 is " Capture from MIC an LINE IN input. " so looks like that already works, but maybe recently. that could be relevant to me as far as not buy a VX when I want to make it work on debian stable w/o changes, but however, I could install the git version or a snapshot. its just not clear all. -- ------------------- Lars Schotte @ romy

1 0

[alsa-devel] C-Media CMI8738-LX noise in recording from line in
by Lars Schotte 01 Apr '10

01 Apr '10

I have this Sweex Sorround sound card PCI and I want to use it for recording / digitalizing / magnetic and other media types through line-in. I have to use that card (or another) because the built-in sound card doesnt work /is broken/. The soundcard has following chipset - C-Media CMI8738-LX. So I try to record from the line in input, which works for listening, so line in input is played good through line out then. I dont know if there is a passthrought or sth. however, when I record it, using audacity, or even alsarecord / it doesnt matter / the sound is reported and also actually is too silent and there is a lot of noise. So with that noise, this card is for digitalizing useless. this soundcard has physically no shared connector with the rear, or bass or whatever. so there are 5 connectors, line in, mic in, front, rear and cent/sub. each for himself. maybe thats the case, that the old ones did have shared one and therefore it breaks the recording or whatever, just a theory. because a few years ago i had an old cmipci and that one worked fine. just to be clear, there is sound, so it records, the problem is that its too silent and there is a lot of noise in it. i write this note because I saw some reports that suggest that it produces _only_ noise in recording. thats not the case here. -- ------------------- Lars Schotte @ romy

4 5

[alsa-devel] start threshold in alsa plugin
by Stefan Schoenleitner 01 Apr '10

01 Apr '10

Hi, in my io-plugin code I would like to know the start threshold value. AFAIK the start threshold is set to a default value that depends on the configured buffer size SND_PCM_IOPLUG_HW_BUFFER_BYTES. In my case the buffer size is 160*2*1 .. 160*2*2 bytes which is 1..2 periods as one period has 160 samples and each sample has 16 bit (2 bytes). * How exactly is the default threshold value derived from the buffer size ? I also tried to get the start threshold value from the PCM: ------------------------------------------------------------------------------ if (snd_pcm_sw_params_malloc(&sw_params)<0) return -1; if ((err=snd_pcm_sw_params_current(plug_info->io.pcm, sw_params))<0) { printf("Unable to determine current swparams: %s\n", snd_strerror(err)); return -err; } if (snd_pcm_sw_params_get_start_threshold(sw_params, &param)<0) return -1; DBG("start threshold: %lu", param); ------------------------------------------------------------------------------ Unfortunately the call to snd_pcm_sw_params_current() fails (i/o error). * Do you know why that call fails ? * Is this the right way to get the start threshold value from a pcm ? I'm calling the above code at the end of the plugin entry function SND_PCM_PLUGIN_DEFINE_FUNC() after all hw constraints (including the buffer size) have been set. Maybe the plugin entry function is just not the right place to retrieve the sw configuration from the PCM as it is too early and the sw config of the pcm has not yet been set up ? * Should I use a callback like sw_params to retrieve the default config ? cheers, Stefan

1 0

[alsa-devel] Regressions: MSI vs HDA-Intel
by Torsten Kaiser 01 Apr '10

01 Apr '10

I have two systems that use the alsa hda-intel driver, both show regressions in relation to MSI. System 1: Athlon(tm) X2 BE-2400 with an AMD RS690/SB600 chipset 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383] (Mainboard is a MSI MS-7368) After upgrading from 2.6.31 to 2.6.33 I get a delay during bootup: [ 1.155925] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1.159143] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 [ 1.232595] firewire_core: created device fw0: GUID 00dc10000129c48f, S400 [ 1.252677] hda_codec: ALC888: BIOS auto-probing. [ 1.259226] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19 [ 1.260293] HDA Intel 0000:01:05.2: irq 27 for MSI/MSI-X [ 1.314712] input: GenPS/2 Genius Mouse as /devices/platform/i8042/serio1/input/input3 [ 4.322508] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 [ 5.332508] hda-intel: No response from codec, disabling MSI: last cmd=0x000f0000 [ 6.342508] hda-intel: Codec #0 probe error; disabling it... [ 7.392508] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0000 [ 7.430464] ALSA device list: [ 7.431549] #0: HDA ATI SB at 0xfe7f4000 irq 16 [ 7.432656] #1: HDA ATI HDMI at 0xfe9e8000 irq 27 2.6.34-rc2 does not boot on this system, something related to the new bootmem allocator, so I can't say if this might already be fixed for 2.6.34. Should the system be blacklisted like the two Asus Athlon X2 boards, or is this some other bug? System 2: Opteron(tm) 2218 with an nVidia MCP55 chipset 00:06.1 Audio device [0403]: nVidia Corporation MCP55 High Definition Audio [10de:0371] (rev a2) (Mainboard is an ASUS KFN5-D SLI) Commit 80c43ed724797627d8f86855248c497a6161a214 disabled MSI for this system, but the MSI mode was working fine for all 2.6.33 versions I used. Should the generic blacklist disable MSI for all Athlon X2 instead of all nNvidia chipsets? If you need more information, please ask, I will try to provide anything you need. Thanks, Torsten

3 7

[alsa-devel] Handling of the DXS controls in the via82xx driver
by Soeren D. Schulze 01 Apr '10

01 Apr '10

Hi everyone, before my latest upgrade to Linux 2.6.32 (yes, sorry, it's Debian), I had four levers in my alsamixer: VIA DXS, VIA DXS 1, VIA DXS 2 and VIA DXS 3. They controlled the hardware mixing when accessing the sound device multiple times. Now they have disappeared. I think I can pretty certainly trace this down to commit 2fb930b53f513cbc4c102d415d2923a8a7091337 to Linux [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=commi…], which "move[s] DXS volume controls to PCM interface". As I'm not an ALSA developer, I don't realize the intended effect of this change, but the actual effect is that I cannot change the DXS volumes any more. mplayer still controls the global PCM volume. Well, in fact, there is one way. While an mplayer is running, I can do: amixer cset numid=47,iface=PCM,name='PCM Playback Volume' 24,24 When restarting mplayer, the volume is reset to 31,31 (maximum). Commit 3d00941371a765779c4e3509214c7e5793cce1fe [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.33.y.git;a=commi…] seems to be responsible for this. The bad thing about it is that 31,31 is a really bad setting for my poorly engineered sound card. It distorts a lot. I suspect that the real *bug* is that mplayer does not use the per-channel DXS controls even though it's supposed to (which seems to be why the DXS controls are called "PCM Playback Volume"). Personally, rather than fixing this bug, I would just revert to the former state. I was always happy with all the DXS levers set to 75%. Thank you Sören

3 6