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

[alsa-devel] [PATCH 1/4] ASoC: DaVinci: remove requirement that dma_params is 1st in structure
by Troy Kisky 13 Jul '10

13 Jul '10

Remove requirement that dma_params is 1st in the structures davinci_audio_dev and davinci_mcbsp_dev. Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> --- sound/soc/davinci/davinci-i2s.c | 6 +----- sound/soc/davinci/davinci-mcasp.c | 1 + sound/soc/davinci/davinci-mcasp.h | 5 ----- sound/soc/davinci/davinci-pcm.c | 7 ++++--- 4 files changed, 6 insertions(+), 13 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index 4ae7070..9e69a4e 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -98,11 +98,6 @@ enum { }; struct davinci_mcbsp_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; #define MOD_DSP_A 0 @@ -547,6 +542,7 @@ static int davinci_i2s_probe(struct platform_device *pdev) dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = res->start; davinci_i2s_dai.private_data = dev; + davinci_i2s_dai.dma_data = dev->dma_params; ret = snd_soc_register_dai(&davinci_i2s_dai); if (ret != 0) goto err_free_mem; diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 5d1f98a..5023915 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -907,6 +907,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) dma_data->channel = res->start; davinci_mcasp_dai[pdata->op_mode].private_data = dev; + davinci_mcasp_dai[pdata->op_mode].dma_data = dev->dma_params; davinci_mcasp_dai[pdata->op_mode].dev = &pdev->dev; ret = snd_soc_register_dai(&davinci_mcasp_dai[pdata->op_mode]); diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/davinci/davinci-mcasp.h index 9d179cc..582c924 100644 --- a/sound/soc/davinci/davinci-mcasp.h +++ b/sound/soc/davinci/davinci-mcasp.h @@ -39,11 +39,6 @@ enum { }; struct davinci_audio_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; int sample_rate; diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index c73a915..c2c2e85 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -238,10 +238,11 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream) struct davinci_runtime_data *prtd; int ret = 0; struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->private_data; - struct davinci_pcm_dma_params *params = &pa[substream->stream]; - if (!params) + struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->dma_data; + struct davinci_pcm_dma_params *params; + if (!pa) return -ENODEV; + params = &pa[substream->stream]; snd_soc_set_runtime_hwparams(substream, &davinci_pcm_hardware); /* ensure that buffer size is a multiple of period size */ -- 1.5.6.3

3 5

[alsa-devel] wrong decibel data?
by Nicolo' Chieffo 01 Jul '10

01 Jul '10

Hello, I have a laptop with an intel hda audio chipset (STAC92xx) My problem is that when I put pulseaudio volume to 14% (or less) I can't hear any audio coming from speakers or headphones: in fact the alsamixer volume is set to 0% I already filed a bug to pulseaudio [1] in which the developers say that this is a common problem which is usually caused by the ALSA audio driver which reports a wrong decibel value. [1] http://pulseaudio.org/ticket/580

9 95

[alsa-devel] Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII
by Lennart Poettering 25 Jun '10

25 Jun '10

Heya, a while back I wrote a little tool "dbmeasure" which can be used to determine dB attenuation data for alsa mixer controls. I have now extended this little dB tools suite to include a tiny tool "dbverify" that can be used to verify the correctness of existing dB data exposed by the drivers. It should be relatively easy to use that tool, suitable even for non-guru folks who want to debug the dB information from alsa. http://git.0pointer.de/?p=dbmeasure.git git://git.0pointer.de/dbmeasure.git Just run "make" in a git checkout and then try: $ ./dbverify Aureon51MkII Master 30 200 That will verify the dB data of the "Master" control of the sound card that goes by the id "Aureon51MkII". It will compare the discrete volume steps 30 and 200: first it will play a full amplitude sine wave at mixer volume step 30, and then will change to mixer volume step 200, but attenuate the sine wave in software compensating for the volume change. So once you hear the sine wave attenuated by the hw, and once by the software. If the card's dB data is correct both sines should have the same volume. Now, playing around with this, I could verify what I already mentioned to Jarsolav elsewhere earlier: it seems that particularly USB cards seem to expose invalid dB data (at least all mine do). For example, for the above mentioned Aureon 5.1 it's really *way* off -- if you posess that card just run the line above, and listen to the difference. It's really bad. OTOH the dB data of the HDA cards I own is pretty accurate as it seems, at least I was unable to decide just by listening which sine wave was attenuated by sw, and which by hw. Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards, or if these cards are just crappy and include invalid data? In which case I wonder what we could do about that? The Aureon's dB range already looks suspicous, since both the max and the min dB value are < 0 (-47.69 to -1.97), so maybe we could add some heuristics to filter out data that already looks suspicous? Invalid dB data from the driver is a real problem for the "flat volume" logic in PA. We basically allow each app to control the full hw volume range individually, and then set the hw volume to the max of what all apps wanted and attenuate the other streams accordingly. On the Aureon this doesn't work at all, since the attenuation of the streams is miscalculated due to the invalid dB data. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

8 93

[alsa-devel] no audio output with TYAN S7025 motherboard and Realtek ALC262
by Bryan Green 20 Jun '10

20 Jun '10

Hi, I have several systems with a TYAN S7025 motherboard and Realtek ALC262 chipset. I have not been able to produce any audio output. Well, that is except for one of the systems: after a variety of tweeks and tests, I got sound working on one system, but I do not know what change enabled sound to start working, and I have not been able to reproduce the effect on the other systems. I have tested with kernels up to 2.6.33, and with ALSA version 1.0.22.1. For a non-working system, 'alsaconf' gives the following output: Unknown hardware: "HDA-Intel" "Realtek ALC262" "HDA:10ec0262,10ec0262,00100202" "0x8086" "0x3a3e" And dmesg gives the following: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 HDA Intel 0000:00:1b.0: irq 89 for MSI/MSI-X HDA Intel 0000:00:1b.0: setting latency timer to 64 hda_codec: ALC262: BIOS auto-probing. autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) hp_outs=0 (0x0/0x0/0x0/0x0/0x0) mono: mono_out=0x0 dig-out=0x1e/0x0 inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0, cd=0x1c, aux=0x0 dig-in=0x1f realtek: No valid SSID, checking pincfg 0x411111f0 for NID 0x1d realtek: Enable default setup for auto mode as fallback input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input8 For the working system, the dmesg output is the same except for two lines: autoconfig: line_outs=1 (0x1b/0x0/0x0/0x0/0x0) inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0, cd=0x1c, aux=0x14 Is there a method for tweaking these values on the non-working system to match the working system, to see if that works? I've uploaded the alsa-info output from a non-working system here: http://www.alsa-project.org/db/?f=91057bfc12790688f1d257743e53d5d0ec2ce1e2 I've uploaded the alsa-info output from the working system here: http://www.alsa-project.org/db/?f=198420f14cd0062713636408640636e6d474cf94 Thanks, -bryan

3 5

[alsa-devel] 2.6.34-rc: sound hungs (ice1724)
by Alexander Beregalov 06 Jun '10

06 Jun '10

Hi Takashi Could you please help me how to debug an issue. Sometimes soung hungs, it happens few days (up to a week) after boot. I have no idea how to reproduce it or how to debug it. That's why it is very hard to bisect, I have not tried, the better way should exist. The problem appeared somewhere after 2.6.33. Card is M-Audio Revo 5.1 (1412:1724). After it hungs ALSA continues to play last sound frame forever. When I try to play something else playing frame changes. Only reboot heals it. rmmod hungs at INFO: task rmmod:30356 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. rmmod D db281e7c 0 30356 2345 0x00000004 db281e8c 00000086 00000002 db281e7c cc2d7b90 00000000 c14e8b80 09c3638a c10252a0 00000001 c14e2000 c14e2000 c14e8b80 c14e8b80 cc2d7a00 db281e8c 00000246 db281e8c c1043d23 00000001 f6923000 f69231b4 db281e9c db281ebc Call Trace: [<c10252a0>] ? __wake_up+0x40/0x50 [<c1043d23>] ? prepare_to_wait+0x43/0x70 [<f8ce328d>] snd_card_free+0x5d/0x90 [snd] [<c1043af0>] ? autoremove_wake_function+0x0/0x40 [<f9ebcaa6>] snd_vt1724_remove+0x13/0x25 [snd_ice1724] [<c11cddb9>] pci_device_remove+0x19/0x40 [<c1239f3e>] __device_release_driver+0x3e/0x90 [<c123a017>] driver_detach+0x87/0x90 [<c1239323>] bus_remove_driver+0x63/0xa0 [<c123a526>] driver_unregister+0x46/0x80 [<c10d616d>] ? sysfs_remove_file+0xd/0x10 [<c11cdfed>] pci_unregister_driver+0x2d/0x80 [<f9ebca91>] alsa_card_ice1724_exit+0xd/0xf [snd_ice1724] [<c1057bee>] sys_delete_module+0x15e/0x210 [<c107f91f>] ? remove_vma+0x3f/0x60 [<c1080902>] ? do_munmap+0x202/0x2d0 [<c1002b50>] sysenter_do_call+0x12/0x26 CONFIG_SOUND=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_VMASTER=y CONFIG_SND_DMA_SGBUF=y CONFIG_SND_AC97_CODEC=m CONFIG_SND_PCI=y CONFIG_SND_ICE1724=m

2 3

Re: [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
by Clemens Ladisch 03 Jun '10

03 Jun '10

Frederick V Heitkamp wrote: > Repeatable Hard Crash. > What else do I need to provide? > > [ 5484.995249] WriteControlReg: not written, no change > [ 5485.069621] divide error: 0000 [#1] pcm_hw_params ok > [ 5485.070159] Prepare rate=44100 format=2 channels=2 > [ 5485.070161] set_audio_format[14] = 5 > [ 5485.070166] Prepare rate=44100 format=2 channels=2 > [ 5485.070167] set_audio_format[14] = 5 > [ 5485.070003] PREEMPT SMP > ... > [ 5485.070003] EIP is at pcm_pointer+0x37/0x70 [snd_echo3g] > ... > [ 5485.965788] [<c10041c0>] ? do_divide_error+0x0/0x90 > [ 5485.980619] [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g] > [ 5485.998047] [<c104764e>] ? run_timer_softirq+0x17e/0x2e0 > [ 5486.014175] [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g] > [ 5486.033940] [<c107a5d5>] ? handle_IRQ_event+0x45/0x190 bytes_to_frames() divides by runtime->frame_bits which is not set until after the hw_params callback has succeeded, but the corresponding chip->substream[] entry is set in that callback, by init_engine(). It should probably have been set in the prepare callback. Frederick, please try the patch below. Takashi, is there any reason why the runtime-> fields are initialized after the hw_params callback? Regards, Clemens --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -403,12 +403,6 @@ if (err < 0) goto _error; - if (substream->ops->hw_params != NULL) { - err = substream->ops->hw_params(substream, params); - if (err < 0) - goto _error; - } - runtime->access = params_access(params); runtime->format = params_format(params); runtime->subformat = params_subformat(params); @@ -446,6 +440,13 @@ runtime->boundary *= 2; snd_pcm_timer_resolution_change(substream); + + if (substream->ops->hw_params != NULL) { + err = substream->ops->hw_params(substream, params); + if (err < 0) + goto _error; + } + runtime->status->state = SNDRV_PCM_STATE_SETUP; pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,

6 10

[alsa-devel] usbaudio: Support for USB audio v2.0 devices
by Daniel Mack 27 May '10

27 May '10

Hi, I've been working on support for USB devices compliant to audio class v2.0 and would like to share what I got. First problem is that they literally changed every single descriptor type by adding or removing fields or changing their width, respectively. Even worse, some enum values were dropped and reassigned so their numerical value has a different meaning now. My first step was to clean up most of the existing descriptor parsers by moving away from anonymous byte array access to real structs so we can see which fields we're actually dereferencing. In a second step, I added definitions for the replacement descriptors and use them at appropriate places. The bInterfaceProtocol field must always be set correctly of course, otherwise we'll parse garbage. Other things that have changed from v1.0 to v2.0 are: * The number of streaming interfaces is now reported by a standard interface association descriptor. The old approach using a proprietary descriptor extension is deprecated. * The number of channels per interface is now stored in the AS_GENERAL descriptor (used to be part of the FORMAT_TYPE descriptor). * The list of supported sample rates is no longer stored in a variable length appendix of the FORMAT_TYPE descriptor but is retrieved from the device using a class specific GET_RANGE command. * Supported sample formats are now reported as 32bit bitmap rather than as a fixed value. For now, this is worked around by choosing just one of them. Eventually, the code should propagate the full ability of the device. * A devices needs to have at least one CLOCK_SOURCE descriptor which denotes a clockID that is needed as argument to the class request command. If can have more than one though and the host driver is in charge to choose the right one. There are also new types for clock selectors and sample rate converters that a device might report. This is all unsupported at the moment. We only parse the first CLOCK_SOURCE and take this one. * Many descriptors (format_type, ...) have changed their layout. Handle this by casting the descriptors to the appropriate structs. With the following patches applied, a v2.0 device is recognized and reported as ALSA device. I can even hear at least some kind of music, but the sample rate setting does not yet seem to be correct. Also, the existing mixer code does not work at all for v2.0 devices. This will be quite some work to support that and I fear the whole thing must be reimplemented for v2.0 specifically. For now, I worked around that by not parsing them at all but bailing out very early. However, I would like to make sure the changes I made so far won't cause any regression for v1.0 devices, and so it would be good to see them applied as a preliminary support. I'll continue working on this and send more updates along. Let me know what you think. Thanks, Daniel

5 33

[alsa-devel] [PATCH: alsa-lib] Fix a string format ambiguity
by Colin Guthrie 27 May '10

27 May '10

Hi, Simply patch to fix a format-string ambiguity. Meant to give this over before 1.0.23 but forgot. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]

2 1

[alsa-devel] [RFC] disabling ALSA period interrupts
by pl bossart 20 May '10

20 May '10

Howdy, When PulseAudio is used and all PCM is routed through PulseAudio (Fedora, Meego, etc), the notion of ALSA periods isn't very useful. PulseAudio uses a timer to refill buffers and the period interrupts are not used at all. So why not disable them entirely to reduce the number of wakeups? This is possible with a number of existing DMA controllers. The simple patch attached shows a proof-of-concept on HDAudio, it's been working for 5 hours on my Fedora12 laptop without any glitches and powertop does show _zero_ wakeups from the HDAudio controller (except on startup). I am told by my colleagues working in Windows environments that this is what's done on Vista/Windows7 btw. This isn't to say Windows is great but that artificial generation of not-needed interrupts is avoidable. There are probably some cases where you don't want this type of behavior (broken hardware, legacy code with multiple-buffering, disabled timer in PulseAudio), so I think it would make sense to request the disabling of interrupts when hw_params are set, since this is also the time when period sizes are set. I am aware that some changes would be needed in pcm_lib.c, where all the error checks are done. Takashi, Jaroslav, Lennart, what do you think? Feedback and suggestions welcome. Cheers - Pierre

10 56

[alsa-devel] [PATCH] ALSA: hda: Fix 0 dB for Packard Bell models using Conexant CX20549 (Venice)
by Daniel Chen 11 May '10

11 May '10

Hi, Attached is a patch against sound-2.6 master HEAD (also applicable to 2.6.32.12 and 2.6.33.3) that fixes 0 dB for Packard Bell machines using Conexant CX20549. Without it, sound distorts horribly. Best, -Dan

3 6