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

[alsa-devel] distinguish events based on input ports
by Lieven Moors 21 Jul '09

21 Jul '09

Hi everybody, I've just started writing my first little program with alsa, and I had a question regarding the use of input(read) ports. What I want to do is distinguish events based on the input port they came through. Since the destination of the event is mostly set to 'broadcast', I cannot extract this information from the event itself. I would like to know if there is another way to do this, or if it is simply impossible. Thanks for your help, Greetings, Lieven

2 1

[alsa-devel] Testers wanted: New SB X-Fi driver
by Matthias Diehl 21 Jul '09

21 Jul '09

> At Tue, 30 Jun 2009 16:10:45 +0200, > Matthias Diehl wrote: > > > > hi, > > > > i guess you dont speak german, do you? well, i'll try it in > english ;-) > > > > i tried to install your newest x-fi "hack" in ubuntu 9.04 64bit. > it's an x-fi extreme music. i downloaded this snapshot: >> > ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-uns… > > Use alsa-driver-snapshot.tar.gz instead of the unstable one. > > > while the installation process there are some warnings. after > replacing the demon.conf and reboot there was no sound. > > > > then i noticed the sentence "Note that the ctxfi driver might > conflict with the HD-audio driver" in the description. i think my > problem is the hdmi soundchip from my graphics adapter (sapphire > radeon hd 4870) which was automatically installed at the > ubuntu-installation > ("hda intel sound"). > > You are likely looking at irrelevant things. > > There are several variants of X-Fi boards. Many of them are equipped > with emu20k1 or emu20k2 chip. Some of these models can behave as > HD-audio compatible, too. These are supported by snd-ctxfi driver. > > In addition, there is X-Fi models that are without emu20k1/emu20k2 > chips. Some of them (CA0110-IBG) behave only as a HD-audio device, > and some others are with CA0106 chip. The former is supported by > snd-hda-intel driver and the latter by snd-ca0106 driver. > > So, they cannot be deactivated. The only question is whether you have > emu20k1/emu20k2 chip on your board. And this can be checked when you > load snd-ctxfi driver. If the driver is properly loaded and the > card instance is created (see /proc/asound/cards), then it's good. > Otherwise, your board is no such one. You need other drivers. > > Please ask further questions on alsa-devel ML (you can add me to Cc, > though) so that other people with your board can advice better. > > > HTH, > > Takashi hi there, i now tried to install the stable version, but i have still no sound. here's what lspci | grep audio says: 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio 05:00.0 Multimedia audio controller: Creative Labs SB X-Fi lsmod | grep snd says: snd_hda_intel 557492 1 snd_pcm_oss 52352 0 snd_mixer_oss 24960 2 snd_pcm_oss snd_pcm 99336 2 snd_hda_intel,snd_pcm_oss snd_seq_dummy 11524 0 snd_seq_oss 41984 0 snd_seq_midi 15744 0 snd_rawmidi 33920 1 snd_seq_midi snd_seq_midi_event 16512 2 snd_seq_oss,snd_seq_midi snd_seq 66272 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 34064 2 snd_pcm,snd_seq snd_seq_device 16276 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq snd 78792 9 snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 16800 2 snd snd_page_alloc 18704 2 snd_hda_intel,snd_pcm cat /proc/asound/cards says: 0 [HDMI ]: HDA-Intel - HDA ATI HDMI HDA ATI HDMI at 0xf7dfc000 irq 17 i hope, someone can help me ... greetings from germany, matthias

4 3

[alsa-devel] Two Codecs in the machine driver
by Olaya, Margarita 21 Jul '09

21 Jul '09

Hi all, I have a hardware platform which has two codecs and I want to create a SoC machine driver to connect them to the processor, but it's not clear to me how to do that. Do you have any suggestions? Is there any driver that I can see as an example? Thanks & Regards, Margarita

2 1

Re: [alsa-devel] Testers wanted: New SB X-Fi driver
by Takashi Iwai 21 Jul '09

21 Jul '09

At Thu, 16 Jul 2009 12:19:15 +0200, Frashman wrote: > > Takashi Iwai schrieb: > > At Wed, 15 Jul 2009 12:55:23 +0200, > > Frashman wrote: > > > >> Hi Takashi, > >> > >> first of all, thank you for developing this driver. > >> I tested it today. It works, so far. > >> > >> But two annoying things. As you mentioned, I got problems, if the > >> onboard sound modules are loaded. Then i get no sound out auf my xfi. > >> > > > > It's likely the collision of PCI device ID. > > Some X-Fi models support both HD-audio and emu20kx-native modes. The > > modes are switched by some magical sequence. > > > > Anyway, please run alsa-info.sh with --no-upload option, and attach > > the generated file. > > > I let the kernel auto probe all sound modules and generated then the > alsa-info.txt > It's attached. The PCI ID looks different from what snd-hda-intel driver supports. When compiled together with snd-ctxfi, snd-hda-intel only probes PCI ID 1002:0009. Are you sure that it's hda-intel that interferes the xfi? Any relevant kernel messages or asound entry when this happens? Takashi

2 2

Re: [alsa-devel] [PATCH 2/2] Add possibility to control the GPIO_STATUS shift
by Mark Brown 21 Jul '09

21 Jul '09

On Fri, Jul 17, 2009 at 04:45:21PM +0200, Marek Vasut wrote: > From 1ea286d088993e05b5b374a08ee6f933242d3561 Mon Sep 17 00:00:00 2001 > From: Marek Vasut <marek.vasut(a)gmail.com> > Date: Thu, 4 Jun 2009 21:56:59 +0200 > Subject: [PATCH 2/2] Add possibility to control the GPIO_STATUS shift > > This patch allows tweaking the behaviour of GPIO_STATUS register > shift quirk that's in wm97xx-core. The problem with GPIO_STATUS > register being shifted by one doesn't appear on all hardware it > seems and causes problems with accelerated touchscreen drivers on > Palm hardware. Therefore an accelerated touchscreen driver can select > if the shift is/isn't happening on the hardware. Acked-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > > Signed-off-by: Marek Vasut <marek.vasut(a)gmail.com> > --- > drivers/input/touchscreen/mainstone-wm97xx.c | 3 +++ > drivers/input/touchscreen/wm97xx-core.c | 6 ++++-- > include/linux/wm97xx.h | 7 +++++++ > 3 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/touchscreen/mainstone-wm97xx.c b/drivers/input/touchscreen/mainstone-wm97xx.c > index de02f87..e000ab3 100644 > --- a/drivers/input/touchscreen/mainstone-wm97xx.c > +++ b/drivers/input/touchscreen/mainstone-wm97xx.c > @@ -198,6 +198,9 @@ static int wm97xx_acc_startup(struct wm97xx *wm) > if (machine_is_palmt5() || machine_is_palmtx() || machine_is_palmld()) { > pen_int = 1; > irq = 27; > + /* There is some obscure mutant of WM9712 interbred with WM9713 > + * used on Palm HW */ > + wm->variant = WM97xx_WM1613; > } else if (machine_is_mainstone() && pen_int) > irq = 4; > > diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c > index 2957d48..252eb11 100644 > --- a/drivers/input/touchscreen/wm97xx-core.c > +++ b/drivers/input/touchscreen/wm97xx-core.c > @@ -204,7 +204,7 @@ void wm97xx_set_gpio(struct wm97xx *wm, u32 gpio, > else > reg &= ~gpio; > > - if (wm->id == WM9712_ID2) > + if (wm->id == WM9712_ID2 && wm->variant != WM97xx_WM1613) > wm97xx_reg_write(wm, AC97_GPIO_STATUS, reg << 1); > else > wm97xx_reg_write(wm, AC97_GPIO_STATUS, reg); > @@ -307,7 +307,7 @@ static void wm97xx_pen_irq_worker(struct work_struct *work) > WM97XX_GPIO_13); > } > > - if (wm->id == WM9712_ID2) > + if (wm->id == WM9712_ID2 && wm->variant != WM97xx_WM1613) > wm97xx_reg_write(wm, AC97_GPIO_STATUS, (status & > ~WM97XX_GPIO_13) << 1); > else > @@ -582,6 +582,8 @@ static int wm97xx_probe(struct device *dev) > > wm->id = wm97xx_reg_read(wm, AC97_VENDOR_ID2); > > + wm->variant = WM97xx_GENERIC; > + > dev_info(wm->dev, "detected a wm97%02x codec\n", wm->id & 0xff); > > switch (wm->id & 0xff) { > diff --git a/include/linux/wm97xx.h b/include/linux/wm97xx.h > index 6f69968..0c98781 100644 > --- a/include/linux/wm97xx.h > +++ b/include/linux/wm97xx.h > @@ -16,6 +16,12 @@ > #include <linux/platform_device.h> > > /* > + * WM97xx variants > + */ > +#define WM97xx_GENERIC 0x0000 > +#define WM97xx_WM1613 0x1613 > + > +/* > * WM97xx AC97 Touchscreen registers > */ > #define AC97_WM97XX_DIGITISER1 0x76 > @@ -283,6 +289,7 @@ struct wm97xx { > unsigned pen_is_down:1; /* Pen is down */ > unsigned aux_waiting:1; /* aux measurement waiting */ > unsigned pen_probably_down:1; /* used in polling mode */ > + u16 variant; /* WM97xx chip variant */ > u16 suspend_mode; /* PRP in suspend mode */ > }; > > -- > 1.6.3.3 >

2 1

[alsa-devel] [PATCH 0/2]ad1938 dai and board driver clean-up according to feedback
by Barry Song 20 Jul '09

20 Jul '09

Hi Mark, Update bf5xx-tdm dai(patch 1) and bf5xx-ad1938 machine(patch 2) drivers according to your feedback. Thanks Barry

3 4

[alsa-devel] [PATCH] ALSA: hda - Add quirk for Gateway T6834c laptop
by 宋浩 20 Jul '09

20 Jul '09

From: Hao Song <baritono.tux(a)gmail.com> Gateway T6834c laptops need EAPD always on while the default behavior for the STAC9205 reference board is to turn it off upon every HP plug. By using the special "eapd" model, which is first introduced for Gateway T1616 laptops for this same reason, this peculiarity can be properly handled. Signed-off-by: Hao Song <baritono.tux(a)gmail.com> --- sound/pci/hda/patch_sigmatel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 41b5b3a..d9efe5c 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -2379,6 +2379,7 @@ static struct snd_pci_quirk stac9205_cfg_tbl[] = { "Dell Vostro 1500", STAC_9205_DELL_M42), /* Gateway */ SND_PCI_QUIRK(0x107b, 0x0565, "Gateway T1616", STAC_9205_EAPD), + SND_PCI_QUIRK(0x107b, 0x0560, "Gateway T6834c", STAC_9205_EAPD), {} /* terminator */ }; -- 1.6.0.4 -- 宋浩 Song, Hao Institute of Theoretical Computer Science and Communications Room 117, Ho Sin Hang Engineering Building Chinese University of Hong Kong, Hong Kong, P.R.China E-mail: baritono.tux(a)gmail.com Office Tel: (+8600852)-31634255

2 1

Re: [alsa-devel] New Audio Driver Design
by Daniel Mack 20 Jul '09

20 Jul '09

On Thu, Jul 16, 2009 at 09:13:28AM +0900, jassi brar wrote: > On Thu, Jul 16, 2009 at 5:22 AM, Daniel Mack <daniel(a)caiaq.de> wrote: > > Are these decoder instruction something you need to do at runtime? Or > > would it suffice to provide them once when the driver is probed? > > The decoder insn, params atleast, depend upon the mp3 file i want the dsp to > decode and play. > So, let us assume, i have to load decoder insns and params into the dsp for > every mp3 file playback. Then the alsa control API seems appropriate. Unless there is any other interface for that specific purpose I'm not aware of. > Also, by what interface name(like I2S/PCM/AC97) shud my driver get encoded > mp3 data from my mp3-player and then decode that mp3 data by dsp and play > the output pcm stream? > I am afraid i must bypass/hack ALSA stack to directly get mp3 data from > user-space. Am i right? Have a look at include/sound/pcm.h - there are more formats defined than just linear PCM, and I think SNDRV_PCM_FMTBIT_MPEG could be something you can use. But I'm not sure and never used something like that before, so maybe anyone else can elaborate more? Daniel

1 0

[alsa-devel] CS42L52 codec
by Anna White 20 Jul '09

20 Jul '09

Hello, I am working with CS42L52 codec under Linux. I have CS42L52 driver code, but I need ALSA configuration files. Does somebody have ALSA configuration files ? Or recomendation how to write them ? Thanks for responces. P.S. It may be related to thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-February/006130.h…

2 1

Re: [alsa-devel] [PATCH] hda: add bounds checking for the codec command fields v2
by Wu Fengguang 20 Jul '09

20 Jul '09

On Fri, Jul 17, 2009 at 06:46:01PM +0800, Takashi Iwai wrote: > At Fri, 17 Jul 2009 18:41:05 +0800, > Guo, Chaohong wrote: > > > > Although it does address this issue, I am not comfortable with this fixing. > > It seems more like a workaround than fix. > > No, it's rather for catching a bug. This is definitely neither > "workaround" nor "fix". Yes, I wrote this mainly for catching unknown bugs. > > Moreover, if long format node > > ID is used in the future, the code will cause little trouble for maintaining. > > Well, the current code doesn't support the long id (as the restriction > of HD-audio controller side), so we'd need major changes in anyway. > Thus this check is no big issue for maintenance, at least to me :) Does the HDA spec define cmd format that accept long form NID? If so, can you point me to the specific location please? Thanks. > > what I want is to fix it during parsing connection list, and verify the node > > id is valid there . > > Heh, this was already fixed :) AFAIK, snd_hda_get_connections() won't return NIDs bigger than 0x7f(short) or 0x7ffff(long). Thanks, Fengguang

2 1