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

[alsa-devel] ALC268 auto-parsing
by Marco Schuster 16 Jan '08

16 Jan '08

Hi all, I am a bit interested in how the Realtek Windows driver gets its pin config. There IMO are two options: a) it uses the bios autoconfig - as parsing this doesn't work in alsa here, there must be something special in it b) it uses a config file - it should be easy to get out the pin config. Any opinions what is correct way? Marco

2 1

[alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
by Ondrej Zary 16 Jan '08

16 Jan '08

Hello, as hibernation (swsusp) started to work with my CPU, I found that my Turtle Beach Malibu stops working after resume from hibernation. It's caused by fact that the card is not enabled on the pnp layer during resume - and thus card registers are inaccessible (reads return FFs, writes go nowhere). During resume, pnp_bus_resume() in drivers/pnp/driver.c is called for each pnp device. This function calls pnp_start_dev() only when the PNP_DRIVER_RES_DO_NOT_CHANGE bit is NOT seting pnp_drv->flags. But the cs4236 driver in sound/isa/cs423x/cs4236.c explicitly sets the .flags to PNP_DRIVER_RES_DISABLE - it's value is 3 and that includes PNP_DRIVER_RES_DO_NOT_CHANGE bit. The same .flags value is present in many of the ALSA ISA sound drivers. Removing that .flags line caused this to appear inlog when loading snd_cs4236 module: CS4236+ WSS PnP manual resources are invalid, using auto config CS4236+ CTRL PnP manual resources are invalid, using auto config CS4236+ MPU401 PnP manual resources are invalid, using auto config and the sound now works after resume! So the question is: why is this line present? Is this a bug? What's the correct fix? -- Ondrej Zary

6 23

[alsa-devel] TLV support for PCM (in driver)
by Jaroslav Kysela 16 Jan '08

16 Jan '08

Hi, I am actually thinking to add TLV support to each PCM stream. The reason is to obtain various "static" information from the driver without even opening the PCM stream. The current API lack: a) get channel info / name / position (e.g. Front Left Speaker) - not sure how to handle multichannel cards - I'm sure that this is something to be user configurable b) get possible channels c) get possible formats d) various inter-PCM-device constraint description (e.g. if S/PDIF PCM stream can be used with analog etc.) e) eventually more information for device name hinting for userspace (current problems for HDA, AC97, USB devices are that we have only one .conf file per driver covering all hardware - we need to detect real device capabilities and show only devices which can be really used) Opinions? Jaroslav ----- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.

2 3

[alsa-devel] hdsp driver broken for Multiface II Rev 35
by Andreas Degert 16 Jan '08

16 Jan '08

Hi folks, changeset 5326 from 2007/08/31 broke the driver for this card revision. There was an older thread about this problem which didn't seem to come to a conclusion. ioctl SNDRV_HDSP_IOCTL_GET_VERSION returns io_type = 1 (Multiface) firmware_rev = 0x35 which is correct. The old code for hdsp_playback_to_output_key looks like this: static int hdsp_playback_to_output_key (struct hdsp *hdsp, int in, int out) { switch (hdsp->firmware_rev) { case 0xa: return (64 * out) + (32 + (in)); case 0x96: case 0x97: return (32 * out) + (16 + (in)); default: return (52 * out) + (26 + (in)); } } For my card the result is "(52 * out) + (26 + (in))". The new code looks like this: static int hdsp_playback_to_output_key (struct hdsp *hdsp, int in, int out) { switch (hdsp->io_type) { case Multiface: case Digiface: default: return (64 * out) + (32 + (in)); case H9632: return (32 * out) + (16 + (in)); case H9652: return (52 * out) + (26 + (in)); } } which gives the wrong result "(64 * out) + (32 + (in))". The old code returns this when firmware_rev == 0xa, which might be the revision of the older Multiface (not Multiface II). I changed the code to static int hdsp_playback_to_output_key (struct hdsp *hdsp, int in, int out) { switch (hdsp->io_type) { case Multiface: case Digiface: default: if (hdsp->firmware_rev == 0xa) return (64 * out) + (32 + (in)); else return (52 * out) + (26 + (in)); case H9632: return (32 * out) + (16 + (in)); case H9652: return (52 * out) + (26 + (in)); } } Another possibility would be to go back to the old version of the code and only make changes for io_type H9632/H9652 with new firmware revisions: static int hdsp_playback_to_output_key (struct hdsp *hdsp, int in, int out) { switch (hdsp->firmware_rev) { case 0xa: return (64 * out) + (32 + (in)); case 0x96: case 0x97: return (32 * out) + (16 + (in)); } switch (hdsp->io_type) { case H9632: return (32 * out) + (16 + (in)); case Multiface: case H9652: return (52 * out) + (26 + (in)); case Digiface: ??? is there a Digiface with revision != 0xa ??? default: ??? HDSP_IO_Type Undefined ??? } } Similar changes must be made to hdsp_input_to_output_key. Does anyone know which firmware revision exist for which card (io_type) ? thank you Andreas Degert

3 4

Re: [alsa-devel] Bug#436723: Playing sound hands on powerbook3, 5 with 2.6.21-2 kernel
by maximilian attems 16 Jan '08

16 Jan '08

[ adding alsa upstream on cc ] On Mon, Jan 14, 2008 at 12:21:11AM +0100, th.huth(a)googlemail.com wrote: > > Please have a look at > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/87652/co… > and the corresponding patch to see wether this patch solves this sound > issue. woow, i thought to fire up "try newer kernel", but your patch still applies to current linus git: ~/src/linux-2.6$ patch -p0 --dry-run < ~/pmac.c.diff patching file sound/ppc/pmac.c Hunk #5 succeeded at 868 (offset -24 lines). Hunk #6 succeeded at 1207 (offset -47 lines). so bringing that to upstream alsa radar. -- maks

3 3

[alsa-devel] I/O possible
by Mihaela Vitalariu 16 Jan '08

16 Jan '08

Hello everyone! I am coding a Linux sound application using the PCM interface. It plays fine but at unexpected intervals i sometimes get a SIGIO directly in my program, which exits printing the message "I/O possible". What can be happening? Any help would be greatly appreciated. Simbasaurus.

1 0

[alsa-devel] hda_intel messages showing up in dmesg
by Andrew Paprocki 16 Jan '08

16 Jan '08

I'm seeing these messages show up in dmesg every once in a while. If anyone has ideas as to why I'd be seeing these, I can help track down any potential problems. I am having problems where ALSA playback stutters while using the OSS-compatibility layer for ALSA works fine with no stuttering. After inserting the module w/ model=6stack-dig: ACPI: PCI Interrupt 0000:00:14.2[A] -> GSI 16 (level, low) -> IRQ 16 hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x225f0d00 hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x225f0d00 ACPI: PCI Interrupt 0000:01:05.2[B] -> GSI 19 (level, low) -> IRQ 18 hda-intel: Invalid position buffer, using LPIB read method instead. After inserting the module w/ no model defined: ACPI: PCI Interrupt 0000:00:14.2[A] -> GSI 16 (level, low) -> IRQ 16 hda_codec: Unknown model for ALC883, trying auto-probe from BIOS... ACPI: PCI Interrupt 0000:01:05.2[B] -> GSI 19 (level, low) -> IRQ 18 hda-intel: Invalid position buffer, using LPIB read method instead. I've only seen the azx_get_response messages print out once. I see the LPIB message print out every once in a while. Thanks, -Andrew

2 1

[alsa-devel] [PATCH] remove 11c1:1040 from patch_si3054.c id list
by Vasily Khoruzhick 16 Jan '08

16 Jan '08

Codec with id 11c1:1040 sitting on hda bus isn't si3054-compatible. It should be removed from patch_si3054.c id list

2 1

Re: [alsa-devel] intel-hd on an intel G33 motherboard
by De Fuuss 16 Jan '08

16 Jan '08

Hi, I have recompiled the driver with --with-debug=detect. Dmesg output is attached to this mail. ALSA specificities seem to be present this time. Hope this helps. Best regards, Patrick > From: zhe.jiang(a)intel.com > To: fuuss(a)hotmail.com > Date: Tue, 15 Jan 2008 09:32:35 +0800 > CC: cmatsuoka(a)gmail.com; alsa-devel(a)alsa-project.org > Subject: Re: [alsa-devel] intel-hd on an intel G33 motherboard > > On Mon, 2008-01-14 at 17:11 +0000, De Fuuss wrote: >> The jumper is now set to enable onboard (Intel HDA) audio. >> At the back of the barebone there are 5 jacks (4 channels for 7.1 and 1 line in channel) + 1 spdif out. >> From these, using 6stack-hp, only the "Front L/R" jack works, none of the others >> On the front, there are 2 jacks (1 headphones and 1 microphone). The headphone jack works. >> > Can you tell us how you did the testing? >>From the driver code, it's not likely that all other jacks don't work. > > Because the driver support up-mixing, you can play a 2-channel music and > get sound from 4 jacks on the back panel. > > I read the dmesg output that you sent to me. > But there is no alsa debug info in it. > Did you really configure the driver with the option > "--with-debug=detect"? > If not, please try it and paste the dmesg info, it is helpful to trace > the issue. > > Best regards! > Jiang,zhe >> All the channels have been set to 100% in alsamixer. >> >> Considering that a week ago I had 0.0 and today I'm at 2.0, it's already a improvement. ;-) >> >> Patrick >> >>> Subject: Re: [alsa-devel] intel-hd on an intel G33 motherboard >>> From: zhe.jiang(a)intel.com >>> To: fuuss(a)hotmail.com >>> CC: cmatsuoka(a)gmail.com; alsa-devel(a)alsa-project.org >>> Date: Mon, 14 Jan 2008 16:43:00 +0800 >>> >>> On Mon, 2008-01-14 at 02:06 +0800, De Fuuss wrote: >>>> >>>> Following your advice, I tested per channel output. Using either >>>> 6stack-dig or 6stack-hp, I get noise from Front Left and Right jacks, >>>> using speaker-test (X=1 and 2) but not on any other channels. >>> >>> Hi, >>> Did you mean that after you changed the 'Jumper', >>> you could get the sound from the Front jack on the back channel? >>> >>>> Patrick >>>> >>>>> Date: Sun, 13 Jan 2008 01:01:50 -0200 >>>>> From: cmatsuoka(a)gmail.com >>>>> To: fuuss(a)hotmail.com >>>>> CC: zhe.jiang(a)intel.com; alsa-devel(a)alsa-project.org >>>>> Subject: Re: [alsa-devel] intel-hd on an intel G33 motherboard >>>>> >>>>> 2008/1/12 De Fuuss : >>>>> >>>>>> I get the uneasy feeling that something is messed up with this >>>> board. Anyway, for completeness' sake, I attached the results of >>>> amixer contents, cat /proc/asound/card0/codec#0 and dmesg for the >>>> module loaded as 6stack-dig. I have to try 6stack-hp again to confirm >>>> if I get something there. >>>>> >>>>> I fixed the Inspiron output, and I'm adding the SG33G5M codec to the >>>>> codecgraph codecs collection (git repository at >>>>> http://helllabs.org/git/codecgraph.git). If nodes 0x14, 0x15, 0x16 >>>> and >>>>> 0x17 are the front, rear, clfe and side connectors in the back >>>> panel, >>>>> 6stack-hp should work (at least for the outputs). You can test the >>>>> outputs using "speaker-test -Dplug:surround71 -c8 -sX" (where X >>>> varies >>>>> from 1 to 8) and a pair of headphones. >>>>> _______________________________________________ >>>>> Alsa-devel mailing list >>>>> Alsa-devel(a)alsa-project.org >>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>>> >>>> _________________________________________________________________ >>>> Express yourself instantly with MSN Messenger! Download today it's >>>> FREE! >>>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >>>> _______________________________________________ >>>> Alsa-devel mailing list >>>> Alsa-devel(a)alsa-project.org >>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>>> >>>> >>> >> >> _________________________________________________________________ >> Express yourself instantly with MSN Messenger! Download today it's FREE! >> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Re: [alsa-devel] Splitting up the HDA-INTEL modules
by Jonathan Woithe 15 Jan '08

15 Jan '08

Marco Schuster wrote: > when I looked today through the files of the snd-hda-intel module, I > was a bit shocked by this complex amount of code (patch_realtek.c for > example). I would think about splitting up the code in a way each > chipset gets its own .c file - which will make debugging, patching or > editing a lot easier IMO, and for second people can then comment on > just their specific chipset in config. The problem with such a split is, as Tobin went on to say, that there are a lot of interdependencies and shared code within each chipset's family: > I don't think that it would be very easy, as there are several instances > where code relies on other codec definitions. One could argue that therefore we have toplevel realtek/sigmatek/etc "librarys" which are used by each chipset-specific driver but IMHO that is hardly going to count as a simplification. Tobin then said: > In all actuality, what is needed is a more generic driver that is driven > by userspace tools. ... Maybe we can get a core group together and > actually define and implement an API for this. I think this idea has merit and may be worth pursuing. I would be interested in assisting and providing input to the process although I haven't time at present to take a lead role. > My idea is a driver that takes settings from a config file that are > either 32bit register values (aka Sigmatel), or individual Node > parameters (Realtek, Conexant, etc). This way we can define model > config files, and associate their PCI Quirk in a central config file > that can be edited in userspace. This would be much easier to support, > for users, distro vendors, hardware vendors, and us. Agreed, at least in theory. There may be complications due to the varying topography of the chips; the userspace API may have to be relatively complex to support things like record source switch options (which are vastly different for diffenent chips). Even so, if we can get this to work the ongoing support effort for HDA will be much reduced so it's probably worth the effort. > I'll try to write up a proposal in the next few weeks, if we can get > others on board to work on this. I think this would be worth looking at. Regards jonathan

1 0