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

[alsa-devel] [PATCH] hda_intel: Fixes distorted recording on US15W chipset
by Shahin Ghazinouri 11 May '10

11 May '10

The HDA controller in US15W (Poulsbo) reports inaccurate position values for capture streams when using the LPIB read method, resulting in distorted recordings. However, using the position buffer is broken for playback streams, resulting in a fallback to the LPIB method with the current driver. This patch works around the issue by independently detecting the read position method for capture and playback streams. The patch will not have any effect if the position fix method is explicitly set. Signed-off-by: Shahin Ghazinouri <shahin.ghazinouri(a)pelagicore.com> --- --- linux-2.6.34-rc6/sound/pci/hda/hda_intel.c 2010-04-30 05:02:05.000000000 +0200 +++ linux-2.6.34-rc6_patch/sound/pci/hda/hda_intel.c 2010-04-30 11:31:57.000000000 +0200 @@ -425,7 +425,8 @@ struct snd_dma_buffer posbuf; /* flags */ - int position_fix; + int playback_position_fix; + int capture_position_fix; int poll_count; unsigned int running :1; unsigned int initialized :1; @@ -1302,8 +1303,10 @@ azx_sd_writel(azx_dev, SD_BDLPU, upper_32_bits(azx_dev->bdl.addr)); /* enable the position buffer */ - if (chip->position_fix == POS_FIX_POSBUF || - chip->position_fix == POS_FIX_AUTO || + if (chip->capture_position_fix == POS_FIX_POSBUF || + chip->capture_position_fix == POS_FIX_AUTO || + chip->playback_position_fix == POS_FIX_POSBUF || + chip->playback_position_fix == POS_FIX_AUTO || chip->via_dmapos_patch) { if (!(azx_readl(chip, DPLBASE) & ICH6_DPLBASE_ENABLE)) azx_writel(chip, DPLBASE, @@ -1843,13 +1846,24 @@ if (chip->via_dmapos_patch) pos = azx_via_get_position(chip, azx_dev); - else if (chip->position_fix == POS_FIX_POSBUF || - chip->position_fix == POS_FIX_AUTO) { - /* use the position buffer */ - pos = le32_to_cpu(*azx_dev->posbuf); + else if (azx_dev->index < chip->playback_index_offset) { + /* Capture stream */ + if (chip->capture_position_fix == POS_FIX_POSBUF || + chip->capture_position_fix == POS_FIX_AUTO) + /* use the position buffer */ + pos = le32_to_cpu(*azx_dev->posbuf); + else + /* read LPIB */ + pos = azx_sd_readl(azx_dev, SD_LPIB); } else { - /* read LPIB */ - pos = azx_sd_readl(azx_dev, SD_LPIB); + /* Playback stream */ + if (chip->playback_position_fix == POS_FIX_POSBUF || + chip->playback_position_fix == POS_FIX_AUTO) + /* use the position buffer */ + pos = le32_to_cpu(*azx_dev->posbuf); + else + /* read LPIB */ + pos = azx_sd_readl(azx_dev, SD_LPIB); } if (pos >= azx_dev->bufsize) pos = 0; @@ -1884,15 +1898,30 @@ azx_dev->start_flag = 0; pos = azx_get_position(chip, azx_dev); - if (chip->position_fix == POS_FIX_AUTO) { - if (!pos) { - printk(KERN_WARNING - "hda-intel: Invalid position buffer, " - "using LPIB read method instead.\n"); - chip->position_fix = POS_FIX_LPIB; - pos = azx_get_position(chip, azx_dev); - } else - chip->position_fix = POS_FIX_POSBUF; + if (azx_dev->index < chip->playback_index_offset) { + /* Capture stream */ + if (chip->capture_position_fix == POS_FIX_AUTO) { + if (!pos) { + printk(KERN_WARNING + "hda-intel: Invalid position buffer, " + "using LPIB read method instead.\n"); + chip->capture_position_fix = POS_FIX_LPIB; + pos = azx_get_position(chip, azx_dev); + } else + chip->capture_position_fix = POS_FIX_POSBUF; + } + } else { + /* Playback stream */ + if (chip->playback_position_fix == POS_FIX_AUTO) { + if (!pos) { + printk(KERN_WARNING + "hda-intel: Invalid position buffer, " + "using LPIB read method instead.\n"); + chip->playback_position_fix = POS_FIX_LPIB; + pos = azx_get_position(chip, azx_dev); + } else + chip->playback_position_fix = POS_FIX_POSBUF; + } } if (!bdl_pos_adj[chip->dev_index]) @@ -2431,7 +2460,10 @@ chip->dev_index = dev; INIT_WORK(&chip->irq_pending_work, azx_irq_pending_work); - chip->position_fix = check_position_fix(chip, position_fix[dev]); + chip->capture_position_fix = + check_position_fix(chip, position_fix[dev]); + chip->playback_position_fix = + check_position_fix(chip, position_fix[dev]); check_probe_mask(chip, dev); chip->single_cmd = single_cmd;

2 3

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

11 May '10

Hi, Attached please find a patch against sound-2.6 (also applicable to stable trees) that fixes the reported distortion for Lenovo models on CX20549. Best, -Dan

2 1

[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