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

Re: [alsa-devel] [patch] i2c: cleanup: change parameter to pointer
by Takashi Iwai 04 Apr '10

04 Apr '10

At Fri, 2 Apr 2010 14:29:23 +0300, Dan Carpenter wrote: > > We actually pass an array of 7 chars not 5. > This silences a smatch warning. > > Signed-off-by: Dan Carpenter <error27(a)gmail.com> Thanks. I applied together with the fx in the declaration part in include/sound/ak4113.h. Takashi > --- > Compile tested only. :/ > > diff --git a/sound/i2c/other/ak4113.c b/sound/i2c/other/ak4113.c > index fff62cc..971a84a 100644 > --- a/sound/i2c/other/ak4113.c > +++ b/sound/i2c/other/ak4113.c > @@ -70,7 +70,7 @@ static int snd_ak4113_dev_free(struct snd_device *device) > } > > int snd_ak4113_create(struct snd_card *card, ak4113_read_t *read, > - ak4113_write_t *write, const unsigned char pgm[5], > + ak4113_write_t *write, const unsigned char *pgm, > void *private_data, struct ak4113 **r_ak4113) > { > struct ak4113 *chip; >

1 0

[alsa-devel] [PATCH - powermac] Add debug log
by Risto Suominen 04 Apr '10

04 Apr '10

From: Risto Suominen <Risto.Suominen(a)gmail.com> Add some debug log in tumbler.c. Signed-off-by: Risto Suominen <Risto.Suominen(a)gmail.com> --- Kernel version 2.6.32.9 (probably any 2.6), ALSA 1.0.22.1. This patch is available here, too: http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p16d.diff It has no effect, unless one changes '#undef DEBUG' to '#define DEBUG' in the beginning of the file (and possibly in tumbler.patch, too). --- a/alsa-kernel/ppc/tumbler.c-p15 2010-03-16 19:59:01.000000000 +0200 +++ b/alsa-kernel/ppc/tumbler.c 2010-03-23 21:34:46.000000000 +0200 @@ -246,6 +246,7 @@ static int tumbler_set_master_volume(str snd_printk(KERN_ERR "failed to set volume \n"); return -EINVAL; } + DBG("(I) succeeded to set volume (%u, %u)\n", left_vol, right_vol); return 0; } @@ -356,6 +357,7 @@ static int tumbler_set_drc(struct pmac_t snd_printk(KERN_ERR "failed to set DRC\n"); return -EINVAL; } + DBG("(I) succeeded to set DRC (%u, %u)\n", val[0], val[1]); return 0; } @@ -392,6 +394,7 @@ static int tumbler_set_drc(struct pmac_t snd_printk(KERN_ERR "failed to set DRC\n"); return -EINVAL; } + DBG("(I) succeeded to set DRC (%u, %u)\n", val[0], val[1]); return 0; }

1 0

[alsa-devel] [PATCH - powermac] Lineout detection on G4 DA
by Risto Suominen 04 Apr '10

04 Apr '10

From: Risto Suominen <Risto.Suominen(a)gmail.com> Lineout (Pro Speaker) detection on PowerMac G4 Digital Audio (Tumbler). Signed-off-by: Risto Suominen <Risto.Suominen(a)gmail.com> --- Kernel version 2.6.32.9 (probably any 2.6), ALSA 1.0.22.1. The patch is available here, too: http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p16.diff This has not been tested. Hopefully someone with that kind of machine and those speakers can do it. --- a/alsa-kernel/ppc/tumbler.c-p15 2010-03-16 19:59:01.000000000 +0200 +++ b/alsa-kernel/ppc/tumbler.c 2010-03-23 21:42:03.000000000 +0200 @@ -1137,7 +1141,8 @@ static long tumbler_find_device(const ch gp->inactive_val = (*base) ? 0x4 : 0x5; } else { const u32 *prop = NULL; - gp->active_state = IS_G4DA && !strcmp(device, "keywest-gpio15"); + gp->active_state = IS_G4DA + && !strncmp(device, "keywest-gpio1", 13); gp->active_val = 0x4; gp->inactive_val = 0x5; /* Here are some crude hacks to extract the GPIO polarity and @@ -1315,6 +1320,9 @@ static int __devinit tumbler_init(struct if (irq <= NO_IRQ) irq = tumbler_find_device("line-output-detect", NULL, &mix->line_detect, 1); + if (IS_G4DA && irq <= NO_IRQ) + irq = tumbler_find_device("keywest-gpio16", + NULL, &mix->line_detect, 1); mix->lineout_irq = irq; tumbler_reset_audio(chip);

1 0

[alsa-devel] [RFC][PATCH] ASoC: OMAP: Fix capture pointer handling for OMAP1510 to work correctly with recent ALSA PCM code
by Janusz Krzysztofik 02 Apr '10

02 Apr '10

With recent (2.6.34) chnages in PCM handling, capture stopped working on my OMAP1510 based Amstrad Delta videophone. Using 2.6.34-rc2, I was able to correct the problem in 3 different ways: 1. reverting commit 7b3a177b0d4f92b3431b8dca777313a07533a710, 2. enabling additional jiffies check with echo 4 >/proc/asound/card0/pcm0c0/xrun_debug 3. applying the patch below. Since I wasn't able to reproduce the problem on my i686 PC, I guess the problem is probably machine specific. The patch reuses the method for software emulation of missing hardware pointer, already implemented for playback on OMAP1510. It's possible that event if a hardware pointer is available for capture on this machine, its behaviour may be not compatible with what upper layer expects. If you think the problem may be more general and should be solved differently, on a higher level, I can try to work more on it if you give me a hint. If the patch gets accepted, I suggest it goes as a fix in the current release cycle. Created and tested against linux-2.6.34-rc2. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- git/sound/soc/omap/omap-pcm.c.orig 2010-03-25 16:00:13.000000000 +0100 +++ git/sound/soc/omap/omap-pcm.c 2010-03-28 05:16:42.000000000 +0200 @@ -60,12 +60,11 @@ static void omap_pcm_dma_irq(int ch, u16 struct omap_runtime_data *prtd = runtime->private_data; unsigned long flags; - if ((cpu_is_omap1510()) && - (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)) { + if ((cpu_is_omap1510())) { /* * OMAP1510 doesn't fully support DMA progress counter * and there is no software emulation implemented yet, - * so have to maintain our own playback progress counter + * so have to maintain our own progress counters * that can be used by omap_pcm_pointer() instead. */ spin_lock_irqsave(&prtd->lock, flags); @@ -189,8 +188,7 @@ static int omap_pcm_prepare(struct snd_p dma_params.frame_count = runtime->periods; omap_set_dma_params(prtd->dma_ch, &dma_params); - if ((cpu_is_omap1510()) && - (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)) + if ((cpu_is_omap1510())) omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ | OMAP_DMA_LAST_IRQ | OMAP_DMA_BLOCK_IRQ); else @@ -248,14 +246,15 @@ static snd_pcm_uframes_t omap_pcm_pointe dma_addr_t ptr; snd_pcm_uframes_t offset; - if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { + if (cpu_is_omap1510()) { + offset = prtd->period_index * runtime->period_size; + } else if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { ptr = omap_get_dma_dst_pos(prtd->dma_ch); offset = bytes_to_frames(runtime, ptr - runtime->dma_addr); - } else if (!(cpu_is_omap1510())) { + } else { ptr = omap_get_dma_src_pos(prtd->dma_ch); offset = bytes_to_frames(runtime, ptr - runtime->dma_addr); - } else - offset = prtd->period_index * runtime->period_size; + } if (offset >= runtime->buffer_size) offset = 0;

3 8

[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