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

[alsa-devel] snd_hda_intel: Conexant CX20551 (Waikiki)
by Edwin Smulders 03 Jun '07

03 Jun '07

Hi, I believe there's still a problem with the HDA Intel chip Conexant CX20551 (Waikiki) not working. However, im not entirely sure the problem the problem is with alsa, because it starts working when i boot with acpi=off (a fix suggested on the ubuntu forums, but not quite useful on a laptop [plus, it breaks my ethernet]) The reason I'm mailing is, can you confirm this is something alsa can/should/will fix or are we all looking in the wrong direction and this is really an acpi problem? If you can fix this or know of something that might work, I would be happy to hear it. I've attached my lspci -nv and cat /proc/asound/card0/codec\#* just in case. I would be happy to give you any more info you might need. ~~ Edwin

2 2

[alsa-devel] [PATCH] Add support for another X-Fi Extreme Audio (really SB Live 24bit)
by Daniel T. Chen 03 Jun '07

03 Jun '07

Hi, Attached please find an hg changeset against current alsa-kernel tip. Thanks, Daniel Chen

2 2

[alsa-devel] Next steps
by chris＠idlelion.net 03 Jun '07

03 Jun '07

Hey gang, I'm trying to work on issue 305, suspend/resume for cs46xx. I'm running CentOS 5, so I'd like to work on what's current for that distribution first, and patch to latest if needed after that. I think I have the correct source package, but the only mention of cs46xx I could find in the source is a configuration file. Running make doesn't make the cs46xx module, AFAICT. Which source (package)(s) should I have? How do I track down the source file(s) I need to examine? Thanks, Chris

4 5

Re: [alsa-devel] ASoC and a codec that can't be controlled
by Timur Tabi 01 Jun '07

01 Jun '07

Liam Girdwood wrote: >> I guess I just don't understand why the codec driver is acting like the "master" driver of >> ASOC. IMHO, the codec driver should be doing two things: > > I guess this is due to an ordering issue we had during early > development. We had to make sure that the I2C probe of the codec > succeeded before registering the card, pcms, etc. Fwiw, I do intend to > address this in future versions (I should probably add a road map to the > wiki now). In that case, I think we can solve this problem as well as the PowerPC device tree problem in one shot, because they're basically the same problem. Anyway, let me see if I get this right: 1. The first function called is eti_b1_init(). 2. eti_b1_init() calls platform_device_add() to add an soc-audio class device and register the eti_b1_snd_devdata structure. 3. The registration causes a number of things to happen, one of which is a call to soc_probe(). 4. soc_probe() sees that the snd_soc_machine_eti_b1.probe is NULL, so that part is skipped. 3. soc_probe() sees that snd_soc_machine_eti_b1.dai_link->cpu_dai->probe is also NULL, so that part is skipped. (eti_b1_snd_devdata.machine == snd_soc_machine_eti_b1) 4. soc_probe() sees that soc_codec_dev_wm8731.probe is not NULL, so it calls wm8731_probe(). 5. wm8731_probe() registers an I2C driver. 6. The I2C class driver calls wm8731_i2c_driver.attach_adapter, which is wm8731_i2c_attach(). 7. wm8731_i2c_attach() calls i2c_probe(), which in turn calls wm8731_codec_probe() 8. wm8731_codec_probe() allocates a snd_soc_codec structure. 8. wm8731_codec_probe() calls wm8731_init(). This means that if there is no I2C support, wm8731_init() will never be called. 9. wm8731_init() initializes the snd_soc_codec structure. Question: why doesn't wm8731_probe() initialize the non-I2C parts of the snd_soc_codec structure? For example, snd_soc_codec.dai, snd_soc_codec.name, and snd_soc_codec.owner? That way, the snd_soc_codec structure will be properly initialized even when there's no I2C. 10. wm8731_init() calls snd_soc_new_pcms. 11. wm8731_init() exits, wm8731_codec_probe() exits, wm8731_i2c_attach() exits, and then wm8731_probe() exits. Control returns to soc_probe(). 12. soc_probe() notices that eti_b1_snd_devdata.platform.probe is NULL, so it skips that. Question: why don't you define a function for at91_soc_platform.probe, and in that function you can call snd_soc_new_pcms()? That way, you guarantee the codec driver's I2C interface is initialized before snd_soc_new_pcms() is called, and you avoid have PCM calls in the codec driver. >> ASOC and the machine driver should then work in tandem to decide which driver will do what >> and which capabilities are *actually* supported. *Something* needs to look at the entire >> system and say to each device, "Well, yes, I know about this little feature of yours, but >> we're just not going to support that today." >> > > The machine driver pretty much already does this. It can override valid > hardware configurations and return -EINVAl if required. Do you have an example of that? Would that be eti_b1_hw_params()? -- Timur Tabi Linux Kernel Developer @ Freescale

2 5

[alsa-devel] [1/3] 2.6.22-rc3: known regressions v2
by Michal Piotrowski 01 Jun '07

01 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Unclassified Subject : build failed in function `vic_sys_interrupt' References : http://lkml.org/lkml/2007/5/31/227 Submitter : Toralf Förster <toralf.foerster(a)gmx.de> Status : Unknown Subject : long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi <miklos(a)szeredi.hu> Handled-By : Ingo Molnar <mingo(a)elte.hu> Status : problem is being debugged ACPI Subject : unable to shutdown on kernel 2.6.22-rc2 References : http://bugzilla.kernel.org/show_bug.cgi?id=8516 Submitter : Thierry Volpiatto <tvolpiatt(a)neuf.fr> Status : Unknown ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Status : Unknown Networking Subject : b44: regression in 2.6.22 References : http://lkml.org/lkml/2007/5/27/108 Submitter : Maximilian Engelhardt <maxi(a)daemonizer.de> Handled-By : Michael Buesch <mb(a)bu3sch.de> Status : problem is being debugged Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej"

3 2

[alsa-devel] Configure problems for alsa-utils-1.0.4
by David Topper 01 Jun '07

01 Jun '07

So I've managed to compile alsa-drivers-1.0.4 for ARM. I can even load the modules. I've also successfully compiled alsa-libs-1.0.4 ... but I had to do it on the board. Cross compiling simply didn't seem to work. I've been using --prefix=/ and --exec-prefix=/ for configures. But when I do ./configure --prefix=/ --exec-prefix=/ for alsa-utils-1.0.4 it fails with: checking for libasound headers version >= 0.9.0... not present. configure: error: Sufficiently new version of libasound not found. But they're there, for sure. Perhaps it doesn't like looking in /include/alsa? Thanks, DT

1 0

[alsa-devel] snd_soc_dai_link.init()
by Timur Tabi 01 Jun '07

01 Jun '07

Liam, Why does the init() function pointer in the snd_soc_dai_link structure take a snd_soc_codec pointer? Wouldn't it make more sense for it to take a snd_soc_dai_link pointer? That way, I could use the init() function to initialize the structure. I'm trying to write a function that will initialize the codec_dai pointer. I thought I could use snd_soc_dai_link.init(), but I don't know how to get the pointer to the snd_soc_dai_link structure from a snd_soc_codec structure. /* SoC machine DAI configuration, glues a codec and cpu DAI together */ struct snd_soc_dai_link { char *name; /* Codec name */ char *stream_name; /* Stream name */ /* DAI */ struct snd_soc_codec_dai *codec_dai; struct snd_soc_cpu_dai *cpu_dai; /* machine stream operations */ struct snd_soc_ops *ops; /* codec/machine specific init - e.g. add machine controls */ int (*init)(struct snd_soc_codec *codec); }; -- Timur Tabi Linux Kernel Developer @ Freescale

2 7

[alsa-devel] Power management state flow in ALSA
by Nobin Mathew 01 Jun '07

01 Jun '07

I am having a doubt regarding ALSA power management. My understanding of APM suspend() is like this. Freeze the ALSA apps Call ALSA driver suspend () in the ALSA suspend() function it saves the current state of substream and changes the state of substream to SUSPENDED. My understanding of APM resume() is like this Call ALSA driver resume () Activate the ALSA apps In ALSA resume function it restores the saved state of substream. So my question is when ALSA app will get to know the SUSPENDED state of substream.??? I am using linux kernel 2.6.17 ALSA driver version 1.0.11rc4 ASoC patch version 0.12.4

3 9