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

[alsa-devel] Subject: [PATCH 1/1] set invalid dma channel to -1 (and properly check for it) since 0 is not an invalid channel but -1 is.
by sware 01 Jan '09

01 Jan '09

Set the invalid dma channel to -1 (and check properly for it) in pxa2xx_pcm_hw_free(). Was assuming 0 is an invalid channel number but 0 is a valid pxa dma channel num. Signed-off-by: stephen <stephen.ware(a)eqware.net> --- sound/soc/pxa/pxa2xx-pcm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-pcm.c b/sound/soc/pxa/pxa2xx-pcm.c index c670d08..53b9fb1 100644 --- a/sound/soc/pxa/pxa2xx-pcm.c +++ b/sound/soc/pxa/pxa2xx-pcm.c @@ -61,9 +61,9 @@ static int pxa2xx_pcm_hw_free(struct snd_pcm_substream *substream) __pxa2xx_pcm_hw_free(substream); - if (prtd->dma_ch) { + if (prtd->dma_ch >= 0) { pxa_free_dma(prtd->dma_ch); - prtd->dma_ch = 0; + prtd->dma_ch = -1; } return 0; -- 1.5.4.3

2 2

[alsa-devel] Control interconnection information API?
by Eliot Blennerhassett 01 Jan '09

01 Jan '09

New Year's Greetings, something that seems to be lacking in the ALSA API, or at least the way of describing controls (by name only), is any concept of the connectivity between the various controls and the codecs and output terminals. One use for such information is to build a GUI that shows this connectivity (instead of the current bucket'o'controls approach). Now there are a couple of special cases: * HDA driver exports the codec widget information via a proc file, allowing the codecgraph tool to visualise the connections. Widgets have numeric IDs and list the IDs of widgets that connect to their inputs. * ASoC DAPM (which I (not being an ASoC developer or user) have mostly been skimming over in this list). Reading this http://www.mjmwired.net/kernel/Documentation/sound/alsa/soc/dapm.txt 3. Codec Widget Interconnections. I can see that there are lists of connections. I'm not sure if these are visible to userspace via any API? So: Can either of these schemes be generalised to all ALSA drivers? Is there some other way to reveal the information (Connections TLV, new API etc?) Does anybody else thing this is worth pursuing, or is it just me? regards -- Eliot Blennerhassett AudioScience Inc

2 1

Re: [alsa-devel] 2.6.28-rc5 broke ALSA headphone output for my Toughbooks.
by Takashi Iwai 01 Jan '09

01 Jan '09

At Tue, 23 Dec 2008 10:44:50 -0500, Kyler Laird wrote: > > My Panasonic CF-74 Toughbooks do not play audio through the headphone > jack starting with 2.6.28-rc5. The patch below is only to illustrate > what changes I made to restore headphone jack functionality. I do not > suggest using this patch as part of the mainline kernel because it > reverts some code that I'm sure is important to other users. > > Output of the ALSA script aadebug follows the patch. > > I'm continuing to investigate but I wanted to get this out in case the > solution is obvious to someone else. It would be great to have a fix in > 2.6.28. (2.6.28 is the first series to support all of the hardware in > the Toughbook.) Please run alsa-info.sh with --no-upload option and attach the generated files on both the headphone plugged and unplugged. Also, run preferably on both (old) working and non-working kernels to compare. thanks, Takashi

1 0

Re: [alsa-devel] [PATCH 11/13] sound/usb: use USB API functions rather than constants
by Takashi Iwai 01 Jan '09

01 Jan '09

At Mon, 29 Dec 2008 11:23:02 +0100 (CET), Julia Lawall wrote: > > From: Julia Lawall <julia(a)diku.dk> > > This set of patches introduces calls to the following set of functions: > > usb_endpoint_dir_in(epd) > usb_endpoint_dir_out(epd) > usb_endpoint_is_bulk_in(epd) > usb_endpoint_is_bulk_out(epd) > usb_endpoint_is_int_in(epd) > usb_endpoint_is_int_out(epd) > usb_endpoint_num(epd) > usb_endpoint_type(epd) > usb_endpoint_xfer_bulk(epd) > usb_endpoint_xfer_control(epd) > usb_endpoint_xfer_int(epd) > usb_endpoint_xfer_isoc(epd) > > In some cases, introducing one of these functions is not possible, and it > just replaces an explicit integer value by one of the following constants: > > USB_ENDPOINT_XFER_BULK > USB_ENDPOINT_XFER_CONTROL > USB_ENDPOINT_XFER_INT > USB_ENDPOINT_XFER_ISOC > > An extract of the semantic patch that makes these changes is as follows: > (http://www.emn.fr/x-info/coccinelle/) > > // <smpl> > @r1@ struct usb_endpoint_descriptor *epd; @@ > > - ((epd->bmAttributes & \(USB_ENDPOINT_XFERTYPE_MASK\|3\)) == > - \(USB_ENDPOINT_XFER_CONTROL\|0\)) > + usb_endpoint_xfer_control(epd) > > @r5@ struct usb_endpoint_descriptor *epd; @@ > > - ((epd->bEndpointAddress & \(USB_ENDPOINT_DIR_MASK\|0x80\)) == > - \(USB_DIR_IN\|0x80\)) > + usb_endpoint_dir_in(epd) > > @inc@ > @@ > > #include <linux/usb.h> > > @depends on !inc && (r1||r5)@ > @@ > > + #include <linux/usb.h> > #include <linux/usb/...> > // </smpl> > > Signed-off-by: Julia Lawall <julia(a)diku.dk> Applied now. Thanks. Takashi

1 0

[alsa-devel] [PATCH] hda - fix name for ALC1200
by Wu Fengguang 01 Jan '09

01 Jan '09

On Thu, Dec 25, 2008 at 03:13:58PM +0200, Thomas Schneider wrote: > Hi, > > here is the output from alsa-info.sh > > http://www.alsa-project.org/db/?f=8282910dc807e1f141896886cd5f8fd574117000 > > I found another small mistake. In the Mixer my Soundcard is shown as "Realtek ALC888". > When i switch this to lines in patch_realtek.c then it is shown as "Realtek ALC1200". > > > static struct hda_codec_preset snd_hda_preset_realtek[] = { > ...... > > { .id = 0x10ec0888, .name = "ALC888", .patch = patch_alc883 }, > { .id = 0x10ec0888, .rev = 0x100101, .name = "ALC1200", > .patch = patch_alc883 }, > > ..... Good catch! Reversing the order should fix the name. Thanks, Fengguang --- hda - fix name for ALC1200 Move the more specific preset for ALC1200 above the general one for ALC888, so that it will have the chance to get matched and selected. Reported-by: Thomas Schneider <nailstudio(a)gmx.net> Signed-off-by: Wu Fengguang <fengguang.wu(a)intel.com> --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- sound-2.6.orig/sound/pci/hda/patch_realtek.c +++ sound-2.6/sound/pci/hda/patch_realtek.c @@ -16638,9 +16638,9 @@ static struct hda_codec_preset snd_hda_p .patch = patch_alc882 }, /* should be patch_alc883() in future */ { .id = 0x10ec0885, .name = "ALC885", .patch = patch_alc882 }, { .id = 0x10ec0887, .name = "ALC887", .patch = patch_alc883 }, - { .id = 0x10ec0888, .name = "ALC888", .patch = patch_alc883 }, { .id = 0x10ec0888, .rev = 0x100101, .name = "ALC1200", .patch = patch_alc883 }, + { .id = 0x10ec0888, .name = "ALC888", .patch = patch_alc883 }, { .id = 0x10ec0889, .name = "ALC889", .patch = patch_alc883 }, {} /* terminator */ };

2 1

[alsa-devel] [PATCH] ALSA: hda - Add HP Acacia detection
by Chris Bagwell 01 Jan '09

01 Jan '09

Add automatic mapping of HP Acacia motherboards to 3stack-hp. Allows for greater then 2 channel audio by enabling Channel Mode option in mixer. Motherboard specs: http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01321559&lc=en&dlc=en&… Signed-off-by: Chris Bagwell <chris at cnpbagwell dot com> diff --git a/pci/hda/patch_realtek.c b/pci/hda/patch_realtek.c index 4afa0c9..410be84 100644 --- a/pci/hda/patch_realtek.c +++ b/pci/hda/patch_realtek.c @@ -8444,6 +8444,7 @@ static struct snd_pci_quirk alc883_cfg_tbl[] = { SND_PCI_QUIRK(0x103c, 0x2a4f, "HP Samba", ALC888_3ST_HP), SND_PCI_QUIRK(0x103c, 0x2a60, "HP Lucknow", ALC888_3ST_HP), SND_PCI_QUIRK(0x103c, 0x2a61, "HP Nettle", ALC883_6ST_DIG), + SND_PCI_QUIRK(0x103c, 0x2a66, "HP Acacia", ALC888_3ST_HP), SND_PCI_QUIRK(0x1043, 0x1873, "Asus M90V", ALC888_ASUS_M90V), SND_PCI_QUIRK(0x1043, 0x8249, "Asus M2A-VM HDMI", ALC883_3ST_6ch_DIG), SND_PCI_QUIRK(0x1043, 0x82fe, "Asus P5Q-EM HDMI", ALC1200_ASUS_P5Q),

2 1

Re: [alsa-devel] 2.6.28: hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
by Takashi Iwai 01 Jan '09

01 Jan '09

At Tue, 30 Dec 2008 07:28:14 -0500 (EST), Justin Piszcz wrote: > > On Tue, 30 Dec 2008, Justin Piszcz wrote: > > > The audio for this board works fine, there are no issues, but there are some > > cosmetic issues when the driver loads: > > > > 1. Unknown model. It's no bug. It's neither warning nor error message but a information message. > > 2. Wrong model number. They likely share the same ID and compatible. So don't worry about it. In short, nothing to fix, so far. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

1 0