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

[alsa-devel] [PATCH] ASoC: dapm: Convert pin switches to use snd_soc_card
by Mark Brown 15 Feb '12

15 Feb '12

Since the addition of the non-CODEC control adds card controls like the DAPM pin switch have been broken as they are expecting the private data for the control to be the CODEC but it's now the card. Fix that for the pin switches, an audit of other drivers is required. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-dapm.c | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 6fc488e..9b796e3 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -2644,15 +2644,15 @@ EXPORT_SYMBOL_GPL(snd_soc_dapm_info_pin_switch); int snd_soc_dapm_get_pin_switch(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { - struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); + struct snd_soc_card *card = snd_kcontrol_chip(kcontrol); const char *pin = (const char *)kcontrol->private_value; - mutex_lock(&codec->mutex); + mutex_lock(&card->mutex); ucontrol->value.integer.value[0] = - snd_soc_dapm_get_pin_status(&codec->dapm, pin); + snd_soc_dapm_get_pin_status(&card->dapm, pin); - mutex_unlock(&codec->mutex); + mutex_unlock(&card->mutex); return 0; } @@ -2667,19 +2667,19 @@ EXPORT_SYMBOL_GPL(snd_soc_dapm_get_pin_switch); int snd_soc_dapm_put_pin_switch(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { - struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); + struct snd_soc_card *card = snd_kcontrol_chip(kcontrol); const char *pin = (const char *)kcontrol->private_value; - mutex_lock(&codec->mutex); + mutex_lock(&card->mutex); if (ucontrol->value.integer.value[0]) - snd_soc_dapm_enable_pin(&codec->dapm, pin); + snd_soc_dapm_enable_pin(&card->dapm, pin); else - snd_soc_dapm_disable_pin(&codec->dapm, pin); + snd_soc_dapm_disable_pin(&card->dapm, pin); - snd_soc_dapm_sync(&codec->dapm); + snd_soc_dapm_sync(&card->dapm); - mutex_unlock(&codec->mutex); + mutex_unlock(&card->mutex); return 0; } -- 1.7.9.rc1

3 4

[alsa-devel] [PATCH v2] ASoC: core - add platform DAPM debugfs support
by Liam Girdwood 15 Feb '12

15 Feb '12

From: Sebastien Guiriec <s-guiriec(a)ti.com> Allow platform widgets to be visible in debugfs like codec widgets. Signed-off-by: Liam Girdwood <lrg(a)ti.com> --- include/sound/soc.h | 5 +++++ sound/soc/soc-core.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 0 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 4f67e01..8fa4dca 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -706,6 +706,11 @@ struct snd_soc_platform { struct list_head card_list; struct snd_soc_dapm_context dapm; + +#ifdef CONFIG_DEBUG_FS + struct dentry *debugfs_platform_root; + struct dentry *debugfs_dapm; +#endif }; struct snd_soc_dai_link { diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 8bd9995..276b68a 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -302,6 +302,27 @@ static void soc_cleanup_codec_debugfs(struct snd_soc_codec *codec) debugfs_remove_recursive(codec->debugfs_codec_root); } +static void soc_init_platform_debugfs(struct snd_soc_platform *platform) +{ + struct dentry *debugfs_card_root = platform->card->debugfs_card_root; + + platform->debugfs_platform_root = debugfs_create_dir(platform->name, + debugfs_card_root); + if (!platform->debugfs_platform_root) { + dev_warn(platform->dev, + "Failed to create platform debugfs directory\n"); + return; + } + + snd_soc_dapm_debugfs_init(&platform->dapm, + platform->debugfs_platform_root); +} + +static void soc_cleanup_platform_debugfs(struct snd_soc_platform *platform) +{ + debugfs_remove_recursive(platform->debugfs_platform_root); +} + static ssize_t codec_list_read_file(struct file *file, char __user *user_buf, size_t count, loff_t *ppos) { @@ -435,6 +456,14 @@ static inline void soc_cleanup_codec_debugfs(struct snd_soc_codec *codec) { } +static inline void soc_init_platform_debugfs(struct snd_soc_platform *platform) +{ +} + +static inline void soc_cleanup_platform_debugfs(struct snd_soc_platform *platform) +{ +} + static inline void soc_init_card_debugfs(struct snd_soc_card *card) { } @@ -922,6 +951,7 @@ static void soc_remove_dai_link(struct snd_soc_card *card, int num, int order) /* Make sure all DAPM widgets are freed */ snd_soc_dapm_free(&platform->dapm); + soc_cleanup_platform_debugfs(platform); platform->probed = 0; list_del(&platform->card_list); module_put(platform->dev->driver->owner); @@ -1039,6 +1069,8 @@ static int soc_probe_platform(struct snd_soc_card *card, if (!try_module_get(platform->dev->driver->owner)) return -ENODEV; + soc_init_platform_debugfs(platform); + if (driver->dapm_widgets) snd_soc_dapm_new_controls(&platform->dapm, driver->dapm_widgets, driver->num_dapm_widgets); -- 1.7.5.4

2 1

[alsa-devel] [PATCH] ASoC: dapm - Make DAPM reset code a separate function.
by Liam Girdwood 15 Feb '12

15 Feb '12

It's useful to export the DAPM reset as a static function for future use by other DAPM functions. e.g. The dynamic PCM query widgets resets the DAPM graph before working out active paths. Signed-off-by: Liam Girdwood <lrg(a)ti.com> --- sound/soc/soc-dapm.c | 21 ++++++++++++++------- 1 files changed, 14 insertions(+), 7 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 0c94027..227887e 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -169,6 +169,19 @@ static inline struct snd_soc_card *dapm_get_soc_card( return NULL; } +static void dapm_reset(struct snd_soc_card *card) +{ + struct snd_soc_dapm_widget *w; + + memset(&card->dapm_stats, 0, sizeof(card->dapm_stats)); + + list_for_each_entry(w, &card->widgets, list) { + w->power_checked = false; + w->inputs = -1; + w->outputs = -1; + } +} + static int soc_widget_read(struct snd_soc_dapm_widget *w, int reg) { if (w->codec) @@ -1402,13 +1415,7 @@ static int dapm_power_widgets(struct snd_soc_dapm_context *dapm, int event) } } - memset(&card->dapm_stats, 0, sizeof(card->dapm_stats)); - - list_for_each_entry(w, &card->widgets, list) { - w->power_checked = false; - w->inputs = -1; - w->outputs = -1; - } + dapm_reset(card); /* Check which widgets we need to power and store them in * lists indicating if they should be powered up or down. We -- 1.7.5.4

2 7

[alsa-devel] [PATCH] ALSA: usb-audio: avoid integer overflow in create_fixed_stream_quirk()
by Xi Wang 15 Feb '12

15 Feb '12

A malicious USB device could feed in a large nr_rates value. This would cause the subsequent call to kmemdup() to allocate a smaller buffer than expected, leading to out-of-bounds access. This patch validates the nr_rates value and reuses the limit introduced in commit 4fa0e81b ("ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()"). Signed-off-by: Xi Wang <xi.wang(a)gmail.com> --- sound/usb/card.h | 1 + sound/usb/format.c | 4 +--- sound/usb/quirks.c | 6 +++++- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/sound/usb/card.h b/sound/usb/card.h index a39edcc..da5fa1a 100644 --- a/sound/usb/card.h +++ b/sound/usb/card.h @@ -1,6 +1,7 @@ #ifndef __USBAUDIO_CARD_H #define __USBAUDIO_CARD_H +#define MAX_NR_RATES 1024 #define MAX_PACKS 20 #define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */ #define MAX_URBS 8 diff --git a/sound/usb/format.c b/sound/usb/format.c index e09aba1..ddfef57 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -209,8 +209,6 @@ static int parse_audio_format_rates_v1(struct snd_usb_audio *chip, struct audiof return 0; } -#define MAX_UAC2_NR_RATES 1024 - /* * Helper function to walk the array of sample rate triplets reported by * the device. The problem is that we need to parse whole array first to @@ -255,7 +253,7 @@ static int parse_uac2_sample_rate_range(struct audioformat *fp, int nr_triplets, fp->rates |= snd_pcm_rate_to_rate_bit(rate); nr_rates++; - if (nr_rates >= MAX_UAC2_NR_RATES) { + if (nr_rates >= MAX_NR_RATES) { snd_printk(KERN_ERR "invalid uac2 rates\n"); break; } diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index a3ddac0..2781726 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -132,10 +132,14 @@ static int create_fixed_stream_quirk(struct snd_usb_audio *chip, unsigned *rate_table = NULL; fp = kmemdup(quirk->data, sizeof(*fp), GFP_KERNEL); - if (! fp) { + if (!fp) { snd_printk(KERN_ERR "cannot memdup\n"); return -ENOMEM; } + if (fp->nr_rates > MAX_NR_RATES) { + kfree(fp); + return -EINVAL; + } if (fp->nr_rates > 0) { rate_table = kmemdup(fp->rate_table, sizeof(int) * fp->nr_rates, GFP_KERNEL); -- 1.7.5.4

2 1

Re: [alsa-devel] [PATCH v2] [trivial] usx2y: Fix typo in usbusx2yaudio.c and usx2yhwdeppcm.c
by Takashi Iwai 15 Feb '12

15 Feb '12

At Wed, 15 Feb 2012 00:38:55 +0900, Masanari Iida wrote: > > Correct spelling "propably" to "probably" and "activ" to "active" > in sound/usb/usx2y/usbusx2yaudio.c and usx2yhwdeppcm.c > > Signed-off-by: Masanari Iida <standby24x7(a)gmail.com> Thanks, applied now to topic/misc branch of sound git tree. Takashi > --- > sound/usb/usx2y/usbusx2yaudio.c | 4 ++-- > sound/usb/usx2y/usx2yhwdeppcm.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/sound/usb/usx2y/usbusx2yaudio.c b/sound/usb/usx2y/usbusx2yaudio.c > index 6ffb371..520ef96 100644 > --- a/sound/usb/usx2y/usbusx2yaudio.c > +++ b/sound/usb/usx2y/usbusx2yaudio.c > @@ -80,7 +80,7 @@ static int usX2Y_urb_capt_retire(struct snd_usX2Y_substream *subs) > cp = (unsigned char*)urb->transfer_buffer + urb->iso_frame_desc[i].offset; > if (urb->iso_frame_desc[i].status) { /* active? hmm, skip this */ > snd_printk(KERN_ERR "active frame status %i. " > - "Most propably some hardware problem.\n", > + "Most probably some hardware problem.\n", > urb->iso_frame_desc[i].status); > return urb->iso_frame_desc[i].status; > } > @@ -300,7 +300,7 @@ static void usX2Y_error_sequence(struct usX2Ydev *usX2Y, > { > snd_printk(KERN_ERR > "Sequence Error!(hcd_frame=%i ep=%i%s;wait=%i,frame=%i).\n" > -"Most propably some urb of usb-frame %i is still missing.\n" > +"Most probably some urb of usb-frame %i is still missing.\n" > "Cause could be too long delays in usb-hcd interrupt handling.\n", > usb_get_current_frame_number(usX2Y->dev), > subs->endpoint, usb_pipein(urb->pipe) ? "in" : "out", > diff --git a/sound/usb/usx2y/usx2yhwdeppcm.c b/sound/usb/usx2y/usx2yhwdeppcm.c > index a51340f..8e40b6e 100644 > --- a/sound/usb/usx2y/usx2yhwdeppcm.c > +++ b/sound/usb/usx2y/usx2yhwdeppcm.c > @@ -74,7 +74,7 @@ static int usX2Y_usbpcm_urb_capt_retire(struct snd_usX2Y_substream *subs) > } > for (i = 0; i < nr_of_packs(); i++) { > if (urb->iso_frame_desc[i].status) { /* active? hmm, skip this */ > - snd_printk(KERN_ERR "activ frame status %i. Most propably some hardware problem.\n", urb->iso_frame_desc[i].status); > + snd_printk(KERN_ERR "active frame status %i. Most probably some hardware problem.\n", urb->iso_frame_desc[i].status); > return urb->iso_frame_desc[i].status; > } > lens += urb->iso_frame_desc[i].actual_length / usX2Y->stride; > -- > 1.7.6.5 >

1 0

[alsa-devel] 1ca3d59d5a3e762fb1c002bcd912914bc858b430 broke passthrough [Was: Re: ALSA 1.0.25 broke AC3 passthrough?]
by Jean-Yves Avenard 15 Feb '12

15 Feb '12

Hi again Allright.. Took me forever doing a bisect in alsa-kmirror while finding the proper revision in alsa-drivers to be able to compile it. So painful.. How do you guys ever manage to quickly do bisect ??? Anyhow... What broke passthrough for me (and others) is this commit: commit 1ca3d59d5a3e762fb1c002bcd912914bc858b430 Author: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Date: Thu Aug 4 10:12:56 2011 -0500 ALSA: hda: option to enable arbitrary buffer/period sizes Add new parameter to disable rounding of buffer/period sizes to multiples of 128 bytes. This is more efficient in terms of memory access but isn't required by the HDA spec and prevents users from specifying exact period/buffer sizes. For example for 44.1kHz, a period size set to 20ms will be rounded to 19.59ms. Tested and enabled on Intel HDA controllers. Option is disabled by default for other controllers. Tested-by: Wu Fengguang <fengguang.wu(a)intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Jaroslav Kysela <perex(a)perex.cz> It's not an obvious breakage however and it only occurs with specific combinations of hardware buffer size (as seen for me in /proc/asound/card1/pcm3p/sub0/prealloc) and request of buffer time and period size. With the default ALSA hardware buffer size of 64kB, AC3/DTS works. With 4096, it doesn't and it will make the tested applications hang. both MythTV and mplayer (and I know of a few others), request by default a buffer time of 500ms with a period of 4 (requested respectively through snd_pcm_hw_params_set_buffer_time_near and snd_pcm_hw_params_set_periods_near) With those combinations: (4MB hardware buffer, 500ms and period of 4), trying to write audio with snd_pcm_writei will hang to eventually fail with the error "Input/output error" Disabling the functionality introduced in that changeset, fix it for v1.0.25 (using the following patch: diff --git a/pci/hda/hda_intel.c b/pci/hda/hda_intel.c index 9cbde2f..9227389 100644 --- a/pci/hda/hda_intel.c +++ b/pci/hda/hda_intel.c @@ -2773,8 +2773,8 @@ static int __devinit azx_create(struct snd_card *card, str } /* disable buffer size rounding to 128-byte multiples if supported */ - if (chip->driver_caps & AZX_DCAPS_BUFSIZE) - align_buffer_size = 0; +// if (chip->driver_caps & AZX_DCAPS_BUFSIZE) +// align_buffer_size = 0; /* allow 64bit DMA address if supported by H/W */ if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64))) ) Hope this help Regards Jean-Yves Avenard

4 7

Re: [alsa-devel] [PATCH 2/2] USB: Gadget: Add Audio Class 2.0 Driver
by Jassi Brar 15 Feb '12

15 Feb '12

On Mon, Aug 22, 2011 at 7:58 PM, Felipe Balbi <balbi(a)ti.com> wrote: > >> > audio.c doesn't do anything audio related. It's just adding the >> > configuration to composite layer. The real specification is implemented >> > in f_audio.c (should probably be called f_uac1.c, though). >> Agreed. Reusing audio.c is quite reasonable. >> So, I'll :- >> * Merge audio2.c into audio.c >> * Rename f_audio.c -> f_uac1.c >> * Add new f_audio2.c as f_uac2.c >> * Add Kconfig switch to compile UAC_1 (audio.c + f_uac1.c) or UAC_2 >> (audio.c + f_uac2.c) >> >> I'll wait for other comments and revise the patch after a few days. > > ok, sounds reasonable. > OK, after a 'few days' on some distant giant planet, here is the revised patchset accordingly. Cheers -jassi

3 5

Re: [alsa-devel] Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series
by Joey Jiao 15 Feb '12

15 Feb '12

Btw, for the code modification, I modified model will in patch_realtek.c which works same as the hda-verb command. From: static const struct hda_verb alc260_will_verbs[] = { {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, {} }; To: static const struct hda_verb alc260_will_verbs[] = { {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP}, {0x0b, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, {0x0f, AC_VERB_SET_EAPD_BTLENABLE, 0x02}, {0x1a, AC_VERB_SET_COEF_INDEX, 0x07}, {0x1a, AC_VERB_SET_PROC_COEF, 0x3040}, {0x01, AC_VERB_SET_GPIO_MASK, 0x01}, {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x01}, {} }; 在 2012年2月15日上午9:18，Joey Jiao <joey.jiaojg(a)gmail.com> 写道： > Hi all, > I solved the speaker problem of B1900, and I have you can fix the > driver in next alsa release. > I use hda-verb tool to enable sound from speaker. > Commands as below: > sudo hda-verb /dev/snd/hwC0D0 0x01 0x716 0x01 > sudo hda-verb /dev/snd/hwC0D0 0x01 0x717 0x01 > > Perhaps you need to add a new model besides will. Meanwhile, auto > detect of headphone inserting is not function, so speaker and > headphone don't switch automatically. > > > 在 2012年2月15日上午8:50，Raymond Yau <superquad.vortex2(a)gmail.com> 写道： >> 2012/2/11, Jonathan Woithe <jwoithe(a)just42.net>: >>> Hi Joey >>> >>> For future reference, please email reports like this to the alsa-devel list. >>> The relevant developers are far more likely to respond to messages on the >>> list than they are to messages sent privately. >>> >>> I have copied this to the list to maximise its distribution. >>> >>> On Sat, Feb 11, 2012 at 09:17:05AM +0800, joey.jiaojg wrote: >>>> I'm reporting a bug related to ALSA and ALC260, which perhaps only >>>> you can solve. Appreciate if you can check. >>>> We got a lot of users using HP COMPAQ B1900 series which using ATI >>>> SB450 and ALC260 for linux systems like Debian, Ubuntu and etc. The >>>> problem is that there is no sound from speaker while enable >>>> model=will can hear from earphone. The problem and alsa-info.txt is >>>> reported here >>>> https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/186698, >>>> which thought be a bug of ALC260 driver bug. >>>> Hope you can check what we can do to solve it. >>> >>> From the above I am not entirely sure what the problem is. You seem to be >>> talking about two separate conditions. In the first (where I presume the >>> module is loaded without any parameters you say there's no sound from the >>> speaker. Do other aspects of the card work correctly in this case? >>> >>> The second situation is where "model=will" is specified as a module >>> parameter. Here you say you can get audio from the headphone, but again >>> what about other aspects of the soundcard - do they work normally? >>> >>> At a rough guess, it sounds like there are two underlying issues. The first >>> is that this system requires some model-specific handing in order to map >>> chip outputs correctly. The second is that if such model-specific details >>> are required then the driver preferrably would activate these automatically >>> without the need to specify "model=will". >>> >>> Another possibility is that there is something about this laptop system >>> which is confusing the auto-probing of the alc260 codec code. >>> >>> I'm not sure what is the best way of proceeding here. I suspect other more >>> active developers will have a streamlined approach to help rectify the >>> trouble. In the first instance I would tend to load the module with >>> "model=test" and experiment with the resulting alsamixer controls to >>> determine what chip outputs are connected to which pins. However, this is >>> quite "old school" now - while it's the approach I used when getting my >>> system working, my impression is that its use has been mostly deprecated by >>> the automatic parser which is now present. >>> >>> In the above-referenced launchpad report the question is asked about the >>> ALC260 datasheet. This is readily available on the net. I doubt it is all >>> that necessary now since I think the base infrastructure is pretty solid, >>> but if you do need it and have difficulty finding it please contact me >>> off-list. >>> >> >> The auto-parser require correct pin default >> >> Refer to alc260 General Description >> >> Realtek's proprietary impedance sensing and jack detect techniques >> allow device loads on inputs and outputs to be auto-detected. All >> analog IOs are input and output capable. Headphone amplifiers are also >> integrated at each analog output. All analog IOs can be re-tasked >> according to user's definitions, or automatically switched to suit the >> connecting device (Universal Audio Jack®). >> >> Reserve analog mixer architecture is backwards compatible with AC'97 > > > > -- > -Joey Jiao -- -Joey Jiao

2 1

[alsa-devel] [PATCH] ASoC: wm8994: Use slow start for VMID
by Mark Brown 15 Feb '12

15 Feb '12

Improves performance on power up. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index e8f2396..b137ac9 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -794,7 +794,7 @@ static void vmid_reference(struct snd_soc_codec *codec) WM8994_BIAS_SRC | WM8994_STARTUP_BIAS_ENA | WM8994_VMID_BUF_ENA | - (0x3 << WM8994_VMID_RAMP_SHIFT)); + (0x2 << WM8994_VMID_RAMP_SHIFT)); wm_hubs_vmid_ena(codec); -- 1.7.9.rc1

1 0

Re: [alsa-devel] Bug report - patch_realtek.c - Laptop HP COMPAQ B1900 Series
by Jonathan Woithe 15 Feb '12

15 Feb '12

Hi Joey For future reference, please email reports like this to the alsa-devel list. The relevant developers are far more likely to respond to messages on the list than they are to messages sent privately. I have copied this to the list to maximise its distribution. On Sat, Feb 11, 2012 at 09:17:05AM +0800, joey.jiaojg wrote: > I'm reporting a bug related to ALSA and ALC260, which perhaps only > you can solve. Appreciate if you can check. > We got a lot of users using HP COMPAQ B1900 series which using ATI > SB450 and ALC260 for linux systems like Debian, Ubuntu and etc. The > problem is that there is no sound from speaker while enable > model=will can hear from earphone. The problem and alsa-info.txt is > reported here https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/186698, > which thought be a bug of ALC260 driver bug. > Hope you can check what we can do to solve it. _From the above I am not entirely sure what the problem is. You seem to be talking about two separate conditions. In the first (where I presume the module is loaded without any parameters you say there's no sound from the speaker. Do other aspects of the card work correctly in this case? The second situation is where "model=will" is specified as a module parameter. Here you say you can get audio from the headphone, but again what about other aspects of the soundcard - do they work normally? At a rough guess, it sounds like there are two underlying issues. The first is that this system requires some model-specific handing in order to map chip outputs correctly. The second is that if such model-specific details are required then the driver preferrably would activate these automatically without the need to specify "model=will". Another possibility is that there is something about this laptop system which is confusing the auto-probing of the alc260 codec code. I'm not sure what is the best way of proceeding here. I suspect other more active developers will have a streamlined approach to help rectify the trouble. In the first instance I would tend to load the module with "model=test" and experiment with the resulting alsamixer controls to determine what chip outputs are connected to which pins. However, this is quite "old school" now - while it's the approach I used when getting my system working, my impression is that its use has been mostly deprecated by the automatic parser which is now present. In the above-referenced launchpad report the question is asked about the ALC260 datasheet. This is readily available on the net. I doubt it is all that necessary now since I think the base infrastructure is pretty solid, but if you do need it and have difficulty finding it please contact me off-list. Regards jonathan

2 1