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

Re: [alsa-devel] Asus E35M1-M Pro and Realtek AL887-VD - no love from ALSA for Sourround
by Raymond Yau 25 Mar '11

25 Mar '11

>> I recently purchased *Asus* *e35M1*-*M* *Pro* and I would like to get souround >> sound going fro*m* *m*y 5.1 syste*m*. I have it connected accordingly to the *>> m*anual (line in - rear speakers, line out - front speaker, *m*ic in - >> bass/center) but anywy I try that is using guides like >> http://www.gentoo-wiki.info/HOWTO_Surround_Sound <http://www.gentoo-wiki.info/HOWTO_Surround_Sound> I a*m* *no*t able to get >> sound fro*m* any other speaker then front left and right one. *Alsa**m*ixer >> does *no*t show any devices as shared to be available to switch to the >> output fro*m* input >> speaker-test plays every file in the left and right front speaker at the >> sa*m*e ti*m*e >> Here is *m*y syste*m* infor*m*ation using 2.6.38-rc8-git3 >> http://www.*alsa*-*pro*ject.org/db/?f=0dd55b4640a8afff1552c4d0be0105e416ad1… <http://www.alsa-project.org/db/?f=0dd55b4640a8afff1552c4d0be0105e416ad1cf3> >> and 2.6.38-rc8-next-20110314 >> http://www.*alsa*-*pro*ject.org/db/?f=a8733bf0083929540948f51b5f33d9c8a62d9… <http://www.alsa-project.org/db/?f=a8733bf0083929540948f51b5f33d9c8a62d9994> *>> M*y question is what should I try next? Any desktop motherboard with 3 jacks in rear panel should use "3stack-6ch" to support analog surround51 or "3stack-6ch-dig" to analog surround51 and digital out

1 0

[alsa-devel] driver silence callback
by Eliot Blennerhassett 24 Mar '11

24 Mar '11

Greetings, Is the driver's silence callback meant to be able to *overwrite* some part of the audio buffer that has already been written e.g. via the playback *copy* callback? In the case of my (older) hardware, once audio has been written via the copy callback, it is gone (into a fifo), there is no way to overwrite with silence. The asihpi silence call back will _append_ a period of silence to the already written audio queue. I'm wondering if this is wrong? Perhaps I should not have a silence callback at all? I'm looking at the case in pcm_lib.c snd_pcm_playback_silence() where "when runtime->silence_size >= runtime->boundary - fill processed area with silence immediately" My reference for silence callback. http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch11s02.html regards Eliot

2 2

[alsa-devel] [PATCH] TerraTec DMX 6Fire USB: Don't leak firmware when usb6fire_fw_ihex_init() fails.
by Jesper Juhl 24 Mar '11

24 Mar '11

We need to release_firmware() what we request_firmware()'ed when usb6fire_fw_ihex_init() fails or we'll leak memory. Signed-off-by: Jesper Juhl <jj(a)chaosbits.net> --- firmware.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/usb/6fire/firmware.c b/sound/usb/6fire/firmware.c index 9081a54..2761392 100644 --- a/sound/usb/6fire/firmware.c +++ b/sound/usb/6fire/firmware.c @@ -254,6 +254,7 @@ static int usb6fire_fw_ezusb_upload( ret = usb6fire_fw_ihex_init(fw, rec); if (ret < 0) { kfree(rec); + release_firmware(fw); snd_printk(KERN_ERR PREFIX "error validating ezusb " "firmware %s.\n", fwname); return ret; -- Jesper Juhl <jj(a)chaosbits.net> http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please.

1 0

[alsa-devel] [PATCH] ASoC: Add max98095 CODEC driver
by Peter Hsiang 24 Mar '11

24 Mar '11

This patch adds the MAX98095 CODEC driver. Signed-off-by: Peter Hsiang <peter.hsiang(a)maxim-ic.com> Please see the attached patch file 0001-ASoC-Add-max98095-CODEC-driver.patch Thanks, Peter

3 2

[alsa-devel] Coverity tool reported issues related patches
by sudarshan.bisht＠nokia.com 24 Mar '11

24 Mar '11

Hi, Few days back I sent some patches for review and you reviewed them, after incorporating review comments I sent updated patches too. So I just wanted to know that the way I sent them was right ? And when will those patches be incorporated to alsa-lib upstream ? If something has to be done from my side then please let me know. Br, Sudarshan Bisht

2 1

Re: [alsa-devel] 答复: [PATCH 7/16] ALSA: VIA HDA: Modify notify_aa_path_ctls() function
by Takashi Iwai 24 Mar '11

24 Mar '11

At Thu, 24 Mar 2011 15:32:51 +0800, <LydiaWang(a)viatech.com.cn> wrote: > > > > > -----邮件原件----- > > 发件人: Takashi Iwai [mailto:tiwai@suse.de] > > 发送时间: 2011年3月21日 19:08 > > 收件人: Jaroslav Kysela > > 抄送: Lydia Wang; alsa-devel(a)alsa-project.org; Harald Welte > > 主题: Re: [alsa-devel] [PATCH 7/16] ALSA: VIA HDA: Modify notify_aa_path_ctls() > > function > > > > At Mon, 21 Mar 2011 08:32:43 +0100 (CET), > > Jaroslav Kysela wrote: > > > > > > On Mon, 21 Mar 2011, Lydia Wang wrote: > > > > > > > From: Lydia Wang <lydiawang(a)viatech.com.cn> > > > > Subject: ALSA: VIA HDA: Modify notify_aa_path_ctls() function. > > > > > > > > Modify notify_aa_path_ctls() function to get volume control items name > > > > dynamically instead of by giving static item name. > > > > > > This code looks ugly to me. If you like to have a dynamic set of notified > > > controls, create one using snd_array in via_spec. > > > > Agreed. The current code is too fragile. > > > > > > thanks, > > > > Takashi > > I've created such control type of snd_array. When I want to update a-a path volume and mute control, I must find out the controls among all such ones. But in new alsa driver, I found the mic's a-a path name will be mic, or rear mic according to its pin position. In old driver, the a-a path name is static, but now it's dynamic. So I write this function to find out the actual name of controls. I'm not very clear why it's ugly. Please tell me. Thank you! First off, looking over all controls of the card instance isn't considered as a valid task for the local codec driver. If such a feature is inevitably necessary, we should implement a helper function in ALSA core. Secondly, the controls you look at might not belong to your codec. HD-audio bus can contain multiple codecs, and it might come from some others. HD-audio codec has already an array of mixer elements. codec->mixers is an array for struct hda_nid_item. You can use this instead for look-up. If more performance optimization is needed, create another local array to point only the needed kctls. thanks, Takashi

1 0

[alsa-devel] Bad file descriptor : -EBADFD
by Irfan Shaikh 24 Mar '11

24 Mar '11

Hello In the below logic, snd_pcm_write always returns -EBADFD . snd_pcm_writei not at all recovers from this state infinitly. How can i solve this problem. while(1) { /*Read from capture device*/ snd_pcm_writei(() if(error) xrun_recovery(pAlsaConfigP->playback_handle, retVal); } **** ERROR values returned from snd_pcm_writei: Only forst time : -11 Follwed by -EBADFD always static int xrun_recovery(snd_pcm_t *handle, int err) { if (err == -EPIPE) { /* under-run */ err = snd_pcm_prepare(handle); if (err < 0) printf("Can't recovery from underrun, prepare failed: %s\n", snd_strerror(err)); return 0; } else if (err == -ESTRPIPE) { while ((err = snd_pcm_resume(handle)) == -EAGAIN) sleep(1); /* wait until the suspend flag is released */ if (err < 0) { err = snd_pcm_prepare(handle); if (err < 0) printf("Can't recovery from suspend, prepare failed: %s\n", snd_strerror(err)); } return 0; } return err; } SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

2 5

[alsa-devel] [PATCH 0/6] ALSA: VIA HDA: patch series
by Lydia Wang 24 Mar '11

24 Mar '11

Following patch series mainly includes: -fix side channel mute invalid issue of VT2002P, VT1812 and VT1802 -add VT1802 check in via_speaker_automute function -update VT1708 initial verbs -update VT1718S initial verbs -update VT2002P initial verbs -update unsolicited event function to process more events

2 1

[alsa-devel] [PATCH 6/6] ALSA: VIA HDA: Update unsolicited event function
by Lydia Wang 24 Mar '11

24 Mar '11

From: Lydia Wang <lydiawang(a)viatech.com.cn> Subject: ALSA: VIA HDA: Update unsolicited event function. Update unsolicited event process function via_unsol_event() to make it can process more unsolicited events. Signed-off-by: Lydia Wang <lydiawang(a)viatech.com.cn> --- sound/pci/hda/patch_via.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -234,12 +234,12 @@ return codec_type; }; +#define VIA_JACK_EVENT 0x20 #define VIA_HP_EVENT 0x01 #define VIA_GPIO_EVENT 0x02 -#define VIA_JACK_EVENT 0x04 -#define VIA_MONO_EVENT 0x08 -#define VIA_SPEAKER_EVENT 0x10 -#define VIA_BIND_HP_EVENT 0x20 +#define VIA_MONO_EVENT 0x03 +#define VIA_SPEAKER_EVENT 0x04 +#define VIA_BIND_HP_EVENT 0x05 enum { VIA_CTL_WIDGET_VOL, @@ -1746,17 +1746,21 @@ unsigned int res) { res >>= 26; - if (res & VIA_HP_EVENT) - via_hp_automute(codec); - if (res & VIA_GPIO_EVENT) - via_gpio_control(codec); + if (res & VIA_JACK_EVENT) set_widgets_power_state(codec); - if (res & VIA_MONO_EVENT) + + res &= ~VIA_JACK_EVENT; + + if (res == VIA_HP_EVENT) + via_hp_automute(codec); + else if (res == VIA_GPIO_EVENT) + via_gpio_control(codec); + else if (res == VIA_MONO_EVENT) via_mono_automute(codec); - if (res & VIA_SPEAKER_EVENT) + else if (res == VIA_SPEAKER_EVENT) via_speaker_automute(codec); - if (res & VIA_BIND_HP_EVENT) + else if (res == VIA_BIND_HP_EVENT) via_hp_bind_automute(codec); }

1 0

[alsa-devel] [PATCH 5/6] ALSA: VIA HDA: Update VT2002P initial verbs
by Lydia Wang 24 Mar '11

24 Mar '11

From: Lydia Wang <lydiawang(a)viatech.com.cn> Subject: ALSA: VIA HDA: Update VT2002P initial verbs. Add some hardware related verbs in VT2002P initial verbs. These verbs are used to fix Class-D speaker no sound issue. Signed-off-by: Lydia Wang <lydiawang(a)viatech.com.cn> --- sound/pci/hda/patch_via.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -5267,6 +5267,10 @@ }; static struct hda_verb vt2002P_volume_init_verbs[] = { + /* Class-D speaker related verbs */ + {0x1, 0xfe0, 0x4}, + {0x1, 0xfe9, 0x80}, + {0x1, 0xfe2, 0x22}, /* * Unmute ADC0-1 and set the default input to mic-in */

1 0