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

[alsa-devel] [PATCH]New model for conexant 5045 codec to support benq r55e
by Jiang zhe 17 Jan '08

17 Jan '08

Hi, Please refer to bug 0003636. The benq r55e laptop have 3 jacks on the front panel. One for HP, one for Line In and one for Mic In. This patch implemented a new model to support it. Best regards! Jiang,zhe Signed-off-by: Jiang Zhe <zhe.jiang(a)intel.com> --- alsa-driver-hg20080115/alsa-kernel/pci/hda/patch_conexant.c 2008-01-09 09:00:15.000000000 +0800 +++ b/alsa-kernel/pci/hda/patch_conexant.c 2008-01-17 10:33:44.000000000 +0800 @@ -457,6 +457,15 @@ static struct hda_input_mux cxt5045_capt } }; +static struct hda_input_mux cxt5045_capture_source_benq = { + .num_items = 3, + .items = { + { "IntMic", 0x1 }, + { "ExtMic", 0x2 }, + { "LineIn", 0x3 }, + } +}; + /* turn on/off EAPD (+ mute HP) as a master switch */ static int cxt5045_hp_master_sw_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) @@ -576,6 +585,15 @@ static struct snd_kcontrol_new cxt5045_m {} }; +static struct snd_kcontrol_new cxt5045_benq_mixers[] = { + HDA_CODEC_VOLUME("Line In Capture Volume", 0x1a, 0x03, HDA_INPUT), + HDA_CODEC_MUTE("Line In Capture Switch", 0x1a, 0x03, HDA_INPUT), + HDA_CODEC_VOLUME("Line In Playback Volume", 0x17, 0x3, HDA_INPUT), + HDA_CODEC_MUTE("Line In Playback Switch", 0x17, 0x3, HDA_INPUT), + + {} +}; + static struct hda_verb cxt5045_init_verbs[] = { /* Line in, Mic */ {0x12, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN }, @@ -601,6 +619,30 @@ static struct hda_verb cxt5045_init_verb { } /* end */ }; +static struct hda_verb cxt5045_benq_init_verbs[] = { + /* Int Mic, Mic */ + {0x12, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN|AC_PINCTL_VREF_80 }, + {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN|AC_PINCTL_VREF_80 }, + /* Line In,HP, Amp */ + {0x10, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, + {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, + {0x11, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, + {0x11, AC_VERB_SET_CONNECT_SEL, 0x1}, + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)}, + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, + /* Record selector: Int mic */ + {0x1a, AC_VERB_SET_CONNECT_SEL,0x1}, + {0x1a, AC_VERB_SET_AMP_GAIN_MUTE, + AC_AMP_SET_INPUT|AC_AMP_SET_RIGHT|AC_AMP_SET_LEFT|0x17}, + /* SPDIF route: PCM */ + { 0x13, AC_VERB_SET_CONNECT_SEL, 0x0 }, + /* EAPD */ + {0x10, AC_VERB_SET_EAPD_BTLENABLE, 0x2 }, /* default on */ + { } /* end */ +}; static struct hda_verb cxt5045_hp_sense_init_verbs[] = { /* pin sensing on HP jack */ @@ -741,6 +783,7 @@ static int cxt5045_init(struct hda_codec enum { CXT5045_LAPTOP, /* Laptops w/ EAPD support */ CXT5045_FUJITSU, /* Laptops w/ EAPD support */ + CXT5045_BENQ, #ifdef CONFIG_SND_DEBUG CXT5045_TEST, #endif @@ -750,6 +793,7 @@ enum { static const char *cxt5045_models[CXT5045_MODELS] = { [CXT5045_LAPTOP] = "laptop", [CXT5045_FUJITSU] = "fujitsu", + [CXT5045_BENQ] = "benq", #ifdef CONFIG_SND_DEBUG [CXT5045_TEST] = "test", #endif @@ -763,6 +807,7 @@ static struct snd_pci_quirk cxt5045_cfg_ SND_PCI_QUIRK(0x103c, 0x30cd, "HP DV Series", CXT5045_LAPTOP), SND_PCI_QUIRK(0x103c, 0x30d5, "HP 530", CXT5045_LAPTOP), SND_PCI_QUIRK(0x103c, 0x30d9, "HP Spartan", CXT5045_LAPTOP), + SND_PCI_QUIRK(0x152d, 0x0753, "Benq R55E", CXT5045_BENQ), SND_PCI_QUIRK(0x1734, 0x10ad, "Fujitsu Si1520", CXT5045_FUJITSU), SND_PCI_QUIRK(0x1734, 0x10cb, "Fujitsu Si3515", CXT5045_LAPTOP), SND_PCI_QUIRK(0x1734, 0x110e, "Fujitsu V5505", CXT5045_LAPTOP), @@ -819,6 +864,16 @@ static int patch_cxt5045(struct hda_code spec->mixers[0] = cxt5045_mixers; codec->patch_ops.init = cxt5045_init; break; + case CXT5045_BENQ: + codec->patch_ops.unsol_event = cxt5045_hp_unsol_event; + spec->input_mux = &cxt5045_capture_source_benq; + spec->num_init_verbs = 1; + spec->init_verbs[0] =cxt5045_benq_init_verbs; + spec->mixers[0] = cxt5045_mixers; + spec->mixers[1] = cxt5045_benq_mixers; + spec->num_mixers = 2; + codec->patch_ops.init = cxt5045_init; + break; #ifdef CONFIG_SND_DEBUG case CXT5045_TEST: spec->input_mux = &cxt5045_test_capture_source;

2 1

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

17 Jan '08

Ups my bad, somehow the model number got commented out by an update script I ran yesterday. The drivers were recompiled with the "with-debug=detect" option set. I've attached the dmesg, codec#0 output and amixer contents. Dmesg is not very talkative, it did not show "hda_codec_setup_stream:NID=", however I get something of the type "hda_generic: no proper output path found". About the testing, I performed speaker-test every time I changed something (still only output on "Front L/R channels"). Patrick > From: zhe.jiang(a)intel.com > To: fuuss(a)hotmail.com > Date: Wed, 16 Jan 2008 13:49:43 +0800 > CC: cmatsuoka(a)gmail.com; alsa-devel(a)alsa-project.org > Subject: Re: [alsa-devel] intel-hd on an intel G33 motherboard > > On Wed, 2008-01-16 at 02:22 +0800, De Fuuss wrote: >> >> 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. > Hi, > >>From the dmesg, there is "hda_codec: Unknown model for ALC883, trying > auto-probe from BIOS" > It looks like that no "model=" is assigned. > Did you assign model for the driver? > > Can you play some music? > Then there will be some info in the dmesg like > "hda_codec_setup_stream:NID= ". > Please paste such info and give the result of > "cat /proc/asound/card0/codec#0". > > BTW, how did you do the testing? > You run speaker-test or by other way? > >>From the codec info, it seems that there are paths from DAC to Jack. > So it's a little weird that all other jacks are silent. > > Thanks! > >> 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/ >> >> > > _______________________________________________ > 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] hdsp driver broken for Multiface II Rev 35
by Jean Batrel 16 Jan '08

16 Jan '08

> Date: Mon, 14 Jan 2008 02:21:42 +0100 > From: Andreas Degert <ad(a)papyrus-gmbh.de> > Subject: [alsa-devel] hdsp driver broken for Multiface II Rev 35 > To: alsa-devel(a)alsa-project.org > Cc: tiwai(a)suse.de > Message-ID: <20080114022142.51d6ae44(a)pluto.noname> > Content-Type: text/plain; charset=US-ASCII > > 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. > (...) > 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 > ------------------------------ Bonjour ! You are asking for firmware revision and (RME) cards : I use a HDSP9632 RME card with issues : my card is Rev. 1.53 and only the 1.51 version is working with Linux, AFAIK... The card is detected, there is some activity in the middle of HDSPmixer, but I can hear no sound... A lspci says : 02:01.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP (rev 99) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 255 Interrupt: pin A routed to IRQ 20 Region 0: Memory at feaf0000 (32-bit, non-prefetchable) [size=64K] I have no very skills with Linux yet, but I very hope getting this card working with Linux. Can you help me please ? I very apologize if this mail is not relevant in this list. But I very thank you in advance (I use Fedora 8 and the latest CCRMA kernel) ! Jean Batrel - jean.batrel(a)voila.fr

1 0

Re: [alsa-devel] ALC268 auto-parsing
by Jonathan Woithe 16 Jan '08

16 Jan '08

Marco Schuster wrote: > 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. I have no concrete evidence for this but my feeling based on a poke around the windoze drivers a few years ago is that they were configured for the particular laptop by the manufacturer. This configuration information is not in an obvious location though - if they go this way it's either embedded within the driver itself or located in a binary format file somewhere. In both cases this makes it almost impossible to utilise. Regards jonathan

1 0

[alsa-devel] SNDRV_PCM_INFO_MMAP - what do I need for it?
by Timur Tabi 16 Jan '08

16 Jan '08

My 8610 ASoC driver has this: static const struct snd_pcm_hardware fsl_dma_hardware = { .info = SNDRV_PCM_INFO_INTERLEAVED, This means that MMAP is not enabled. I understand what MMAP is, but not from an ALSA driver perspective. If I change the above line to this: .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID, what does ALSA do differently? Do I need to define any new functions? From an application perspective, what is different? Also, does DMIX need MMAP support? -- Timur Tabi Linux kernel developer at Freescale

3 4

[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