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

[alsa-devel] [PATCH 1/2] HDA: Fix digital microphone on CS420x
by Daniel J Blueman 05 Nov '12

05 Nov '12

Correctly enable the digital microphones with the right bits in the right coeffecient registers on Cirrus CS4206/7 codecs. It also prevents misconfiguring ADC1/2. This fixes the digital mic on the Macbook Pro 10,1/Retina. Based-on-patch-by: Alexander Stein <alexander.stein(a)systec-electronic.com> Signed-off-by: Daniel J Blueman <daniel(a)quora.org> --- sound/pci/hda/patch_cirrus.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c index 61a7113..859a119 100644 --- a/sound/pci/hda/patch_cirrus.c +++ b/sound/pci/hda/patch_cirrus.c @@ -101,8 +101,8 @@ enum { #define CS420X_VENDOR_NID 0x11 #define CS_DIG_OUT1_PIN_NID 0x10 #define CS_DIG_OUT2_PIN_NID 0x15 -#define CS_DMIC1_PIN_NID 0x12 -#define CS_DMIC2_PIN_NID 0x0e +#define CS_DMIC1_PIN_NID 0x0e +#define CS_DMIC2_PIN_NID 0x12 /* coef indices */ #define IDX_SPDIF_STAT 0x0000 @@ -1079,14 +1079,18 @@ static void init_input(struct hda_codec *codec) cs_automic(codec, NULL); coef = 0x000a; /* ADC1/2 - Digital and Analog Soft Ramp */ + cs_vendor_coef_set(codec, IDX_ADC_CFG, coef); + + coef = cs_vendor_coef_get(codec, IDX_BEEP_CFG); if (is_active_pin(codec, CS_DMIC2_PIN_NID)) - coef |= 0x0500; /* DMIC2 2 chan on, GPIO1 off */ + coef |= 1 << 4; /* DMIC2 2 chan on, GPIO1 off */ if (is_active_pin(codec, CS_DMIC1_PIN_NID)) - coef |= 0x1800; /* DMIC1 2 chan on, GPIO0 off + coef |= 1 << 3; /* DMIC1 2 chan on, GPIO0 off * No effect if SPDIF_OUT2 is * selected in IDX_SPDIF_CTL. */ - cs_vendor_coef_set(codec, IDX_ADC_CFG, coef); + + cs_vendor_coef_set(codec, IDX_BEEP_CFG, coef); } else { if (spec->mic_detect) cs_automic(codec, NULL); -- 1.7.10.4

2 4

[alsa-devel] ad1988 spdif crackling (includes patch)
by Robin Kreis 05 Nov '12

05 Nov '12

Hi! For nearly three years, a bug has been known to cripple SPDIF output on certain hardware. It might work fine for a while, but will randomly break, showing two symptoms: PCM audio is distorted (similar to clipping) while compressed audio (AC3 or DTS) will not work at all. Muting an unmuting the master channel may temporarily fix it. This affects at least all Asus P5B and P6B mainboards. The solution is a simple one-liner, and has been known for a year: http://fjerhammer.dk/ad1988_spdif_crackling.patch (credits go to Javeed Shaikh for the patch and fjerhammer for hosting it). I can verify that it fixes all issues on my setup. Please apply it. See also: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/359361 Greetings, Robin Kreis

3 2

[alsa-devel] [PATCH v2 1/2] ASoC: tlv320aic32x4: Fix problem with first capture.
by Javier Martin 05 Nov '12

05 Nov '12

In its previous status, the first capture didn't work properly; nothing was actually recorded from the microphone. This behaviour was observed using a Visstrim M10 board. In order to solve this BUG a workaround has been added that, during the initialization process of the codec, powers on and off the ADC. The issue seems related to a HW BUG or some behavior that is not documented in the datasheet. Signed-off-by: Javier Martin <javier.martin(a)vista-silicon.com> --- Changes since v1: - Use a subject line according to the ASoC subsystem. --- sound/soc/codecs/tlv320aic32x4.c | 10 ++++++++++ sound/soc/codecs/tlv320aic32x4.h | 3 +++ 2 files changed, 13 insertions(+) diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index b0a73d3..aad92f9 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -675,6 +675,16 @@ static int aic32x4_probe(struct snd_soc_codec *codec) ARRAY_SIZE(aic32x4_snd_controls)); aic32x4_add_widgets(codec); + /* + * Workaround: for an unknown reason, the ADC needs to be powered up + * and down for the first capture to work properly. It seems related to + * a HW BUG or some kind of behavior not documented in the datasheet. + */ + tmp_reg = snd_soc_read(codec, AIC32X4_ADCSETUP); + snd_soc_write(codec, AIC32X4_ADCSETUP, tmp_reg | + AIC32X4_LADC_EN | AIC32X4_RADC_EN); + snd_soc_write(codec, AIC32X4_ADCSETUP, tmp_reg); + return 0; } diff --git a/sound/soc/codecs/tlv320aic32x4.h b/sound/soc/codecs/tlv320aic32x4.h index aae2b24..3577422 100644 --- a/sound/soc/codecs/tlv320aic32x4.h +++ b/sound/soc/codecs/tlv320aic32x4.h @@ -94,6 +94,9 @@ #define AIC32X4_WORD_LEN_24BITS 0x02 #define AIC32X4_WORD_LEN_32BITS 0x03 +#define AIC32X4_LADC_EN (1 << 7) +#define AIC32X4_RADC_EN (1 << 6) + #define AIC32X4_I2S_MODE 0x00 #define AIC32X4_DSP_MODE 0x01 #define AIC32X4_RIGHT_JUSTIFIED_MODE 0x02 -- 1.7.9.5

3 8

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: make module reloadable
by Bo Shen 05 Nov '12

05 Nov '12

Hi Alexandre Belloni, On 11/1/2012 14:18, Alexandre Belloni wrote: > As the platform_devices were never unregistered, it was not possible to > unload/reload the module. > > Signed-off-by: Alexandre Belloni <alexandre.belloni(a)piout.net> > --- > sound/soc/atmel/atmel_ssc_dai.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) NACK - Thanks for your work on atmel ssc dai component. Now, I am reworking the atmel ssc dai audio framework. So, some of them will be none exist any more. Thanks again. Best regards, Bo Shen > diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c > index 354341e..07ee57b 100644 > --- a/sound/soc/atmel/atmel_ssc_dai.c > +++ b/sound/soc/atmel/atmel_ssc_dai.c > @@ -155,6 +155,8 @@ static struct atmel_ssc_info ssc_info[NUM_SSC_DEVICES] = { > #endif > }; > > +static struct platform_device *dma_pdev; > +static struct platform_device *ssc_pdevs[NUM_SSC_DEVICES]; > > /* > * SSC interrupt handler. Passes PDC interrupts to the DMA > @@ -796,6 +798,12 @@ static __devinit int asoc_ssc_probe(struct platform_device *pdev) > > static int __devexit asoc_ssc_remove(struct platform_device *pdev) > { > + int i; > + platform_device_unregister(dma_pdev); > + > + for(i = 0; i < NUM_SSC_DEVICES; i++) > + platform_device_unregister(ssc_pdevs[i]); > + > snd_soc_unregister_dai(&pdev->dev); > return 0; > } > @@ -816,7 +824,6 @@ static struct platform_driver asoc_ssc_driver = { > int atmel_ssc_set_audio(int ssc_id) > { > struct ssc_device *ssc; > - static struct platform_device *dma_pdev; > struct platform_device *ssc_pdev; > int ret; > > @@ -855,6 +862,8 @@ int atmel_ssc_set_audio(int ssc_id) > if (ret < 0) > platform_device_put(ssc_pdev); > > + ssc_pdevs[ssc_id] = ssc_pdev; > + > return ret; > } > EXPORT_SYMBOL_GPL(atmel_ssc_set_audio); >

1 0

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 04 Nov '12

04 Nov '12

[cc alsa-devel] On 04.11.2012 02:25, Jeffrey Barish wrote: > On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: >> On Fri 26 October 2012 21:47:05 Daniel Mack wrote: >>> On 26.10.2012 21:43, Jeffrey Barish wrote: >>>> On Thu 25 October 2012 19:10:45 Daniel Mack wrote: >>>>> On 25.10.2012 17:18, Jeffrey Barish wrote: >>>>>> I found something in the snd_usb_audio code (in endpoint.c) that could >>>>>> explain one of the problems I have observed (the ticks). I would >>>>>> normally test my theory by modifying the code. In this case, I would >>>>>> like to stick in a print statement to see what values are being >>>>>> assigned >>>>>> to certain variables. Unfortunately, I am too ignorant to do something >>>>>> even this trivial as I have never worked on kernel code. I think I am >>>>>> supposed to use printk, >>>>> >>>>> printk is nice for simple debugging, yes. But note that this call is >>>>> timing critical and should not be used in "fast path" code. Introducing >>>>> a printk for each received packet for example will almost certainly >>>>> make >>>>> the driver behave quite differently. >>>>> >>>>>> but beyond that I am lost. Can someone provide >>>>>> me with some directions? I need to know how to make the driver. To >>>>>> that >>>>>> end, I probably will have to install additional packages. After making >>>>>> the driver, I need to know how to install it over the existing driver. >>>>> >>>>> Here's one way to do it: >>>>> >>>>> 1. git clone >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your >>>>> patch should apply on top of this tree eventually) >>>>> 2. cd sound >>>>> 3. zcat /proc/config.gz >.config >>>>> 4. build and install the kernel image. How that is done depends on the >>>>> distribution you're using. For Ubuntu follow the docs at [1] (start at >>>>> point #5). For Fedora and others, something like "make && make install" >>>>> should do >>>>> 5. reboot and check that the new kernel is running >>>>> 6. hack on sound/usb >>>>> 7. make M=sound/usb >>>>> 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod >>>>> sound/usb/snd-usb-audio.ko" (better plug out the device before so you >>>>> always have the same defined point of start) >>>>> >>>>> >>>>> Hope that works for you. >>>>> >>>>> >>>>> Daniel >>>>> >>>>> [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild >>>> >>>> Your directions were almost perfect, so even I was able to build the >>>> kernel. I made a discovery using the new kernel that might help someone >>>> more familiar with the code than I am to localize the problem. I am >>>> still hearing the blip when I play audio sampled at 88.2 kHz, but I just >>>> noticed that the blip is perfectly periodic, with a period of about 16.4 >>>> seconds. I am playing a sine wave synthesized using GStreamer using the >>>> following command: >>>> >>>> gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, >>>> rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink >>>> >>>> A sine wave makes it easier to hear the blip. Does this clue suggest >>>> anything? >>>> >>>> I also want to mention that when I use the new kernel, I do not get the >>>> ticks at either 88.2 or 96 kHz even when I do not use the external USB >>>> hub. I plan next to back up to the 3.6.2 kernel to see whether I still >>>> get ticks there. >>> >>> Which kernel did you use when you heard the 'blibs'? >> >> The latest news is bad. I am on 3.2.0 now. The USB DAC is working >> perfectly at this moment at both 96 kHz and 88.2 kHz without the external >> USB hub (imagine calling that bad news). If I set the srate to 88.2 kHz >> and stop and start the sine wave, sometimes I get the blip. Forget about >> its being periodic. It was definitely periodic before lunch; now I usually >> get random intervals if I get any blips at all. As I am typing this >> message, I can't get blips at all. There was some correlation between >> changing sample rates and blips, but I can't reproduce that behavior now. >> What is most weird is that I haven't gotten any ticks since lunch with any >> kernel or with either sample rate, yet they were reliable earlier today >> unless I used the external USB hub. I obviously need to experiment some >> more to see whether I can observe a pattern. > > To conclude (?) this thread, I am now convinced that the anomalies I observed > were unrelated to the device driver. I had two theories remaining. One was > that the problem was somehow related to an overheating problem. I used a heat > gun to convince myself that the theory was wrong. The other was that the > problem had something to do with services running in the background that > interfered with the device driver. I removed or disabled all services that I > could identify as superfluous. Removed services include zeitgeist, apparmor, > modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, > and pppd-dns. The system has been running perfectly with an 88.2 kHz sample > rate and no external USB hub for 2 days. However, I tried booting the system > with a copy of the OS from before I removed superfluous services. It still ran > perfectly. Thus, I cannot convince myself that removing superfluous services > actually solved the problem. I suppose it's possible that some service was > running sporadically, which could explain why the problem seemed to come and > go and also why the problem did not occur when I booted the copy of the OS. > As long as the problem remains dormant I have no alternative but to move on > and see whether the problem eventually recurs. Only time will tell. > > Thanks for all the help. Hey, I built a kernel and got my own version of the > device driver to run. That was exciting. > > ------------------------------------------------------------------------------ > > I'm back. The USB DAC continued to work for two more days after my last > message and then the blips resumed. I've been digging into the driver code > for two days. I spent today trying to convince myself that the driver is > actually using an asynchronous protocol. The blips are almost certainly buffer > underruns, which I could account for if the driver were not responding to > asynchronous feedback from the DAC. I expected to see a deviation from the > pattern of one frame with 89 samples followed by 4 frames with 88 (which > results in 88,200 samples per second). That sequence would work perfectly if > the clocks in the computer and in the USB DAC were exactly the same frequency, > but of course they are not. Consequently, I would expect to see requests for > one sample more or less once in a while, depending on whether the clock in the > computer is slower or faster than the one in the DAC. What I see is 89 + 4 * > 88 almost all the time, as expected . Once in a while there is a request for > an additional frame of 88 and then the pattern of 89 + 4 * 88 resumes. I > presume that the break in the usual pattern indicates that the device driver > is responding to a request from the DAC for fewer samples, which confirms that > the driver is using the asynchronous protocol. That's good, if I am right. > However, sticking in an extra packet of only 88 would be the expected > deviation if the host were getting a little ahead of the DAC, yet the blip is > almost certainly a buffer underrun, which means that the host is actually > falling behind. Thus, an extra packet of 89 would make more sense. I should > also mention that there is no correlation between the timing of the extra > packet of 88 and the audible blip. Something seems wrong here, but I'm not > sure where to go next. > > On a related topic, to confirm that the blip is a buffer underrun, I would like > to synthesize a waveform that is DC. With DC, an overrun would not produce > any audible anomalies whereas an underrun would be audible. I am using > GStreamer to synthesize the test waveform. Does anyone know of a way to > synthesize a DC waveform using GStreamer? If not, is there any other tool > available in Linux? > > By the way, I bought another USB DAC from a different manufacturer to be sure > that the anomalies I am observing were not due to a defect in the DAC. They > both display the same problem. > > ----------------------------------------------------- > > I modified the device driver to output a constant instead of the incoming > waveform. I get blips, as I expected, so I am now certain that the blips are > caused by a buffer underrun. The blips occur periodically again -- period of > about 16.5 seconds. I presume that the period is related to the difference in > clock rates between the host and DAC. Roughly every 3-4 blips, I get an extra > packet of 88 samples. To prevent buffer underrun, I ought to be getting an > extra packet of 89 samples every 16.5 seconds, but I never do. Thanks for all your investigation on this! Sending computed data instead of the payload delivered by the ALSA stack is in fact a very good way to isolate the issue. The question is: if the algorithm in the USB driver miscalculates the number of samples to send over time, what't the reason for that? Does the device report bogus values or is there this a bug in the driver? Did you read chapter 5.4.12.1 of the USB2.0 spec, and can you explain where you suspect the bug to be? The current implementation in the driver is quite straight forward, mapping all feedback values to Q16.16 and keeping the lower 16bits around for phase compensation between the calculation of the packet sizes. If you find a better solution, please share it here, preferably in the form of a patch :) Thanks, Daniel

1 0

[alsa-devel] [PATCH 5/9] ASoC: Only compile adav80x codec when a bus is defined
by Lee Jones 04 Nov '12

04 Nov '12

If !CONFIG_SPI and !CONFIG_I2C* then there is no point adding support for the adav80x codec as it relies on a bus to operate. This patch fixes the build warnings below when SPI and I2C are not specified in the configuration. sound/soc/codecs/adav80x.c:842:22: warning: ‘adav80x_bus_probe’ defined but not used [-Wunused-function] sound/soc/codecs/adav80x.c:863:22: warning: ‘adav80x_bus_remove’ defined but not used [-Wunused-function] Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Lee Jones <lee.jones(a)linaro.org> --- sound/soc/codecs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index b92759a..0d8135a 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -19,7 +19,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AD1980 if SND_SOC_AC97_BUS select SND_SOC_AD73311 select SND_SOC_ADAU1373 if I2C - select SND_SOC_ADAV80X + select SND_SOC_ADAV80X if (I2C || I2C_MODULE || SPI_MASTER) select SND_SOC_ADS117X select SND_SOC_AK4104 if SPI_MASTER select SND_SOC_AK4535 if I2C -- 1.7.9.5

2 2

[alsa-devel] [PATCH] snd-es1968: remove pm_whitelist
by Ondrej Zary 04 Nov '12

04 Nov '12

pm_whitelist breaks suspend on all non-whitelisted cards for unknown purpose. Remove it. This fixes suspend on Terratec DMX and SF64-PCE2 cards. Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> --- sound/pci/es1968.c | 40 ---------------------------------------- 1 files changed, 0 insertions(+), 40 deletions(-) diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index 5d0e568..a9c92a4 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -137,7 +137,6 @@ static int total_bufsize[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 1024 }; static int pcm_substreams_p[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 4 }; static int pcm_substreams_c[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 1 }; static int clock[SNDRV_CARDS]; -static int use_pm[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 2}; static int enable_mpu[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 2}; #ifdef SUPPORT_JOYSTICK static bool joystick[SNDRV_CARDS]; @@ -158,8 +157,6 @@ module_param_array(pcm_substreams_c, int, NULL, 0444); MODULE_PARM_DESC(pcm_substreams_c, "PCM Capture substreams for " CARD_NAME " soundcard."); module_param_array(clock, int, NULL, 0444); MODULE_PARM_DESC(clock, "Clock on " CARD_NAME " soundcard. (0 = auto-detect)"); -module_param_array(use_pm, int, NULL, 0444); -MODULE_PARM_DESC(use_pm, "Toggle power-management. (0 = off, 1 = on, 2 = auto)"); module_param_array(enable_mpu, int, NULL, 0444); MODULE_PARM_DESC(enable_mpu, "Enable MPU401. (0 = off, 1 = on, 2 = auto)"); #ifdef SUPPORT_JOYSTICK @@ -519,7 +516,6 @@ struct es1968 { struct pci_dev *pci; struct snd_card *card; struct snd_pcm *pcm; - int do_pm; /* power-management enabled */ /* DMA memory block */ struct list_head buf_list; @@ -2387,9 +2383,6 @@ static int es1968_suspend(struct device *dev) struct snd_card *card = dev_get_drvdata(dev); struct es1968 *chip = card->private_data; - if (! chip->do_pm) - return 0; - chip->in_suspend = 1; cancel_work_sync(&chip->hwvol_work); snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); @@ -2410,9 +2403,6 @@ static int es1968_resume(struct device *dev) struct es1968 *chip = card->private_data; struct esschan *es; - if (! chip->do_pm) - return 0; - /* restore all our config */ pci_set_power_state(pci, PCI_D0); pci_restore_state(pci); @@ -2648,15 +2638,6 @@ struct ess_device_list { unsigned short vendor; /* subsystem vendor id */ }; -static struct ess_device_list pm_whitelist[] __devinitdata = { - { TYPE_MAESTRO2E, 0x0e11 }, /* Compaq Armada */ - { TYPE_MAESTRO2E, 0x1028 }, - { TYPE_MAESTRO2E, 0x103c }, - { TYPE_MAESTRO2E, 0x1179 }, - { TYPE_MAESTRO2E, 0x14c0 }, /* HP omnibook 4150 */ - { TYPE_MAESTRO2E, 0x1558 }, -}; - static struct ess_device_list mpu_blacklist[] __devinitdata = { { TYPE_MAESTRO2, 0x125d }, }; @@ -2667,7 +2648,6 @@ static int __devinit snd_es1968_create(struct snd_card *card, int play_streams, int capt_streams, int chip_type, - int do_pm, int radio_nr, struct es1968 **chip_ret) { @@ -2736,25 +2716,6 @@ static int __devinit snd_es1968_create(struct snd_card *card, /* just to be sure */ pci_set_master(pci); - if (do_pm > 1) { - /* disable power-management if not on the whitelist */ - unsigned short vend; - pci_read_config_word(chip->pci, PCI_SUBSYSTEM_VENDOR_ID, &vend); - for (i = 0; i < (int)ARRAY_SIZE(pm_whitelist); i++) { - if (chip->type == pm_whitelist[i].type && - vend == pm_whitelist[i].vendor) { - do_pm = 1; - break; - } - } - if (do_pm > 1) { - /* not matched; disabling pm */ - printk(KERN_INFO "es1968: not attempting power management.\n"); - do_pm = 0; - } - } - chip->do_pm = do_pm; - snd_es1968_chip_init(chip); if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops)) < 0) { @@ -2817,7 +2778,6 @@ static int __devinit snd_es1968_probe(struct pci_dev *pci, pcm_substreams_p[dev], pcm_substreams_c[dev], pci_id->driver_data, - use_pm[dev], radio_nr[dev], &chip)) < 0) { snd_card_free(card); -- Ondrej Zary

3 3

[alsa-devel] [PATCH] ALSA: hda - support Teradici 2200 host card audio
by Lars R. Damerow 04 Nov '12

04 Nov '12

Hello, This patch adds support for Teradici's new Tera2 host card audio. The new card has the same audio chipset as the previous version, so all it's doing is recognizing the new PCI ID and treating it just like the previous one. thanks, -lars Lars R. Damerow (1): ALSA: hda - support Teradici 2200 host card audio sound/pci/hda/hda_intel.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)

2 2

[alsa-devel] [PATCH] [trivial] sound: Fix typo in drivers sound
by Masanari Iida 04 Nov '12

04 Nov '12

Correct spelling typo in debug messages within drivers/sound Signed-off-by: Masanari Iida <standby24x7(a)gmail.com> --- sound/i2c/other/ak4113.c | 2 +- sound/i2c/other/ak4114.c | 2 +- sound/i2c/other/ak4117.c | 2 +- sound/pci/rme9652/hdspm.c | 2 +- sound/soc/codecs/cs42l52.c | 2 +- sound/soc/codecs/wm8994.c | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/sound/i2c/other/ak4113.c b/sound/i2c/other/ak4113.c index ef68d71..e04e750 100644 --- a/sound/i2c/other/ak4113.c +++ b/sound/i2c/other/ak4113.c @@ -426,7 +426,7 @@ static struct snd_kcontrol_new snd_ak4113_iec958_controls[] = { }, { .iface = SNDRV_CTL_ELEM_IFACE_PCM, - .name = "IEC958 Preample Capture Default", + .name = "IEC958 Preamble Capture Default", .access = SNDRV_CTL_ELEM_ACCESS_READ | SNDRV_CTL_ELEM_ACCESS_VOLATILE, .info = snd_ak4113_spdif_pinfo, diff --git a/sound/i2c/other/ak4114.c b/sound/i2c/other/ak4114.c index 816e7d2..5bf4fca 100644 --- a/sound/i2c/other/ak4114.c +++ b/sound/i2c/other/ak4114.c @@ -401,7 +401,7 @@ static struct snd_kcontrol_new snd_ak4114_iec958_controls[] = { }, { .iface = SNDRV_CTL_ELEM_IFACE_PCM, - .name = "IEC958 Preample Capture Default", + .name = "IEC958 Preamble Capture Default", .access = SNDRV_CTL_ELEM_ACCESS_READ | SNDRV_CTL_ELEM_ACCESS_VOLATILE, .info = snd_ak4114_spdif_pinfo, .get = snd_ak4114_spdif_pget, diff --git a/sound/i2c/other/ak4117.c b/sound/i2c/other/ak4117.c index b4b2a51..40e33c9 100644 --- a/sound/i2c/other/ak4117.c +++ b/sound/i2c/other/ak4117.c @@ -380,7 +380,7 @@ static struct snd_kcontrol_new snd_ak4117_iec958_controls[] = { }, { .iface = SNDRV_CTL_ELEM_IFACE_PCM, - .name = "IEC958 Preample Capture Default", + .name = "IEC958 Preamble Capture Default", .access = SNDRV_CTL_ELEM_ACCESS_READ | SNDRV_CTL_ELEM_ACCESS_VOLATILE, .info = snd_ak4117_spdif_pinfo, .get = snd_ak4117_spdif_pget, diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c index f1cd1e3..9a8d5ce 100644 --- a/sound/pci/rme9652/hdspm.c +++ b/sound/pci/rme9652/hdspm.c @@ -4899,7 +4899,7 @@ snd_hdspm_proc_read_madi(struct snd_info_entry * entry, insel = "Coaxial"; break; default: - insel = "Unkown"; + insel = "Unknown"; } snd_iprintf(buffer, diff --git a/sound/soc/codecs/cs42l52.c b/sound/soc/codecs/cs42l52.c index 6159929..4d8db36 100644 --- a/sound/soc/codecs/cs42l52.c +++ b/sound/soc/codecs/cs42l52.c @@ -763,7 +763,7 @@ static int cs42l52_set_sysclk(struct snd_soc_dai *codec_dai, if ((freq >= CS42L52_MIN_CLK) && (freq <= CS42L52_MAX_CLK)) { cs42l52->sysclk = freq; } else { - dev_err(codec->dev, "Invalid freq paramter\n"); + dev_err(codec->dev, "Invalid freq parameter\n"); return -EINVAL; } return 0; diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 11982bf..88dbabc 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -3734,7 +3734,7 @@ static irqreturn_t wm8958_mic_irq(int irq, void *data) } while (count--); if (count == 0) - dev_warn(codec->dev, "No impedence range reported for jack\n"); + dev_warn(codec->dev, "No impedance range reported for jack\n"); #ifndef CONFIG_SND_SOC_WM8994_MODULE trace_snd_soc_jack_irq(dev_name(codec->dev)); -- 1.8.0.rc3.16.g8ead1bf

2 1

[alsa-devel] [PATCH] stop setup_dig_out_stream() causing clicks
by Laurence Darby 04 Nov '12

04 Nov '12

Starting audio or seeking in various music players causes setup_dig_out_stream() to be called, which resets the SPDIF stream, which caused one DAC (but not another) to make a clicking noise every time. This patch turns off codec->spdif_status_reset after one reset which stops further clicks. One reset is still necessary to initialise the codec properly. Signed-off-by: Laurence Darby <ldarby(a)tuffmail.com> --- 2nd attempt at this, I hope I'm not doing anything wrong this time. sound/pci/hda/hda_codec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 1c65cc5..7742a77 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -4731,9 +4731,11 @@ static void setup_dig_out_stream(struct hda_codec *codec, hda_nid_t nid, format); } /* turn on again (if needed) */ - if (codec->spdif_status_reset && (spdif->ctls & AC_DIG1_ENABLE)) + if (codec->spdif_status_reset && (spdif->ctls & AC_DIG1_ENABLE)) { set_dig_out_convert(codec, nid, spdif->ctls & 0xff, -1); + codec->spdif_status_reset = 0; + } } static void cleanup_dig_out_stream(struct hda_codec *codec, hda_nid_t nid) -- 1.7.12

2 5