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

[alsa-devel] [ASoc] TDM over one SSC channel on AT91 possible?
by Friedrich Lobenstock 24 Jun '11

24 Jun '11

Hello! The background: I'm just designing an ATMEL AT91RM9200 based board which got two TLV320AIC33 on board. It is either possible to hook up the two TLV320AIC33 to a separate SSC (synchronous serial control) channel each or use one SSC channel and configure it for TDM (time division multiplex) mode. There is already a driver for TLV320AIC14k/TLV320AIC2k in the development tree, so adding support for the TLV320AIC33 should be feasible. What I'm not sure about is the fact if ASOC is prepared for using channels, especially SSC, in TDM mode. Is the core ASOC structure prepared to handle that? Would we be better off instantiate one drive twice each time with different parameters for the SSC channel? Thanks for any feedback. -- MfG / Regards Friedrich Lobenstock _________________________________________________________ SCOTTY Group Austria GmbH a SCOTTY Group plc company, http://www.scottygroup.com/ _________________________________________________________

4 3

[alsa-devel] [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ
by Ahmet İnan 02 Jun '08

02 Jun '08

after using a HZ:=300 kernel for some time now and needing snd-aloop again i found out, that i either had to correct the hardcoded number, or fix the problem permanently, which couses stuttering and other problems. i also removed the SYNC on start code, not just because its more or less useless and brings problems, but ive got a nice idea how to fix this overrun/underrun problem in a much nicer way. so stay tuned for the next patch, until its implemented. this patch here is more or less experimental, id like to hear some feedback. http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-1.0.1… Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de> please also include my email address when responding - i have no intention to enable recieving emails from the list. ahmet -- admin der abteilung für angewandte mathematik, tel. 0761-203-5626

3 16

[alsa-devel] [RFC] virtual master control for HD-audio
by Takashi Iwai 06 May '08

06 May '08

Hi, another thing I'd like to push into the next kernel is the virtual master volume control. As I posted in earlier posts, it adds virtual controls that have several slave controls with the same types, e.g. Front, Surround, Center, LFE, etc. Then these are adjusted simultaneously via the master control. It'd be appreciated if some one can test the patches with HD-audio h/w that has no master control yet (e.g. some STAC codecs). Note that this won't add the master volumes if there are no real volume controls. Some codecs have really no volume control, and this won't help for such devices. Two (and one for driver) patches will follow after this. Takashi

5 27

[alsa-devel] Altec Lansing FX5051 mixer
by Jeremy Nickurak 04 Apr '08

04 Apr '08

I recently purchased an Altec Lansing USB Surround speaker set. (It's a set of 5.1 speakers, with a built-in USB sound card). I've got about a week before the return policy expires and I'd have to return it. The mixer doesn't work at all w/linux kernel 2.6.22, everything is locked at 100% volume, which is pretty unhelpful, as it's the only way to adjust the volume. (no analog controls). Also, the digital control panel locks up when the speakers power up, further preventing any access to the volume controls. The device works out-of-the-box without any drivers under XP, so I have to so-far assume that alsa's usb-audio is missing something. Any thoughts as to what could be wrong? I'm more than happy to prod the device and submit any information I can extract about it, or even potentially opening the device up for remote access if a reputable developer is interested in examining it. -- Jeremy Nickurak -= Email/Jabber: atrus(a)rifetech.com =-

3 4

[alsa-devel] ALSA driver for Native Instruments sound hardware
by Daniel Mack 23 Mar '08

23 Mar '08

Hi, some months after the last posting, we finally managed to finish a new version of the ALSA driver for Native Instruments' external USB sound cards such as "Rig Kontrol 2", "Kore Kontroller", "Audio Kontrol 1" and "Audio 8 DJ". Compared to the last release, the following things were changed: - the streaming logic was completely reworked so that multiple substreams are handled correctly - a Linux input device layer was added to support the knobs, buttons and pedals on "Rig Kontrol 2" and "AudioKontrol 1" - workqueues were entirely removed from the code - most data structures are now allocated within one big struct to avoid multiple, smaller allocations - many more cleanups according to Clemens' reply on my last posting[1] The driver was properly tested with all the mentioned hardware on both record and playback channels. The patchset should apply to the current mecurial alsa-kernel tree. Please let me know what you think. Best regards, Daniel [1] http://article.gmane.org/gmane.linux.alsa.devel/34324/ Signed-off-by: Daniel Mack <daniel(a)caiaq.org> Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de>

4 10

[alsa-devel] HW decoding abstracted in ALSA
by Harsha priya gupta 19 Mar '08

19 Mar '08

Hi, I am new to ALSA and audio stack in Linux. I have a sound card that can do HW decoding as well. I am looking at writing an ALSA driver such that whatever may be the player or MMF above, it should use the HW decoder and not the inherit SW decoder that is available with the player. Can someone help me with some pointers or existing like-drivers? Thanks in advance, Harsha

2 2

[alsa-devel] no front speaker sound with ALC262
by Rene Dohmen 17 Mar '08

17 Mar '08

Dear List, I have a problem with an Intel HDA soundcard lspci output: ----- 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) The sound volume is very very low when i use the headphone output. The device has integrated speakers but i don't hear any sound coming out of them (maybe because the volume is so low...). I've put all the mixer channels to the maximum values. When booted in Win XP the soundcard works correctly. Is see one line in my logs that indicate that something is wrong: hda_codec: Unknown model for ALC262, trying auto-probe from BIOS... I didn't have it working with other versions of ALSA. Tested with 1.0.14(provided with ubunty gutsy), then started reading, lots of suggestions stated that the problem would be solved in 1.0.15, so i compiled 1.0.16 from src and replaced the default alsa modules with the new ones. De device i 'm using is supplied by tangent ( http://www.tangent.com/t_all_in_one_LCDPC/vita_8000s.htm) its an all in one solution with touchscreen and speakers integrated in one small cabinet. I runned the alsa-info.sh script output and uploaded it: http://pastebin.ca/913865 I don't know if this is the correct place for getting help but all help is appreciated, Best Regards, Rene Dohmen

5 14

[alsa-devel] Maya44 driver in the official ALSA tree
by Piotr Zaryk 15 Mar '08

15 Mar '08

Hi, When will be the next alsa-driver version released? Can't wait till maya44 support will be added to the official alsa tree. It will help with the development of the new driver. -- Piotr Zaryk

3 3

Re: [alsa-devel] no front speaker sound with ALC262
by Takashi Iwai 14 Mar '08

14 Mar '08

At Fri, 29 Feb 2008 17:24:03 +0100, Rene Dohmen wrote: > > No I still don't know where the speakers are conencted. > I asked the support engineers at tangent to send me a detailed > blockdiagram of their sound solution and ik think i'll receive that > sooner or later. > > So, for now, I just tried passing the EAPD option to all NIDS in the > codec#0 file. > > I attached the code#0 file while working with very low volume > > When I run > sudo hda-verb/hda-verb /dev/snd/hwC0D0 0x03 SET_EAPD 0x02 > or > sudo hda-verb/hda-verb /dev/snd/hwC0D0 0x02 SET_EAPD 0x02 Doh, I actually misunderstood that your codec were ALC268 but it's ALC262. EAPD command can be issued only on widgets that support. ALC262 has no EAPD pin caps at all. so it doesn't work like that. Instead, ALC262 (and other Realtek codecs) has a special sequence with coefficients to the vendor-defined widget. Yes, it's a black magic. Try the following sequence: 0x20 SET_COEF_INDEX 0x07 0x20 SET_PROC_COEF 0x3060 0x3060 can be different numbers like 0x3070 or 0x3050. If you set a different number, reset the coef index again (i.e. always call as a pair). Takashi

3 3

[alsa-devel] snd-hda-intel: Fix volume-wheel and microphone on Fujitsu-Siemens Amilo M3438G
by M G 10 Mar '08

10 Mar '08

Currently the default model that gets selected on this hardware is "F1734". Using this model neither the volume-wheel nor microphone (internal or external) work. The first part of my patch changes the default model to "fujitsu", this enables the volume wheel on the left side of the laptop. The second part changes the capture settings and thus makes it possible to record from microphones. Now when capturing from the external microphone I can hear myself talking but its quite quiet. I can improve this a little by raising the capture volume, but if I raise it above 40 I can no longer record anything. Questions: Is this patch any good or is there a better way to fix my problems? Why is the recording so quiet and why can't I record with capture value above 40? Patch: diff -r c4c5e6ced12f pci/hda/patch_realtek.c --- a/pci/hda/patch_realtek.c Wed Feb 06 15:48:06 2008 +0100 +++ b/pci/hda/patch_realtek.c Wed Feb 06 15:59:28 2008 +0100 @@ -2917,7 +2917,7 @@ static struct snd_pci_quirk alc880_cfg_t SND_PCI_QUIRK(0x161f, 0x203d, "W810", ALC880_W810), SND_PCI_QUIRK(0x1695, 0x400d, "EPoX", ALC880_5ST_DIG), SND_PCI_QUIRK(0x1695, 0x4012, "EPox EP-5LDA", ALC880_5ST_DIG), - SND_PCI_QUIRK(0x1734, 0x107c, "FSC F1734", ALC880_F1734), + SND_PCI_QUIRK(0x1734, 0x107c, "FSC F1734", ALC880_FUJITSU), SND_PCI_QUIRK(0x1734, 0x10ac, "FSC", ALC880_UNIWILL), SND_PCI_QUIRK(0x1734, 0x10b0, "Fujitsu", ALC880_FUJITSU), SND_PCI_QUIRK(0x1854, 0x0018, "LG LW20", ALC880_LG_LW), @@ -3161,7 +3161,7 @@ static struct alc_config_preset alc880_p .dig_out_nid = ALC880_DIGOUT_NID, .num_channel_mode = ARRAY_SIZE(alc880_2_jack_modes), .channel_mode = alc880_2_jack_modes, - .input_mux = &alc880_capture_source, + .input_mux = &alc880_6stack_capture_source, .unsol_event = alc880_uniwill_p53_unsol_event, .init_hook = alc880_uniwill_p53_hp_automute, },

2 9

[alsa-devel] OSS4 X-Fi driver port to ALSA
by William Pitcock 07 Mar '08

07 Mar '08

Hi, On Feburary 1, 4Front released their XFi driver to the public. Is anyone looking into porting this? If not, I will give it a try soon enough. It seems to not require any firmware at all too. William

5 13

[alsa-devel] HDMI v. ICH8 on Dell XPS M1330
by Armando Di Cianno 05 Mar '08

05 Mar '08

I figured this was more appropriate for devel, and not user. Sorry, if that's wrong. First, I'm using the 1.0.16 release tarballs. They work better than the in-kernel drivers, as they survive both suspend and hibernate, whereas the kernel drivers do not. I'm eager to see audio over HDMI working on my Dell XPS M1330. I'm pretty sure that this is /not supported/ at the moment -- if this isn't the case, please stop reading, and let me know the particulars. HDMI seems to be supported noted, but mainly for the ATI chips. I'm pretty sure the m1330 has a STAC9228 setup. None of the suggested model= module parameters succeeded in getting audio over HDMI, beyond what is autodetected without any parameter specified. model=5stack seems to show a digital SPDIF device added. If there is anyway I can help the core developers get HDMI audio working, I would be glad to help. I will post all the relevant information I can think of following; please let me know if other information would be helpful. I will gladly turn on any excessive debugging options needed. I am an ALSA n00b, but I will happily do any required work that I can do from this end. Thanks! -- Armando Di Cianno http://dicianno.org/blog armando(a)dicianno.org armando(a)goodship.net w/o model= parameter # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog] Subdevices: 1/1 w/ model=5stack # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: STAC92xx Digital [STAC92xx Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 # lspci -nvvvv -d 8086:284b 00:1b.0 0403: 8086:284b (rev 02) Subsystem: 1028:0209 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 21 Region 0: Memory at febfc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot +,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Virtual Channel <?> Capabilities: [130] Root Complex Link <?> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel

6 20

[alsa-devel] Driver recovers from underrun in plain ALSA mode, but not in OSS emulation
by Timur Tabi 04 Mar '08

04 Mar '08

I'm stress-testing my sound driver using mplayer to see how it handles underrun during jumps in CPU loads. That is, I start playing a movie, and then I cause the CPU to jump to 100%, and then I drop the CPU back to normal. During the times when the CPU is at 100%, I get underruns and other problems. That's normal. When I tell mplayer to use the ALSA API, my driver recovers nicely from an underrun situation when the CPU load drops back to normal. However, if I tell mplayer to use the OSS API (i.e. ALSA's OSS emulation), it does not recover from an underrun situation. The audio and video playback remains distorted. I need to tell mplayer to pause and resume to get it to recover. Is this normal for ALSA drivers? Before I try to debug this problem the hard way, I want to know if this could be the result of a common programming mistake in my driver or something like similar. (FYI, the source code for my driver is in sound/soc/fsl/) -- Timur Tabi Linux kernel developer at Freescale

2 3

[alsa-devel] [PATCH 4/4] Convert non-SoC PXA2xx AC97 driver to clock API
by Mark Brown 04 Mar '08

04 Mar '08

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Acked-by: Takashi Iwai <tiwai(a)suse.de> Cc: alsa-devel(a)alsa-project.org --- sound/arm/pxa2xx-ac97.c | 48 +++++++++++++++++++++++++++++++++++++++------- 1 files changed, 40 insertions(+), 8 deletions(-) diff --git a/sound/arm/pxa2xx-ac97.c b/sound/arm/pxa2xx-ac97.c index 5d86e68..fd7bc86 100644 --- a/sound/arm/pxa2xx-ac97.c +++ b/sound/arm/pxa2xx-ac97.c @@ -16,6 +16,7 @@ #include <linux/platform_device.h> #include <linux/interrupt.h> #include <linux/wait.h> +#include <linux/clk.h> #include <linux/delay.h> #include <sound/core.h> @@ -35,6 +36,10 @@ static DEFINE_MUTEX(car_mutex); static DECLARE_WAIT_QUEUE_HEAD(gsr_wq); static volatile long gsr_bits; +static struct clk *ac97_clk; +#ifdef CONFIG_PXA27x +static struct clk *ac97conf_clk; +#endif /* * Beware PXA27x bugs: @@ -112,9 +117,9 @@ static void pxa2xx_ac97_reset(struct snd_ac97 *ac97) gsr_bits = 0; #ifdef CONFIG_PXA27x /* PXA27x Developers Manual section 13.5.2.2.1 */ - pxa_set_cken(CKEN_AC97CONF, 1); + clk_enable(ac97conf_clk); udelay(5); - pxa_set_cken(CKEN_AC97CONF, 0); + clk_disable(ac97conf_clk); GCR = GCR_COLD_RST; udelay(50); #else @@ -259,7 +264,7 @@ static int pxa2xx_ac97_do_suspend(struct snd_card *card, pm_message_t state) if (platform_ops && platform_ops->suspend) platform_ops->suspend(platform_ops->priv); GCR |= GCR_ACLINK_OFF; - pxa_set_cken(CKEN_AC97, 0); + clk_disable(ac97_clk); return 0; } @@ -268,7 +273,7 @@ static int pxa2xx_ac97_do_resume(struct snd_card *card) { pxa2xx_audio_ops_t *platform_ops = card->dev->platform_data; - pxa_set_cken(CKEN_AC97, 1); + clk_enable(ac97_clk); if (platform_ops && platform_ops->resume) platform_ops->resume(platform_ops->priv); snd_ac97_resume(pxa2xx_ac97_ac97); @@ -335,8 +340,21 @@ static int __devinit pxa2xx_ac97_probe(struct platform_device *dev) #ifdef CONFIG_PXA27x /* Use GPIO 113 as AC97 Reset on Bulverde */ pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + ac97conf_clk = clk_get(&dev->dev, "AC97CONFCLK"); + if (IS_ERR(ac97conf_clk)) { + ret = PTR_ERR(ac97conf_clk); + ac97conf_clk = NULL; + goto err; + } #endif - pxa_set_cken(CKEN_AC97, 1); + + ac97_clk = clk_get(&dev->dev, "AC97CLK"); + if (IS_ERR(ac97_clk)) { + ret = PTR_ERR(ac97_clk); + ac97_clk = NULL; + goto err; + } + clk_enable(ac97_clk); ret = snd_ac97_bus(card, 0, &pxa2xx_ac97_ops, NULL, &ac97_bus); if (ret) @@ -361,11 +379,19 @@ static int __devinit pxa2xx_ac97_probe(struct platform_device *dev) err: if (card) snd_card_free(card); - if (CKEN & (1 << CKEN_AC97)) { + if (ac97_clk) { GCR |= GCR_ACLINK_OFF; free_irq(IRQ_AC97, NULL); - pxa_set_cken(CKEN_AC97, 0); + clk_disable(ac97_clk); + clk_put(ac97_clk); + ac97_clk = NULL; + } +#ifdef CONFIG_PXA27x + if (ac97conf_clk) { + clk_put(ac97conf_clk); + ac97conf_clk = NULL; } +#endif return ret; } @@ -378,7 +404,13 @@ static int __devexit pxa2xx_ac97_remove(struct platform_device *dev) platform_set_drvdata(dev, NULL); GCR |= GCR_ACLINK_OFF; free_irq(IRQ_AC97, NULL); - pxa_set_cken(CKEN_AC97, 0); + clk_disable(ac97_clk); + clk_put(ac97_clk); + ac97_clk = NULL; +#ifdef CONFIG_PXA27x + clk_put(ac97conf_clk); + ac97conf_clk = NULL; +#endif } return 0; -- 1.5.4.3

2 1

[alsa-devel] ALSA C++ API updated for 1.0.16
by Lasse Kärkkäinen 01 Mar '08

01 Mar '08

Here's an updated version of the C++ wrapper that I posted earlier in September 2007. I would like this to be included in the ALSA distribution after some peer review. This wrapper has been used in UltraStar NG (a game shipped by Gentoo and others) since September, with no known issues other than that it is incomplete (very PCM-centric). As a reminder, the API closely follows the C API, and also allows mixing direct C API calls with itself transparently.

4 6

[alsa-devel] [PATCH 4/4] Convert non-SoC PXA2xx AC97 driver to clock API
by Mark Brown 29 Feb '08

29 Feb '08

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Acked-by: Takashi Iwai <tiwai(a)suse.de> Cc: alsa-devel(a)alsa-project.org --- sound/arm/pxa2xx-ac97.c | 48 +++++++++++++++++++++++++++++++++++++++------- 1 files changed, 40 insertions(+), 8 deletions(-) diff --git a/sound/arm/pxa2xx-ac97.c b/sound/arm/pxa2xx-ac97.c index 5d86e68..fd7bc86 100644 --- a/sound/arm/pxa2xx-ac97.c +++ b/sound/arm/pxa2xx-ac97.c @@ -16,6 +16,7 @@ #include <linux/platform_device.h> #include <linux/interrupt.h> #include <linux/wait.h> +#include <linux/clk.h> #include <linux/delay.h> #include <sound/core.h> @@ -35,6 +36,10 @@ static DEFINE_MUTEX(car_mutex); static DECLARE_WAIT_QUEUE_HEAD(gsr_wq); static volatile long gsr_bits; +static struct clk *ac97_clk; +#ifdef CONFIG_PXA27x +static struct clk *ac97conf_clk; +#endif /* * Beware PXA27x bugs: @@ -112,9 +117,9 @@ static void pxa2xx_ac97_reset(struct snd_ac97 *ac97) gsr_bits = 0; #ifdef CONFIG_PXA27x /* PXA27x Developers Manual section 13.5.2.2.1 */ - pxa_set_cken(CKEN_AC97CONF, 1); + clk_enable(ac97conf_clk); udelay(5); - pxa_set_cken(CKEN_AC97CONF, 0); + clk_disable(ac97conf_clk); GCR = GCR_COLD_RST; udelay(50); #else @@ -259,7 +264,7 @@ static int pxa2xx_ac97_do_suspend(struct snd_card *card, pm_message_t state) if (platform_ops && platform_ops->suspend) platform_ops->suspend(platform_ops->priv); GCR |= GCR_ACLINK_OFF; - pxa_set_cken(CKEN_AC97, 0); + clk_disable(ac97_clk); return 0; } @@ -268,7 +273,7 @@ static int pxa2xx_ac97_do_resume(struct snd_card *card) { pxa2xx_audio_ops_t *platform_ops = card->dev->platform_data; - pxa_set_cken(CKEN_AC97, 1); + clk_enable(ac97_clk); if (platform_ops && platform_ops->resume) platform_ops->resume(platform_ops->priv); snd_ac97_resume(pxa2xx_ac97_ac97); @@ -335,8 +340,21 @@ static int __devinit pxa2xx_ac97_probe(struct platform_device *dev) #ifdef CONFIG_PXA27x /* Use GPIO 113 as AC97 Reset on Bulverde */ pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + ac97conf_clk = clk_get(&dev->dev, "AC97CONFCLK"); + if (IS_ERR(ac97conf_clk)) { + ret = PTR_ERR(ac97conf_clk); + ac97conf_clk = NULL; + goto err; + } #endif - pxa_set_cken(CKEN_AC97, 1); + + ac97_clk = clk_get(&dev->dev, "AC97CLK"); + if (IS_ERR(ac97_clk)) { + ret = PTR_ERR(ac97_clk); + ac97_clk = NULL; + goto err; + } + clk_enable(ac97_clk); ret = snd_ac97_bus(card, 0, &pxa2xx_ac97_ops, NULL, &ac97_bus); if (ret) @@ -361,11 +379,19 @@ static int __devinit pxa2xx_ac97_probe(struct platform_device *dev) err: if (card) snd_card_free(card); - if (CKEN & (1 << CKEN_AC97)) { + if (ac97_clk) { GCR |= GCR_ACLINK_OFF; free_irq(IRQ_AC97, NULL); - pxa_set_cken(CKEN_AC97, 0); + clk_disable(ac97_clk); + clk_put(ac97_clk); + ac97_clk = NULL; + } +#ifdef CONFIG_PXA27x + if (ac97conf_clk) { + clk_put(ac97conf_clk); + ac97conf_clk = NULL; } +#endif return ret; } @@ -378,7 +404,13 @@ static int __devexit pxa2xx_ac97_remove(struct platform_device *dev) platform_set_drvdata(dev, NULL); GCR |= GCR_ACLINK_OFF; free_irq(IRQ_AC97, NULL); - pxa_set_cken(CKEN_AC97, 0); + clk_disable(ac97_clk); + clk_put(ac97_clk); + ac97_clk = NULL; +#ifdef CONFIG_PXA27x + clk_put(ac97conf_clk); + ac97conf_clk = NULL; +#endif } return 0; -- 1.5.4.3

1 0

[alsa-devel] [PATCH] hda: incorrect DAC mixer on 92hd71bxxx
by Matthew Ranostay 29 Feb '08

29 Feb '08

If there was two line_outs[] it would overrun into the dmic nid struct below and create a phantom "Surround" mixer. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 54a51b975975 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Thu Feb 28 12:46:32 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Thu Feb 28 16:52:43 2008 -0500 @@ -246,8 +246,8 @@ static hda_nid_t stac92hd71bxx_dmux_nids 0x1c, }; -static hda_nid_t stac92hd71bxx_dac_nids[1] = { - 0x10, /*0x11, */ +static hda_nid_t stac92hd71bxx_dac_nids[2] = { + 0x10, 0x11 }; #define STAC92HD71BXX_NUM_DMICS 2 @@ -2345,10 +2345,10 @@ static int stac92xx_auto_create_multi_ou for (i = 0; i < cfg->line_outs; i++) { - if (!spec->multiout.dac_nids[i]) + + nid = spec->multiout.dac_nids[i]; + if (!nid || nid == spec->multiout.hp_nid) continue; - - nid = spec->multiout.dac_nids[i]; if (i == 2) { /* Center/LFE */ @@ -3550,7 +3550,7 @@ again: spec->num_pwrs = ARRAY_SIZE(stac92hd71bxx_pwr_nids); spec->pwr_nids = stac92hd71bxx_pwr_nids; - spec->multiout.num_dacs = 1; + spec->multiout.num_dacs = ARRAY_SIZE(stac92hd71bxx_dac_nids); spec->multiout.hp_nid = 0x11; spec->multiout.dac_nids = stac92hd71bxx_dac_nids;

2 3

[alsa-devel] [PATCH] hda: 92HD
by Matthew Ranostay 29 Feb '08

29 Feb '08

Added core_init[] for several 92hd73xxx laptops. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 54a51b975975 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Thu Feb 28 12:46:32 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Thu Feb 28 21:14:39 2008 -0500 @@ -525,6 +525,24 @@ static struct hda_verb stac92hd73xx_6ch_ { 0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, { 0x10, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, { 0x11, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, + /* setup import muxs */ + { 0x28, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x29, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x2a, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x2b, AC_VERB_SET_CONNECT_SEL, 0x00}, + {} +}; + +static struct hda_verb dell_m6_core_init[] = { + /* set master volume and direct control */ + { 0x1f, AC_VERB_SET_VOLUME_KNOB_CONTROL, 0xff}, + /* setup audio connections */ + { 0x0a, AC_VERB_SET_CONNECT_SEL, 0x00}, + { 0x0d, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x02}, + /* setup adcs to point to mixer */ + { 0x20, AC_VERB_SET_CONNECT_SEL, 0x0b}, + { 0x21, AC_VERB_SET_CONNECT_SEL, 0x0b}, /* setup import muxs */ { 0x28, AC_VERB_SET_CONNECT_SEL, 0x01}, { 0x29, AC_VERB_SET_CONNECT_SEL, 0x01}, @@ -3437,6 +3455,7 @@ again: switch (spec->board_config) { case STAC_DELL_M6: + spec->init = dell_m6_core_init; switch (codec->subsystem_id) { case 0x1028025e: /* Analog Mics */ case 0x1028025f:

2 2

[alsa-devel] [PATCH] IEC958 definitions for consumer status channel, byte 4
by Pawel MOLL 29 Feb '08

29 Feb '08

Hi, Attached are patches for alsa-kernel and alsa-lib, adding mentioned definitions. Regards Paweł

2 1

[alsa-devel] [PATCH] hda: disable power management on fixed ports.
by Matthew Ranostay 29 Feb '08

29 Feb '08

Power management can't be enabled on fixed ports, since the presence will always return false and prevent output. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 54a51b975975 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Thu Feb 28 12:46:32 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Thu Feb 28 20:39:28 2008 -0500 @@ -3015,11 +3015,15 @@ static int stac92xx_init(struct hda_code ? STAC_HP_EVENT : STAC_PWR_EVENT; int pinctl = snd_hda_codec_read(codec, spec->pwr_nids[i], 0, AC_VERB_GET_PIN_WIDGET_CONTROL, 0); + int def_conf = snd_hda_codec_read(codec, spec->pwr_nids[i], + 0, AC_VERB_GET_CONFIG_DEFAULT, 0); /* outputs are only ports capable of power management * any attempts on powering down a input port cause the * referenced VREF to act quirky. */ if (pinctl & AC_PINCTL_IN_EN) + continue; + if (get_defcfg_connect(def_conf) != AC_JACK_PORT_FIXED) continue; enable_pin_detect(codec, spec->pwr_nids[i], event | i); codec->patch_ops.unsol_event(codec, (event | i) << 26);

2 1

[alsa-devel] [PATCH] hda/patch_sigmatel.c Panasonic CF-74 speaker output
by Kyler Laird 29 Feb '08

29 Feb '08

This patch causes ALSA to send sound to the speakers of a Panasonic CF-74 (Toughbook) instead of just its headphone jack. --kyler diff -Naur linux-2.6.24.1/sound/pci/hda/patch_sigmatel.c linux-2.6.24.1-ALSA_CF74/sound/pci/hda/patch_sigmatel.c --- linux-2.6.24.1/sound/pci/hda/patch_sigmatel.c 2008-02-08 14:55:30.000000000 -0500 +++ linux-2.6.24.1-ALSA_CF74/sound/pci/hda/patch_sigmatel.c 2008-02-11 12:05:11.824064617 -0500 @@ -2467,6 +2467,11 @@ spec->init = stac9200_core_init; spec->mixer = stac9200_mixer; + /* Kyler - fix for CF-74 speaker */ + spec->gpio_mask = 0x00000009; + spec->gpio_data = 0x00000000; + stac92xx_enable_gpio_mask(codec); + err = stac9200_parse_auto_config(codec); if (err < 0) { stac92xx_free(codec);

2 1

Re: [alsa-devel] How to set idle S/PDIF sample rate?
by Demian Martin 29 Feb '08

29 Feb '08

I noticed another big problem in my application relating to locking the system at 48 KHz in the background. If I set SPDIF to 44.1KHz on some playback software (Xine for example) between tracks the system briefly switches back to 48 KHz. This causes an audible pop as the external DAC tries to keep up with the rate change. I have not found a way to lock the system at a different rate (44100 for example) so this doesn't happen between tracks. This behavior is common to both the ICE1724 and the VT1708 drivers. -Demian Date: Thu, 28 Feb 2008 16:12:10 -0500 From: Matt Whitlock <matt(a)whitlock.name> Subject: Re: [alsa-devel] How to set idle S/PDIF sample rate? To: Takashi Iwai <tiwai(a)suse.de> Cc: alsa-devel(a)alsa-project.org Message-ID: <200802281612.11099.matt(a)whitlock.name> Content-Type: text/plain; charset="iso-8859-1" On Thursday, 28 February 2008 6:43:25 am Takashi Iwai wrote: > The driver code resets the format verb of the relevant widgets at > closing streams. This verb contains the sample rate, too. Maybe > keeping this would prevent the reset. > > The below is a test patch. Give it a try. Wow, fantastic. I will give this patch a try. I'll have to rebuild my kernel to disable the in-kernel ALSA code and build the ALSA module separately from the latest sources, but if this patch fixes things, that would be worth the effort. I'll get back to you. Thanks. -Matt

2 1

[alsa-devel] How to set idle S/PDIF sample rate?
by Matt Whitlock 28 Feb '08

28 Feb '08

When no programs have the sound hardware open, ALSA drives my Intel HDA's S/PDIF output with silence at 48000 Hz. How would I change this default so that the idle sample rate is 44100 Hz? The reason I ask is that my stereo receiver misses the first second or so of each song that I play as it switches from 48000 Hz to 44100 Hz. I understand that by switching the idle sample rate to 44100 Hz, I would have the same problem whenever playing a DVD, but I can much more happily accept the switching delay when starting DVDs than I can when starting music playback. I've tried everything, including replacing /usr/share/alsa/alsa.conf with a single PCM definition that outputs straight to hardware with "rate 44100", but still, whenever nothing is accessing the sound hardware, ALSA reverts to 48000-Hz silence. There must be a way to influence that, right? Alternatively, if ALSA would simply not output anything over S/PDIF when idle, my receiver could just stay at 44100 Hz, albeit unlocked since there would be no data stream at all. So this is also an acceptable solution to me, but I cannot find any way to make ALSA totally shut up when idle. It always wants to output silence. Interestingly, if I mute the IEC958 playback channel and then unmute it, my receiver reports no signal at all until I play a sound, and then after the sound finishes, my receiver reports that it is locked onto PCM at 48000 Hz. Seems kind of like a bug, doesn't it? Thanks to anyone who can lend some assistance.

3 10

[alsa-devel] [PATCH 0/2] Fixes to couple DAPM widget functions
by Jarkko Nikula 28 Feb '08

28 Feb '08

API change done by the commit 9af6d9562414568ecadf96aaef5b88e7e8b19821, "[ALSA] soc - Add support for passing kcontrols with events", doesn't change affected pxa machine and wm9712 drivers. These two patches are generated from master branch of linux-2.6-asoc tree but they apply to alsa git and alsa-kernel hg trees as well. I separated wm9712 to own patch since it is ok in asoc-v2-dev branch. There are other drivers as well with this error in asoc-v2-dev but I don't know are they already in progress? I can post a another patch to them if needed. -- Jarkko

3 6

[alsa-devel] Using ARRAY_SIZE macro when setting up ASoC audio map?
by Jarkko Nikula 28 Feb '08

28 Feb '08

Does an example patch to spitz below make any sense? Yep, noticed when forgot to add array terminator to own code :-) diff --git a/sound/soc/pxa/spitz.c b/sound/soc/pxa/spitz.c index d56709e..1cffcd3 100644 --- a/sound/soc/pxa/spitz.c +++ b/sound/soc/pxa/spitz.c @@ -268,8 +268,6 @@ static const char *audio_map[][3] = { /* line is connected to input 1 - no bias */ {"LINPUT1", NULL, "Line Jack"}, - - {NULL, NULL, NULL}, }; static const char *jack_function[] = {"Headphone", "Mic", "Line", "Headset", @@ -317,7 +315,7 @@ static int spitz_wm8750_init(struct snd_soc_codec *codec) } /* Set up spitz specific audio path audio_map */ - for (i = 0; audio_map[i][0] != NULL; i++) { + for (i = 0; i < ARRAY_SIZE(audio_map); i++) { snd_soc_dapm_connect_input(codec, audio_map[i][0], audio_map[i][1], audio_map[i][2]); }

3 5