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

[alsa-devel] [PATCH] Add sequence parsing for speaker-outs in snd_hda_parse_pin_def_config()
by Steve Longerbeam 07 May '07

07 May '07

2 2

Re: [alsa-devel] Getting Started on Alsa
by Ash Willis 07 May '07

07 May '07

Hi Chris, > I'd like to take action on bug #305, since it's my own itch. I've done very > low-level programming, but not on Linux device drivers. I'm very familiar > with command line development tools. > If you're not familiar with drivers or audio drivers in particular then reading Writing an ALSA Driver by Takashi Iwai might be a good place to start. You're referring to the suspend/resume bug in the cs46xx driver, right? Maybe try dumping all the registers while it's working and dumping them while it's broken and comparing the two sets of data? I guess the suspend function is doing something that it shouldn't be, or the resume function isn't doing something that it should be...good luck on finding out what that is. Ash =

3 2

Re: [alsa-devel] Getting Started on Alsa
by Ash Willis 07 May '07

07 May '07

> Thanks for the tips, Ash. I've found the Iwai document. Now there's some > light reading. I take it that it's still relevant, even though it hasn't > been updated since 2005. > I haven't actually read it since 2005 I'm afraid :) but I don't think anything's changed that drastically. The fundamentals are all there. > Yes, the cs46xx driver. That chip is in a lot of machines (at least ten > ThinkPad models), and with this bug nobody running Alsa likes Linux very > much. > Yeah, it's a pretty poor show that this bug has existed for so long. Let's hope you can zap it! > Is there some (handy) way to dump the registers from DOS or Windows as a > comparison? > Well, that depends. I'm not familiar with the hardware. There's a Windows program called PCItree. It allows you to view the current status of the ioport of a chosen device. Now, that's pretty handy if the regs for the card are mapped directly onto the io port. It's usually the case though, I think, that the registers aren't just mapped on and you'll need to query the card. If they're not mapped onto the io port (and forgive me again - not familiar with this chip) then you could use a debugger such as Numega SoftIce to manually issue queries to find out the contents of the registers. Sounds like a happy fun time. Writing the code to do a reg dump might be fun too. You may also want to use a debugger/disassembler with Windows (or other) drivers in order to find out what those drivers do to the card on resume. > For development: Since the drivers go into the kernel, I should be able to > find a page on getting a development environment set up... right? I'm You don't need to mess with the kernel as ALSA is available as a package. All you really need is the latest copy of alsa-driver and a compiler and you're good to go. Ash =

1 0

[alsa-devel] 1.0.14~rc4 prepared for upload.
by Elimar Riesebieter 06 May '07

06 May '07

As the compile errors in alsa-lib fixed I've preparded 1.0.14~rc4 (svn r1849) for upload: alsa-driver alsa-lib alsa-oss alsa-plugins alsa-utils alsa-tools stays still as 1.0.13~rc3. Jordi, could you please upload? Now I go for a beer ;) Elimar -- You cannot propel yourself forward by patting yourself on the back.

1 1

[alsa-devel] Getting Started on Alsa
by Chris Schumann 06 May '07

06 May '07

Hello, I'd like to take action on bug #305, since it's my own itch. I've done very low-level programming, but not on Linux device drivers. I'm very familiar with command line development tools. Is there any documentation on how to get started doing bugfixes or development for Alsa, or do I just look for source and start hacking? Thanks, Chrs

1 0

[alsa-devel] [PATCH] hda_codec: restore control element values during resume
by Daniel Drake 06 May '07

06 May '07

After resume from suspend-to-RAM, there is no sound output from my Intel HDA hardware: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Found in a Dell Inspiron 640m, SigmaTel STAC9200 chip. After resuming, sound immediately returns when you adjust the volume one notch in either direction. I reported this on the ALSA bug tracker (#0002989). Further investigation shows that the AC_VERB_SET_AMP_GAIN_MUTE verb is not being executed during resume, which seems strange. Does other hardware really store this value during a suspend/resume cycle? Or maybe the volume is generally controlled through other means on other setups? I'm not entirely sure what the difference is between kcontrol and kcontrol_new structures, but I note that there is already some code to restore the values for kcontrol_new elements. I solved the issue with the following patch. Is it correct? Signed-off-by: Daniel Drake <dsd(a)gentoo.org> Index: linux-2.6/sound/pci/hda/hda_codec.c =================================================================== --- linux-2.6.orig/sound/pci/hda/hda_codec.c +++ linux-2.6/sound/pci/hda/hda_codec.c @@ -2248,15 +2248,39 @@ EXPORT_SYMBOL(snd_hda_suspend); int snd_hda_resume(struct hda_bus *bus) { struct list_head *p; + struct snd_ctl_elem_value *val = kmalloc(sizeof(*val), GFP_KERNEL); + + if (!val) + return -ENOMEM; list_for_each(p, &bus->codec_list) { struct hda_codec *codec = list_entry(p, struct hda_codec, list); + struct snd_kcontrol *kctl; + + codec->in_resume = 1; + hda_set_power_state(codec, codec->afg ? codec->afg : codec->mfg, AC_PWRST_D0); + + + list_for_each_entry(kctl, &bus->card->controls, list) { + memset(val, 0, sizeof(*val)); + val->id = kctl->id; + /* Assume that get callback reads only from cache, + * not accessing the real hardware + */ + if (snd_ctl_elem_read(bus->card, val) < 0) + continue; + snd_ctl_elem_write(bus->card, NULL, val); + } + if (codec->patch_ops.resume) codec->patch_ops.resume(codec); + + codec->in_resume = 0; } + kfree(val); return 0; }

2 4

[alsa-devel] New Soundcard Matrix
by Jaroslav Kysela 05 May '07

05 May '07

Hello all, I moved the contents of matrix from XML files to Wiki - see http://bugtrack.alsa-project.org/main/index.php/Matrix:Main Please, no more updates to old matrix now. I left the information structure (we can update it later): Vendor -> Device -> ALSA Module If any volunteers are watching this list, we have many "wanted" pages now: http://bugtrack.alsa-project.org/main/index.php/Special:Wantedpages Example page for Matrix:Tag-* : http://bugtrack.alsa-project.org/main/index.php?title=Matrix:Tag-PCI&action… Example page for Matrix:Module-* : http://bugtrack.alsa-project.org/main/index.php?title=Matrix:Module-ali5451… Jaroslav ----- Jaroslav Kysela <perex(a)suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs

1 0

Re: [alsa-devel] Wiki Site
by Jaroslav Kysela 05 May '07

05 May '07

On Fri, 4 May 2007, cameron porter wrote: > Greetings, > > I noticed the notice on your front page needing people to help transfer the > site contents over to your wiki that you set up. I did a little bit of work, > and managed to get a navigation, downloads page, application page, and some > other links. Your work is greatly appreciated here. > I would be glad to continue, if you think I am doing things right. The next > thing I had planned to make some changes to was the documentation section, > add a changes section, add a structure whereby you have an article for each > package, and then the folder for that package contains all the different > versions that have been or will be released. Please give me any thoughts on > any of these, and tell me if you think they are a good idea, and whether I > should continue or not. We need to move the contents at first, but I agree that a good page structure should be created during this process. Please, go ahead - the nice thing on wiki is that we can rearrange information later (if we find a problem with the structure). I just started to move probably most problematic part - soundcard matrix to wiki. Thanks, Jaroslav ----- Jaroslav Kysela <perex(a)suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs

1 0

[alsa-devel] Call for Explanation of ALSA Config Behavior
by Jeff Rush 05 May '07

05 May '07

I'm trying to get ALSA to support all the little features of my laptop, which is based on the Intel HDA chipset with the Realtek codec. I'm also playing with the softvol plug to add a volume controls over certain virtual devices. A few questions I can't figure out: 1. Isn't it the standard convention that there be a control named "Master" that adjusts the overall volume of a device? So why does the Intel HDA ALSA driver define one named "Headphone" that does the same thing instead of following that convention? Is there some reason, or perhaps a difference in opinion within the ALSA community on the naming of controls? Shouldn't every ALSA driver define a "Master" control? 2. When I add a control using the softvol plugin, the mixer GUI shows it in both the playback and the capture set of controls. Why and how can I tag a control to belong to only one set or the other? Being a volume control it seems it should only be in the playback collection. 3. Once I add such a control, it -never- goes away. What I mean is that if I rename it, or remove it, and restart ALSA or even restart the entire computer, the old name for the control always shows up in the mixer GUI. I've grepped *all* of /etc, looking in the /etc/asound.conf, /etc/asound.state and ~/.asoundrc files but the old name isn't anywhere -- where is it coming from? Thanks very much for any help you can provide, For years I've just tried to "use" ALSA but now I'm trying to actually understand its subtle nuances. -Jeff

2 1

[alsa-devel] DMix period_size should always be half of buffer size?
by Prabhu Sivaraja 04 May '07

04 May '07

This is a followup to my earlier question about dmix not being able to mix small files. I investigated it more and here is what I found. Again background info. I have a 64KB as kernel buffer and a 64KB circular buffer for my device. In a poll thread I copy the data obtained from ALSA lib from the kernel buffer to my device circular buffer by keeping track of appl_ptr and hw_ptr(dmix only). Everything was working fine except when I was trying to mix files smaller than 64KB(my buffer size), the small file was not getting mixed through the dmix plugin. Anything over 64KB was getting mixed just fine. So I set about reducing my period size from 32KB to 4KB while maintaining my buffer size at 64KB. When I tried to do this my hw_ptr never gets incremented from 0. Hence my driver is stuck in a loop waiting for bytes to copy. This is only observed when I am using dmix plugin and NOT when using hw or plughw. When my period size is half the size of my buffer everything works fine with dmix (I verified this by reducing my buffer size to 8KB and making my period size 4KB. hw_ptr gets incremented then but I get buffer problems). It seems like dmix is forcing me to keep my period size half the size of my buffer. hw and plughw devices do not seem to do that. Is this a limitation of dmix. Could anyone comment on the dmix limitation that I am experiencing. Thanks a lot of all your help. Prabhu.

2 2