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

[alsa-devel] HDMI regression on close (was: ALSA: hda - Always turn on pins for HDMI/DP)
by Anssi Hannula 18 Feb '13

18 Feb '13

Hi! > From: Takashi Iwai <tiwai(a)suse.de> > Date: Fri, 14 Dec 2012 09:22:35 +0000 (+0100) > Subject: ALSA: hda - Always turn on pins for HDMI/DP > X-Git-Tag: v3.8-rc1~29^2~7 > X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-stable.git;a… > > ALSA: hda - Always turn on pins for HDMI/DP > > We've seen the broken HDMI *video* output on some machines with GM965, > and the debugging session pointed that the culprit is the disabled > audio output pins. Toggling these pins dynamically on demand caused > flickering of HDMI TV. > > This patch changes the behavior to keep the pin ON constantly. Unfortunately this seems to cause a regression on at least some "NVIDIA ION2" systems. When running snd_pcm_open() and snd_pcm_close() on an hdmi device on an affected system, the HDMI port seemingly continues to transmit an empty audio stream. However, when hw_params have been set and snd_pcm_prepare() called before closing the device (and optionally audio has been output), the HDMI port stops transmitting at snd_pcm_close() time. (I use "transmitting" here to mean that the HDMI sink/receiver receives/shows a an active audio stream) On systems _not_ affected by the issue, the HDMI port never starts transmitting if just snd_pcm_open()+snd_pcm_close() have been called (but note [1]). HDMI port continuing transmitting has the unfortunate effect that when the user has connected the system to an amplifier via HDMI (for video playback purposes), the amplifier may continue to play back empty audio from HDMI even when there is actual audio data on its S/PDIF input. An snd_pcm_open()+snd_pcm_close() sequence can be caused by e.g. device probing by an application. Several OpenELEC users have reported this issue on stable 3.7.x, here's some alsainfo: http://onse.fi/files/ion-regression-alsainfo-1.txt http://onse.fi/files/ion-regression-alsainfo-2.txt Both of these have the Nvidia GPU 0b HDMI/DP codecs: Vendor Id: 0x10de000b Subsystem Id: 0x10de0101 Revision Id: 0x100200 However, e.g. my non-ION2 laptop with 0b codecs (but different rev) is _not_ affected: Vendor Id: 0x10de000b Subsystem Id: 0x10de0101 Revision Id: 0x100100 http://www.alsa-project.org/db/?f=bc940d23d19ae7e2ee1e83895d85f711c2d0e5b1 I'm still working with the OpenELEC devs and users to pinpoint the issue further, but it is progressing rather slowly due to not many people having affected systems (especially in the affected dual HDMI + S/PDIF cabled configuration). Feel free to suggest anything we should try out if you have some ideas :) In the meantime, I'll continue investigating exactly why snd_pcm_close() doesn't stop the HDMI output on the affected systems (or why does a simple snd_pcm_open() even start outputting the audio, since that does not seem to happen on other systems). I'll keep you posted. [1] It seems that on my Intel HDMI system ( http://www.alsa-project.org/db/?f=bb3fc8680b372c0475719d42d7fc8b2bb7bfb4eb ) the HDMI port keeps transmitting in approximately reversed situation than in the above ION2 case. That is, if audio has been output in the port e.g. with a speaker-test command, closing the device will not cause the stream to stop (and therefore the above issue happens again, receives ignores S/PDIF stream as HDMI stream is given higher priority by default). I found out that the attached patch solves that one. What are your thoughts on that? (obviously the patch will not solve the ION2 regression, since cleanup() is not called if prepare() has not been called; or at least I assume so, way too tired to check that now...) Note that closing the device after audio has been output stops HDMI port transmission even without the patch on both the NVIDIA ION2 systems and on my NVIDIA laptop, it is just the Intel HDMI codec where that does not happen (well, of the tested ones, at least). > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51421 > > Cc: <stable(a)vger.kernel.org> > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > --- > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > index 0fcfa6f..37dd06d 100644 > --- a/sound/pci/hda/patch_hdmi.c > +++ b/sound/pci/hda/patch_hdmi.c > @@ -431,9 +431,11 @@ static void hdmi_init_pin(struct hda_codec *codec, hda_nid_t pin_nid) > if (get_wcaps(codec, pin_nid) & AC_WCAP_OUT_AMP) > snd_hda_codec_write(codec, pin_nid, 0, > AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE); > - /* Disable pin out until stream is active*/ > + /* Enable pin out: some machines with GM965 gets broken output when > + * the pin is disabled or changed while using with HDMI > + */ > snd_hda_codec_write(codec, pin_nid, 0, > - AC_VERB_SET_PIN_WIDGET_CONTROL, 0); > + AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT); > } > > static int hdmi_get_channel_count(struct hda_codec *codec, hda_nid_t cvt_nid) > @@ -1341,7 +1343,6 @@ static int generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo, > struct hdmi_spec *spec = codec->spec; > int pin_idx = hinfo_to_pin_index(spec, hinfo); > hda_nid_t pin_nid = spec->pins[pin_idx].pin_nid; > - int pinctl; > bool non_pcm; > > non_pcm = check_non_pcm_per_cvt(codec, cvt_nid); > @@ -1350,11 +1351,6 @@ static int generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo, > > hdmi_setup_audio_infoframe(codec, pin_idx, non_pcm, substream); > > - pinctl = snd_hda_codec_read(codec, pin_nid, 0, > - AC_VERB_GET_PIN_WIDGET_CONTROL, 0); > - snd_hda_codec_write(codec, pin_nid, 0, > - AC_VERB_SET_PIN_WIDGET_CONTROL, pinctl | PIN_OUT); > - > return hdmi_setup_stream(codec, cvt_nid, pin_nid, stream_tag, format); > } > > @@ -1374,7 +1370,6 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo, > int cvt_idx, pin_idx; > struct hdmi_spec_per_cvt *per_cvt; > struct hdmi_spec_per_pin *per_pin; > - int pinctl; > > if (hinfo->nid) { > cvt_idx = cvt_nid_to_cvt_index(spec, hinfo->nid); > @@ -1391,11 +1386,6 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo, > return -EINVAL; > per_pin = &spec->pins[pin_idx]; > > - pinctl = snd_hda_codec_read(codec, per_pin->pin_nid, 0, > - AC_VERB_GET_PIN_WIDGET_CONTROL, 0); > - snd_hda_codec_write(codec, per_pin->pin_nid, 0, > - AC_VERB_SET_PIN_WIDGET_CONTROL, > - pinctl & ~PIN_OUT); > snd_hda_spdif_ctls_unassign(codec, pin_idx); > per_pin->chmap_set = false; > memset(per_pin->chmap, 0, sizeof(per_pin->chmap)); -- Anssi Hannula

2 8

Re: [alsa-devel] [PATCH V2] ARM: dts: omap3-devkit8000: Enable audio support
by Peter Ujfalusi 18 Feb '13

18 Feb '13

On 02/16/2013 08:33 AM, Anil Kumar wrote: > Add the needed sections to enable audio support on > Devkit8000 when booted with DT blob. > > Signed-off-by: Anil Kumar <anilk4.v(a)gmail.com> Looks good: Acked-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> > --- > This patch is based on top of kernel 3.8-rc5 and > the following patches. > > Peter Ujfalusi:- > ASoC: twl4030: Correct the support for Voice port > ASoC: twl4030: Convert MICBIAS to SUPPLY widget > ASoC: omap-twl4030: Add support for routing, voice port and jack detect > > Anil Kumar:- > ARM: dts: add minimal DT support for DevKit8000 > https://patchwork.kernel.org/patch/2122461/ > > -Tested for playback and capture on Devkit8000. > > Test process:- > > #amixer set 'PredriveR Mixer AudioR2' on > #amixer set 'PredriveL Mixer AudioL2' on > #amixer set PreDriv 100 unmute > #amixer set 'DAC2 Digital Fine' 100 > #amixer cset numid=27 1 > #arecord | aplay > > For V2: > - Remove pin mux as done at device boot time by default. > > :100644 100644 6338993... c70116f... M arch/arm/boot/dts/omap3-devkit8000.dts > arch/arm/boot/dts/omap3-devkit8000.dts | 23 +++++++++++++++++++---- > 1 files changed, 19 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts > index 6338993..c70116f 100644 > --- a/arch/arm/boot/dts/omap3-devkit8000.dts > +++ b/arch/arm/boot/dts/omap3-devkit8000.dts > @@ -42,6 +42,19 @@ > }; > > }; > + > + sound { > + compatible = "ti,omap-twl4030"; > + ti,model = "devkit8000"; > + > + ti,mcbsp = <&mcbsp2>; > + ti,codec = <&twl_audio>; > + ti,audio-routing = > + "Ext Spk", "PREDRIVEL", > + "Ext Spk", "PREDRIVER", > + "MAINMIC", "Main Mic", > + "Main Mic", "Mic Bias 1"; > + }; > }; > > &i2c1 { > @@ -51,6 +64,12 @@ > reg = <0x48>; > interrupts = <7>; /* SYS_NIRQ cascaded to intc */ > interrupt-parent = <&intc>; > + > + twl_audio: audio { > + compatible = "ti,twl4030-audio"; > + codec { > + }; > + }; > }; > }; > > @@ -86,10 +105,6 @@ > status = "disabled"; > }; > > -&mcbsp2 { > - status = "disabled"; > -}; > - > &mcbsp3 { > status = "disabled"; > }; > -- Péter

1 0

[alsa-devel] [PATCH] ALSA: hda - add quirks for mute LED on two HP machines
by David Henningsson 18 Feb '13

18 Feb '13

These two machines have no mute LED string in BIOS. BugLink: https://bugs.launchpad.net/bugs/1128934 Tested-by: Tammy Yang <tammy.yang(a)canonical.com> Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- Should be sent to stable too, but I guess the patch have to be rewritten to fit. sound/pci/hda/patch_realtek.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 48c9d10..e575685 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -2726,6 +2726,18 @@ static void alc269_fixup_hp_mute_led(struct hda_codec *codec, } } +static void alc269_fixup_hp_mute_led_mic1(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + if (action == HDA_FIXUP_ACT_PRE_PROBE) { + spec->mute_led_polarity = 0; + spec->mute_led_nid = 0x18; + spec->gen.vmaster_mute.hook = alc269_fixup_mic_mute_hook; + spec->gen.vmaster_mute_enum = 1; + } +} + static void alc269_fixup_hp_mute_led_mic2(struct hda_codec *codec, const struct hda_fixup *fix, int action) { @@ -2771,6 +2783,7 @@ enum { ALC269VB_FIXUP_AMIC, ALC269VB_FIXUP_DMIC, ALC269_FIXUP_HP_MUTE_LED, + ALC269_FIXUP_HP_MUTE_LED_MIC1, ALC269_FIXUP_HP_MUTE_LED_MIC2, ALC269_FIXUP_INV_DMIC, ALC269_FIXUP_LENOVO_DOCK, @@ -2903,6 +2916,10 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_hp_mute_led, }, + [ALC269_FIXUP_HP_MUTE_LED_MIC1] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc269_fixup_hp_mute_led_mic1, + }, [ALC269_FIXUP_HP_MUTE_LED_MIC2] = { .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_hp_mute_led_mic2, @@ -2947,6 +2964,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x029b, "Acer 1810TZ", ALC269_FIXUP_INV_DMIC), SND_PCI_QUIRK(0x1025, 0x0349, "Acer AOD260", ALC269_FIXUP_INV_DMIC), SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2), + SND_PCI_QUIRK(0x103c, 0x1973, "HP Pavilion", ALC269_FIXUP_HP_MUTE_LED_MIC1), + SND_PCI_QUIRK(0x103c, 0x1983, "HP Pavilion", ALC269_FIXUP_HP_MUTE_LED_MIC1), SND_PCI_QUIRK_VENDOR(0x103c, "HP", ALC269_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_DMIC), SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_DMIC), -- 1.7.9.5

2 1

[alsa-devel] [PATCH] ALSA: hda - Remove speaker clicks on CX20549
by David Henningsson 18 Feb '13

18 Feb '13

This chip needs the speaker pin to go to D3 to avoid clicks, so default_power_filter does not work here. This was found on Thinkpad R61i/T61i but I guess it applies to the entire chip. If not, quirks should be set for at least PCI SSID 17aa:20ac. Thanks to c4pp4 for testing. BugLink: https://bugs.launchpad.net/bugs/886975 Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_conexant.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 7d941ef..941bf6c 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -3350,6 +3350,7 @@ static int patch_conexant_auto(struct hda_codec *codec) switch (codec->vendor_id) { case 0x14f15045: codec->single_adc_amp = 1; + codec->power_filter = NULL; /* Needs speaker amp to D3 to avoid click */ break; case 0x14f15047: codec->pin_amp_workaround = 1; -- 1.7.9.5

2 5

Re: [alsa-devel] 3.7 HDMI channel map regression
by Takashi Iwai 17 Feb '13

17 Feb '13

At Sat, 16 Feb 2013 18:22:25 -0600, Shawn Bohrer wrote: > > On Mon, Jan 28, 2013 at 08:52:05PM -0600, Shawn Bohrer wrote: > > On Mon, Jan 28, 2013 at 09:56:33AM +0100, Takashi Iwai wrote: > > > At Sun, 27 Jan 2013 19:18:27 -0600, > > > Shawn Bohrer wrote: > > > > > > > > Hi Takashi, > > > > > > > > I recently updated my HTPC from 3.6.11 to 3.7.2 and this caused my RL > > > > and FC channels to swap, and my RR and LFE channels to swap for PCM > > > > audio. Doing a git bisect identified > > > > d45e6889ee69456a4d5b1bbb32252f460cd48fa9 "ALSA: hda - Provide the > > > > proper channel mapping for generic HDMI driver" as the commit that > > > > caused my channels to swap. The commit doesn't revert cleanly on > > > > 3.7.4, and I haven't really looked to see what the correct fix might > > > > be. > > > > > > > > Some info that may be relevant, the sound card is a: > > > > > > > > 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset > > > > Family High Definition Audio Controller (rev 04) > > > > > > > > The machine is running Fedora 18 and audio goes over HDMI to a 5.1 > > > > receiver. I'm not really sure what other info you might need, but > > > > let me know if you need something else or have any patches you would > > > > like me to test. > > > > > > OK, it's the first time to get a bug report about this. > > > Could you tell me how did you test it (i.e. which application, which > > > sound backend)? Can you confirm that it's reproduced via speaker-test > > > program in alsa-utils package? > > > > I originally noticed the problem when all of the dialog started coming > > out of my rear left speaker in MythTV after the kernel update. Then I > > started using the Gnome 3 sound configuration gui in the system > > settings which has a speaker test and I assume is using pulseaudio. > > Running 'speaker-test -c6 -l1 -twav' also reproduces the problem. > > > > For reference here are the versions of the various packages that I'm > > running: > > > > alsa-utils-1.0.26-1.fc18.x86_64 > > alsa-firmware-1.0.25-2.fc18.noarch > > alsa-plugins-pulseaudio-1.0.26-2.fc18.x86_64 > > alsa-lib-devel-1.0.26-2.fc18.x86_64 > > alsa-lib-1.0.26-2.fc18.x86_64 > > alsa-tools-firmware-1.0.26.1-1.fc18.x86_64 > > pulseaudio-gdm-hooks-2.1-5.fc18.x86_64 > > pulseaudio-libs-2.1-5.fc18.x86_64 > > pulseaudio-libs-glib2-2.1-5.fc18.x86_64 > > pulseaudio-module-x11-2.1-5.fc18.x86_64 > > pulseaudio-module-bluetooth-2.1-5.fc18.x86_64 > > pulseaudio-2.1-5.fc18.x86_64 > > pulseaudio-utils-2.1-5.fc18.x86_64 > > Hi Takashi, > > Any updates on this issue? I'd really like to see this issue fixed > and am happy to help in any way I can. Until this gets fixed I'm > stuck on a 3.6.* kernel. There is one fix in sound git tree regarding the HDMI channel map, but it's queued for 3.9 kernel (then backported to stable tree). Try sound.git tree or wait for a while until the upstream merge process above is done. Takashi

1 0

[alsa-devel] ASoC updates for v3.9
by Mark Brown 17 Feb '13

17 Feb '13

The following changes since commit 699ba4546cfe3f4eee73aff4f307bf16362f9232: Merge remote-tracking branch 'asoc/topic/wm8993' into asoc-next (2013-02-11 11:06:55 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.9-updates for you to fetch changes up to 54759313ececcbd07e43fad75e0683e39a1f2a25: Merge remote-tracking branch 'asoc/topic/da7213' into asoc-next (2013-02-14 17:28:00 +0000) ---------------------------------------------------------------- ASoC: Final updates for v3.9 A few more updates from the past week - a new driver from Dialog and some small fixes and tweaks. ---------------------------------------------------------------- Adam Thomson (1): ASoC: codecs: Add da7213 codec Fabio Estevam (1): ASoC: fsl: imx-audmux: Fix sparse warning Mark Brown (6): ASoC: wm8994: Fix variable double use ASoC: arizona: Automatically manage input mutes Merge remote-tracking branch 'asoc/topic/fsl' into asoc-next Merge remote-tracking branch 'asoc/topic/omap' into asoc-next Merge remote-tracking branch 'asoc/topic/wm8994' into asoc-next Merge remote-tracking branch 'asoc/topic/da7213' into asoc-next Sebastien Guiriec (1): ASoC: omap-mcpdm: Remove useless ressource get. include/sound/da7213.h | 52 ++ sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/arizona.c | 17 + sound/soc/codecs/da7213.c | 1599 +++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/da7213.h | 523 ++++++++++++++ sound/soc/codecs/wm5102.c | 13 - sound/soc/codecs/wm5110.c | 17 - sound/soc/codecs/wm8994.c | 10 +- sound/soc/fsl/imx-audmux.c | 2 +- sound/soc/omap/omap-mcpdm.c | 4 - 11 files changed, 2203 insertions(+), 40 deletions(-) create mode 100644 include/sound/da7213.h create mode 100644 sound/soc/codecs/da7213.c create mode 100644 sound/soc/codecs/da7213.h

2 1

Re: [alsa-devel] [PATCH V6 02/10] ASoC: SAMSUNG: Add DT support for i2s
by Mark Brown 17 Feb '13

17 Feb '13

On Thu, Feb 14, 2013 at 09:33:00PM +0100, Sylwester Nawrocki wrote: > My apologies for the late review. It's already sixth version of this patch > series... But I noticed it just now when applying it for Exynos4. The GPIO > part of the bindings is now incompatible with Exynos4 and the bindings will > need to be changed. Leaving the compatibility code in the I2S driver, when > we could have it done well right from the beginning. If I'm not mistaken > a file similar to arch/arm/boot/dts/exynos4x12-pinctrl.dtsi with at least > entries for the I2S devices is needed and an addition of related pinctrl > nodes in exynos5250.dtsi. But I guess this is not something that could be > fixed in the -rc period ? Yes, and incremental fix would be fine.

2 1

[alsa-devel] Takashi: please help (compiling alsa-driver)
by Jonas Petersen 15 Feb '13

15 Feb '13

Hi Takashi, I'm talking to you directly because this ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-unstable-snapshot.… is the only alsa-driver source that I'm able to compile so far. I can unpack this and simply run ./configure && make && make install. It works great. (I compile against the kernel-headers from ubuntu). I spent hours in trying to compile from several other sources. * The plain1.0.25 release (complains about missing symbols). * The snapshots fromhttp://www.alsa-project.org/snapshot/ (will complain about missing 'uapi' stuff) * Btw. where did the snapshots fromhttp://ftp.kernel.org/pub/linux/kernel/people/tiwai/alsa/ go (Advertised here:http://www.alsa-project.org/main/index.php/Download)? * Checked out alsa-driver from git. But no luck, tried many things. e.g.: Branch release, then autoconf, but not even ./configure succeeds. Id like to submit some patches and be able to work with the current state from git. How is that supposed to work? Btw. I often read that the alsa-kernel is needed to compile. But it is not neede with this above mentioned 'unstable-snapshot'. It will just compile against the ubuntu kernel-headers (Lubuntu 12.10). How do you generate these snapshots? Thanks and sorry if that's stupid questions.. Jonas

3 6

[alsa-devel] Allocating DMA buffer for non-PCM
by Adrian Knoth 15 Feb '13

15 Feb '13

Hi! Would you say that the following is the proper way to allocate a DMA buffer used to hold level data? struct hdspm { struct pci_dev *pci; /* and an pci info */ struct snd_dma_buffer dmaLevelBuffer; u32 *level_buffer; /* suitably aligned address */ [..] } /* allocate level buffer */ err = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(hdspm->pci), MADIFX_LEVEL_BUFFER_SIZE, &hdspm->dmaLevelBuffer); if (err < 0) { /* error */ [..] } hdspm->level_buffer = snd_sgbuf_get_ptr(&(hdspm->dmaLevelBuffer), 0); memset(hdspm->level_buffer, 0, MADIFX_LEVEL_BUFFER_SIZE); This used to work on my development machine (kernel 3.6.x), but now a kernel 3.2.0 user reports a NULL pointer dereference of hdspm->level_buffer, so apparently, snd_sgbuf_get_ptr() returned NULL for him. How could this possibly happen? Am I missing something? Better use SNDRV_DMA_TYPE_DEV instead? TIA

3 8

Re: [alsa-devel] [PATCH] ASoC: codecs: Add da7213 codec
by Mark Brown 14 Feb '13

14 Feb '13

On Thu, Feb 14, 2013 at 12:02:51PM +0000, Adam Thomson wrote: > This patch adds support for the Dialog DA7213 audio codec. Applied, thanks.

1 0