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

[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

[alsa-devel] Mute LED on HP Pavilion DV7-1160eg
by Thoralf Freitag 10 May '10

10 May '10

I tried to find a way for switching/control Mute LED on an HP DV 7 notebook. I found a solution which is very ugly. According the solution described here (http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016126.html) I changed the value for LED control in this manner: diff -u alsa-driver-1.0.23/sound/pci/hda/patch_sigmatel.c alsa-driver-1.0.23_b/sound/pci/hda/patch_sigmatel.c --- alsa-driver-1.0.23/sound/pci/hda/patch_sigmatel.c 2010-04-16 13:10:10.000000000 +0200 +++ alsa-driver-1.0.23_b/sound/pci/hda/patch_sigmatel.c 2010-05-01 21:37:36.719063655 +0200 @@ -4952,9 +4952,9 @@ } } if (muted) - spec->gpio_data &= ~spec->gpio_led; /* orange */ + spec->gpio_data &= ~0x01; /* orange */ else - spec->gpio_data |= spec->gpio_led; /* white */ + spec->gpio_data |= 0x01; /* white */ if (!spec->gpio_led_polarity) { /* LED state is inverted on these systems */ I hate this solution. Maybe someone of the programming experts could give me a way to make it better. On which position should I make which changes ? Thanx for your guidance. Thoralf

2 3

[alsa-devel] [RFC] G.723-24 format patch
by Ben Collins 10 May '10

10 May '10

I'm writing a driver for a card that only has hardware support for G.723-24 ADPCM format. I am working around the lack of support in alsa at the moment for this format, but wanted to take a crack at implementing it properly. G.723-24 is a 3-bit signed sample at a fixed 8khz mono sample rate (24000 bit rate). Basically means you need to take in at least 3 bytes (8 samples) minimum for processing the standard packed version. I don't have hardware that supports it, but since I was in the code, I added a G723_24_1B format for producing 1 sample per byte (3 lower bits are actual sample), but for my use I am producing the standard packed stream. Only question I had is that since this is signed, should I expect or want the _1B version to be a 1 byte sign extended version of the 3-bit sample, or just expect the lower 3 bits of the byte to be the g723-24 sample? Looking at other unpacked examples, I assume the latter rather than the former. diff --git a/include/sound/asound.h b/include/sound/asound.h index 1f57bb9..16fc633 100644 --- a/include/sound/asound.h +++ b/include/sound/asound.h @@ -212,7 +212,9 @@ typedef int __bitwise snd_pcm_format_t; #define SNDRV_PCM_FORMAT_S18_3BE ((__force snd_pcm_format_t) 41) /* in three bytes */ #define SNDRV_PCM_FORMAT_U18_3LE ((__force snd_pcm_format_t) 42) /* in three bytes */ #define SNDRV_PCM_FORMAT_U18_3BE ((__force snd_pcm_format_t) 43) /* in three bytes */ -#define SNDRV_PCM_FORMAT_LAST SNDRV_PCM_FORMAT_U18_3BE +#define SNDRV_PCM_FORMAT_G723_24 ((__force snd_pcm_format_t) 44) /* 8 samples in 3 bytes */ +#define SNDRV_PCM_FORMAT_G723_24_1B ((__force snd_pcm_format_t) 45) /* 1 sample in 1 byte */ +#define SNDRV_PCM_FORMAT_LAST SNDRV_PCM_FORMAT_G723_24_1B #ifdef SNDRV_LITTLE_ENDIAN #define SNDRV_PCM_FORMAT_S16 SNDRV_PCM_FORMAT_S16_LE diff --git a/include/sound/pcm.h b/include/sound/pcm.h index de6d981..031e2cd 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -173,6 +173,8 @@ struct snd_pcm_ops { #define SNDRV_PCM_FMTBIT_U18_3LE (1ULL << SNDRV_PCM_FORMAT_U18_3LE) #define SNDRV_PCM_FMTBIT_S18_3BE (1ULL << SNDRV_PCM_FORMAT_S18_3BE) #define SNDRV_PCM_FMTBIT_U18_3BE (1ULL << SNDRV_PCM_FORMAT_U18_3BE) +#define SNDRV_PCM_FMTBIT_G723_24 (1ULL << SNDRV_PCM_FORMAT_G723_24) +#define SNDRV_PCM_FMTBIT_G723_24_1B (1ULL << SNDRV_PCM_FORMAT_G723_24_1B) #ifdef SNDRV_LITTLE_ENDIAN #define SNDRV_PCM_FMTBIT_S16 SNDRV_PCM_FMTBIT_S16_LE diff --git a/sound/core/pcm_misc.c b/sound/core/pcm_misc.c index ea2bf82..c7f8da4 100644 --- a/sound/core/pcm_misc.c +++ b/sound/core/pcm_misc.c @@ -128,6 +128,10 @@ static struct pcm_format_data pcm_formats[SNDRV_PCM_FORMAT_LAST+1] = { .width = 4, .phys = 4, .le = -1, .signd = -1, .silence = {}, }, + [SNDRV_PCM_FORMAT_G723_24] = { + .width = 3, .phys = 3, .le = -1, .signd = 1, + .silence = {}, + }, /* FIXME: the following three formats are not defined properly yet */ [SNDRV_PCM_FORMAT_MPEG] = { .le = -1, .signd = -1, @@ -186,6 +190,10 @@ static struct pcm_format_data pcm_formats[SNDRV_PCM_FORMAT_LAST+1] = { .width = 18, .phys = 24, .le = 0, .signd = 0, .silence = { 0x02, 0x00, 0x00 }, }, + [SNDRV_PCM_FORMAT_G723_24_1B] = { + .width = 3, .phys = 8, .le = -1, .signd = 1, + .silence = {}, + }, };

2 3

Re: [alsa-devel] ALSA Control Interface - default values?
by Mark Brown 10 May '10

10 May '10

On Mon, May 10, 2010 at 04:25:07PM +0200, Max Klein wrote: > thanks for fast reply, may you tell me how the driver can set the defaults? > EDIT: whoops, I guess it was an error in reasoning from myself...as I have the control of all those variables outputted by the get and put callbacks, I just have to initialize those variables before initializing the control interface, right? Yes, the driver just needs to make sure that whatever it uses to return the current setting when queried is going to give the right answer from the time the control is set up, normally by initialising variables though if you're doing things like read data back from hardware then you may be able to rely on the hardware defaults. [Re-adding CC to alsa-devel - it's normal to do a reply to all for Linux lists.]

1 0

Re: [alsa-devel] [PATCH] ALSA: hda: enable SPDIF output for Conexant 5051/Lenovo docking stations
by Takashi Iwai 10 May '10

10 May '10

At Mon, 10 May 2010 10:21:50 -0400, Aristeu Rozanski wrote: > > Hi Pierre, > > this patch should work for all CXT5051-based Lenovo docking stations. > > Aristeu, you added a quirk for the X200 docking station (commit > > 0e6e6db212b0c97c5d4f5f55b674ec2d3276c16c), > > can you check if you see any adverse effects with this patch? > the patch doesn't change or break anything on X200 or X200 + docking Thanks for checking! Takashi

1 0

[alsa-devel] [PATCH] ALSA: hda: enable SPDIF output for Conexant 5051/Lenovo docking stations
by pl bossart 10 May '10

10 May '10

this patch should work for all CXT5051-based Lenovo docking stations. Aristeu, you added a quirk for the X200 docking station (commit 0e6e6db212b0c97c5d4f5f55b674ec2d3276c16c), can you check if you see any adverse effects with this patch? Thanks - Pierre

2 3

[alsa-devel] ALSA Control Interface - default values?
by Max Klein 10 May '10

10 May '10

Hello, when writing an alsa driver, in the info callback of the control I can specify which range of values this control does accept (uinfo->value.integer.min and .max). If I put 1 as minimum and 10 as maximum for example, I would expect that the default value of this control is something in between the range, e.g. 1, after the driver is loaded. But I figured out, that ALSA initializes the control with a value of 0, which is not in between the range. Can someone please tell me why ALSA initializes the Control with a value of zero, even if the minimum in the info callback is 1 ? Is there any way to initialize the control with some "default" values, aside of snd_ctl_add()? Best regards and thanks for your help! Max -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

2 1

Re: [alsa-devel] WM8993: amp control, amplifying pops.
by Mark Brown 10 May '10

10 May '10

On Mon, May 10, 2010 at 10:10:53AM +0800, Zhang JieJing wrote: > I have a question about WM8993 codec's amplifying pops control. Could you please be more specific about what you mean when you say "amplifying pops control"? What exactly is an "amplifying pop" (do you mean that you hear an unwanted noise, or is there something else)? Please ensure that you are using the latest version of the WM8993 driver (including wm_hubs.c) to make sure that you have all the latest bug fixes and enhancements. If you are not using single ended line outputs from the device you should also mark the line outputs as being in differential mode for maximum power savings. > Our board using a WM8993 codec, and I We have problem about ampifying pops, > when the system resume, We will heard a ampifying pop, (but it's silence on > the suspend processing), We also noticed that when system boot, also can > hear one ampifying pop. System resume and power up are identical from the point of view of the CODEC driver. > From I know, the WM8993's codec have a internal amplifier, I don't know how > to control this amplifier. The WM8993 has a large number of amplifiers, there are many audio paths in the device and most of them have some amplification control. Which outputs are you concerned about?

1 0

[alsa-devel] [PATCH] ASoC: core: Support for limiting the volume
by Peter Ujfalusi 10 May '10

10 May '10

Add support for the core to limit the maximum volume on an existing control. The function will modify the soc_mixer_control.max value of the given control. The new value must be lower than the original one (chip maximum) If there is a need for limiting a gain on a given control, than machine drivers can do the following in their snd_soc_dai_link.init function: snd_soc_limit_volume(codec, "TPA6140A2 Headphone Playback Volume", 21); This will modify the original 31 (chip maximum) to 21, so user space will not be able to set the gain higher than this. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- include/sound/soc.h | 2 ++ sound/soc/soc-core.c | 39 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 41 insertions(+), 0 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 01e9c66..9f306f0 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -326,6 +326,8 @@ int snd_soc_get_volsw_s8(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); int snd_soc_put_volsw_s8(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); +int snd_soc_limit_volume(struct snd_soc_codec *codec, + const char *name, int max); /** * struct snd_soc_jack_pin - Describes a pin to update based on jack detection diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index d59076e..4079223 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2238,6 +2238,45 @@ int snd_soc_put_volsw_s8(struct snd_kcontrol *kcontrol, EXPORT_SYMBOL_GPL(snd_soc_put_volsw_s8); /** + * snd_soc_limit_volume - Set new limit to an existing volume control. + * + * @codec: where to look for the control + * @name: Name of the control + * @max: new maximum limit + * + * Return 0 for success, else error. + */ +int snd_soc_limit_volume(struct snd_soc_codec *codec, + const char *name, int max) +{ + struct snd_card *card = codec->card; + struct snd_kcontrol *kctl; + struct soc_mixer_control *mc; + int found = 0; + int ret = -EINVAL; + + /* Sanity check for name and max */ + if (unlikely(!name || max <= 0)) + return -EINVAL; + + list_for_each_entry(kctl, &card->controls, list) { + if (!strncmp(kctl->id.name, name, sizeof(kctl->id.name))) { + found = 1; + break; + } + } + if (found) { + mc = (struct soc_mixer_control *)kctl->private_value; + if (max <= mc->max) { + mc->max = max; + ret = 0; + } + } + return ret; +} +EXPORT_SYMBOL_GPL(snd_soc_limit_volume); + +/** * snd_soc_dai_set_sysclk - configure DAI system or master clock. * @dai: DAI * @clk_id: DAI specific clock ID -- 1.7.1

3 4

Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems
by David Woodhouse 10 May '10

10 May '10

On Mon, 2010-05-10 at 11:50 +0900, FUJITA Tomonori wrote: > On Fri, 7 May 2010 10:51:10 -0400 (EDT) > Alan Stern <stern(a)rowland.harvard.edu> wrote: > > > On Fri, 7 May 2010, Daniel Mack wrote: > > > > > > At least the audio class and ua101 drivers don't do this and fill the > > > > buffers before they are submitted. > > > > > > Gnaa, you're right. I _thought_ my code does it the way I described, but > > > what I wrote is how I _wanted_ to do it, not how it's currently done. I > > > have a plan to change this in the future. > > > > > > So unfortunately, that doesn't explain it either. Sorry for the noise. > > > > At one point we tried an experiment, printing out the buffer and DMA > > addresses. I don't recall seeing anything obviously wrong, but if an > > IOMMU was in use then that might not mean anything. Is it possible > > that the IOMMU mappings sometimes get messed up for addresses above 4 > > GB? > > You mean that an IOMMU could allocate an address above 4GB wrongly? If > so, IIRC, all the IOMMU implementations use dev->dma_mask and > dev->coherent_dma_mask properly. And the DMA address space of the > majority of IOMMUs are limited less than 4GB. The Intel IOMMU code will use dev->dma_mask and dev->coherent_dma_mask properly. It is not limited to 4GiB, but it will tend to give virtual DMA addresses below 4GiB even when a device is capable of more; it'll only give out higher addresses when the address space below 4GiB is exhausted. -- dwmw2

1 0