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

[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 16 Jan '08

16 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

[alsa-devel] HDA: Enable chipset gcap usage
by Tobin Davis 15 Jan '08

15 Jan '08

I tweaked this as promised, and ran it through the checkpatch.pl utility from kernel git tree. I have tested it on my Asus Z62F laptop as well as a few systems in my work environment without issue. Summary: hda_intel.c use gcap register to determine number of streams supported by southbridge. This patch quieries the southbridge for the number of streams supported by the southbridge in most chipsets, and reads these values from the chipset directly. Most systems are hardwired for 4 streams in each direction, but newer chipsets change that capability. As a fallback, the old hardcoded method is still available. Signed off by Tobin Davis <tdavis(a)dsl-only.net>

2 2

[alsa-devel] Fwd: surround51 lfe/center/front channel cross-talk with intel8x0 board
by Matt Hirsch 15 Jan '08

15 Jan '08

I sent this to alsa-users and didn't get any response. I'd be grateful if someone had some suggestions for getting around the problem described below. Thanks very much, Matt ---------- Forwarded message ---------- From: Matt Hirsch <matthew.hirsch(a)gmail.com> Date: Jan 5, 2008 1:20 AM Subject: surround51 lfe/center/front channel cross-talk with intel8x0 board To: alsa-user(a)lists.sourceforge.net I have an AC'97 based onboard sound card in my system (snd_intel8x0 driver). I'm using it in 6ch mode to drive two front speakers, two rear speakers and a subwoofer and center channel. Using speaker-test with the surround51 plug (or any other alsa program with that plug) to send audio to channel 5 (center in alsamixer) produces an attenuated signal on channel 2 (right front in alsamixer) and likewise, sending audio to channel 6 (lfe in alsamixer) produces an attenuated signal on channel 1 (left front in alsamixer). In summary: speaker-test -tsine -f200 -Dsurround51 -c6 -s1 tone on left front speaker only speaker-test -tsine -f200 -Dsurround51 -c6 -s2 tone on right front speaker only speaker-test -tsine -f200 -Dsurround51 -c6 -s3 tone on left rear speaker only speaker-test -tsine -f200 -Dsurround51 -c6 -s4 tone on right rear speaker only speaker-test -tsine -f200 -Dsurround51 -c6 -s5 tone on center speaker, and quieter tone on right front speaker speaker-test -tsine -f200 -Dsurround51 -c6 -s6 tone on lfe, and quieter tone on left front speaker Any help or suggestions as to getting rid of this crosstalk would be greatly appreciated! Here's what I've tried so far: If I don't use the surround51 plug, and use default (hw:0) instead, the channels are all in a different order, but the same effect occurs (crosstalk between two channels). I tried sequentially setting and un-setting all of the modes and buttons in the alsa mixer, such as high-pass filter (on/off), surround jack mode (shared/independent), line jack sense (on/off), exchanging front/surround, etc. Nothing seemed to have any effect. When I exchange the front and surround speakers, the cross talk is also exchanged (i.e. it shows up on the rear speakers rather than the front speakers). I'm running fedora 8, so I started with the latest fedora 8 alsa rpms (1.15). When this didn't work I compiled a recent CVS snapshot (12/25/07) against my kernel and installed it. Same results as above. My hardware shows up in lspci as: 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0) My kernel is 2.6.23.9-85.fc8 Thanks, Matt

2 2

[alsa-devel] ALC268 test model not working
by Marco Schuster 15 Jan '08

15 Jan '08

Hi all, finally I got the patch applied to kernel src :) But it doesn't work correctly, because when running alsamixer, dmesg tells "hda_codec: num_steps = 0 for NID=0x1d", and alsamixer fails with alsamixer: function snd_mixer_load failed: Invalid argument. Is this some obscure bug in the notebook hardware or some driver bug? Marco (note, I apply against .24-rc6 still)

3 4