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

[PATCH v2 01/16] ASoC: eureka-tlv320: Update to modern clocking terminology
by Mark Brown 22 Sep '21

22 Sep '21

As part of moving to remove the old style defines for the bus clocks update the eureka-tlv320 driver to use more modern terminology for clocking. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/fsl/eukrea-tlv320.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/eukrea-tlv320.c b/sound/soc/fsl/eukrea-tlv320.c index e13271ea84de..8b61582753c8 100644 --- a/sound/soc/fsl/eukrea-tlv320.c +++ b/sound/soc/fsl/eukrea-tlv320.c @@ -70,7 +70,7 @@ static struct snd_soc_dai_link eukrea_tlv320_dai = { .name = "tlv320aic23", .stream_name = "TLV320AIC23", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | - SND_SOC_DAIFMT_CBM_CFM, + SND_SOC_DAIFMT_CBP_CFP, .ops = &eukrea_tlv320_snd_ops, SND_SOC_DAILINK_REG(hifi), }; -- 2.20.1

2 17

Redesign the rawmidi midi read with timestamping API
by GitHub pull_request - opened 22 Sep '21

22 Sep '21

alsa-project/alsa-lib pull request #179 was opened from perexg: It's follow-up for https://github.com/alsa-project/alsa-lib/pull/173 and https://github.com/alsa-project/alsa-lib/issues/172 . I am confident, that the direct framing mechanism for the transfer of the midi stream with the timestamping should be hidden and abstracted in the alsa-lib's API. This version uses a new read function (`snd_rawmidi_tread()`) which decodes and merges the data from the kernel frames. The framing mechanism is very specific to the kernel API and the cost of added data copy is negligible in this case (the kernel code basically does similar thing). I kept the `snd_rawmidi_read()` functionality to read raw frames), but the structure for the parsing must be defined on it's own. This mechanism is unsupported. This version seems more abstract and easy to use for apps than the separate decoder function for `snd_rawmidi_read()`. Request URL : https://github.com/alsa-project/alsa-lib/pull/179 Patch URL : https://github.com/alsa-project/alsa-lib/pull/179.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[RFC PATCH] component: do not leave master devres group open after bind
by Kai Vehmanen 22 Sep '21

22 Sep '21

In current code, the devres group for aggregate master is left open after call to component_master_add_*(). This leads to problems when the master does further managed allocations on its own. When any participating driver calls component_del(), this leads to immediate release of resources. This came up when investigating a page fault occurring with i915 DRM driver unbind with 5.15-rc1 kernel. The following sequence occurs: i915_pci_remove() -> intel_display_driver_unregister() -> i915_audio_component_cleanup() -> component_del() -> component.c:take_down_master() -> hdac_component_master_unbind() [via master->ops->unbind()] -> devres_release_group(master->parent, NULL) With older kernels this has not caused issues, but with audio driver moving to use managed interfaces for more of its allocations, this no longer works. Devres log shows following to occur: component_master_add_with_match() [ 126.886032] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000323ccdc5 devm_component_match_release (24 bytes) [ 126.886045] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000865cdb29 grp< (0 bytes) [ 126.886049] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 grp< (0 bytes) audio driver completes its PCI probe() [ 126.892238] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 pcim_iomap_release (48 bytes) component_del() called() at DRM/i915 unbind() [ 137.579422] i915 0000:00:02.0: DEVRES REL 00000000ef44c293 grp< (0 bytes) [ 137.579445] snd_hda_intel 0000:00:1f.3: DEVRES REL 00000000865cdb29 grp< (0 bytes) [ 137.579458] snd_hda_intel 0000:00:1f.3: DEVRES REL 000000001b480725 pcim_iomap_release (48 bytes) So the "devres_release_group(master->parent, NULL)" ends up freeing the pcim_iomap allocation. Upon next runtime resume, the audio driver will cause a page fault as the iomap alloc was released without the driver knowing about it. Fix this issue by using the "struct master" pointer as identifier for the devres group, and by closing the devres group after the master->ops->bind() call is done. This allows devres allocations done by the driver acting as master to be isolated from the binding state of the aggregate driver. This modifies the logic originally introduced in commit 9e1ccb4a7700 ("drivers/base: fix devres handling for master device"). BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/4136 Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- drivers/base/component.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Hi, I'm sending this as RFC as I'm not sure of the implications of not leaving the devres group open might have to other users of the component framework. For audio, the current behaviour seems very problematic. The display codec is usually just one of many audio codecs attached to the controller, and unbind of the display codec (and the aggregate driver created with DRM), should not bring down the whole audio card. However, now all allocations audio driver does after call to component_master_add_with_match(), will be freed when display driver calls component_del(). Closing the devres group at end of component_master_add_*() would seem the cleanest option. Looking for feedback whether this approach is feasible. One alternative would be for the audio driver to close the "last opened" group after its call to component_master_add(), but this seems messy (audio would make assumptions on component.c internals). diff --git a/drivers/base/component.c b/drivers/base/component.c index 5e79299f6c3f..870485cbbb87 100644 --- a/drivers/base/component.c +++ b/drivers/base/component.c @@ -246,7 +246,7 @@ static int try_to_bring_up_master(struct master *master, return 0; } - if (!devres_open_group(master->parent, NULL, GFP_KERNEL)) + if (!devres_open_group(master->parent, master, GFP_KERNEL)) return -ENOMEM; /* Found all components */ @@ -258,6 +258,7 @@ static int try_to_bring_up_master(struct master *master, return ret; } + devres_close_group(master->parent, NULL); master->bound = true; return 1; } @@ -282,7 +283,7 @@ static void take_down_master(struct master *master) { if (master->bound) { master->ops->unbind(master->parent); - devres_release_group(master->parent, NULL); + devres_release_group(master->parent, master); master->bound = false; } } base-commit: 930e99a51fcc8b1254e0a45fbe0cd5a5b8a704a5 -- 2.32.0

3 2

Re: [LAD] Mackie Onyx 1640i: Long run playback results in xrun and hang.
by AreYouLoco? 21 Sep '21

21 Sep '21

I am going to recompile the kernel with options mentioned here: https://www.alsa-project.org/main/index.php/XRUN_Debug And try to debug why the xrun appears. I also checked with buffer size 1024 and exaclty one xrun and then hang repeats. On 9/13/21 12:23 PM, AreYouLoco? wrote: > Hi, > > I am using custom build real-time kernel 5.12.2-rt3-fw. JACK with ALSA > backend on Mackie Onyx 1640i. > Lenovo Thinkpad T420 with FireWire. Debian Bullseye (11.0 - stable) > JACKD version 1.9.17. > I am using 512 samples 3 periods @48kHz. > > The problem is that long run playback only around 1h (but the time > differs), result in > XRUN detected by JACK logs and the whole audio stops. So I have to > restart JACK in order to make it work. > DMESG is silent about that issue. But sometimes I get: > > snd_oxfw fw1.0: Detect discontinuity of CIP: E8 00 > And different hex values there. > > Here is interesting part from the log: > > Sun Sep 12 22:10:12 2021: Jack: JackRequest::Notification > Sun Sep 12 22:10:12 2021: Jack: **** alsa_pcm: xrun of at least 0.027 msecs > Sun Sep 12 22:10:12 2021: Jack: Repreparing capture > Sun Sep 12 22:10:12 2021: Jack: Repreparing playback > Sun Sep 12 22:10:12 2021: Jack: ALSA XRun wait_status = 0 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackClient::ClientNotify ref = 2 name = > dbusapi notify = 3 > Sun Sep 12 22:10:12 2021: Jack: JackClient::kXRunCallback > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:28 2021: ERROR: ALSA: poll time out, polled for > 15998655 usecs, Retrying with a recovery, retry cnt = 1 > Sun Sep 12 22:10:44 2021: ERROR: ALSA: poll time out, polled for > 15998654 usecs, Retrying with a recovery, retry cnt = 2 > Sun Sep 12 22:11:00 2021: ERROR: ALSA: poll time out, polled for > 15998659 usecs, Retrying with a recovery, retry cnt = 3 > Sun Sep 12 22:11:16 2021: ERROR: ALSA: poll time out, polled for > 15998649 usecs, Retrying with a recovery, retry cnt = 4 > > Anyone have idea what might be the cause of this XRUN? Or how to debug that? > > Its reproducible on my setup. Another log catched the same issue: > > Sun Sep 12 16:50:44 2021: Jack: **** alsa_pcm: xrun of at least 0.030 msecs > Sun Sep 12 16:50:44 2021: Jack: Repreparing capture > Sun Sep 12 16:50:44 2021: Jack: Repreparing playback > Sun Sep 12 16:50:44 2021: Jack: ALSA XRun wait_status = 0 > Sun Sep 12 16:50:44 2021: Jack: JackRequest::Notification > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackClient::ClientNotify ref = 2 name = > dbusapi notify = 3 > Sun Sep 12 16:50:44 2021: Jack: JackClient::kXRunCallback > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:51:00 2021: ERROR: ALSA: poll time out, polled for > 15998366 usecs, Retrying with a recovery, retry cnt = 1 > Sun Sep 12 16:51:16 2021: ERROR: ALSA: poll time out, polled for > 15998353 usecs, Retrying with a recovery, retry cnt = 2 > Sun Sep 12 16:51:32 2021: ERROR: ALSA: poll time out, polled for > 15998352 usecs, Retrying with a recovery, retry cnt = 3 > Sun Sep 12 16:51:48 2021: ERROR: ALSA: poll time out, polled for > 15998367 usecs, Retrying with a recovery, retry cnt = 4 > Sun Sep 12 16:52:04 2021: ERROR: ALSA: poll time out, polled for > 15998353 usecs, Retrying with a recovery, retry cnt = 5 > Sun Sep 12 16:52:20 2021: ERROR: ALSA: poll time out, polled for > 15998371 usecs, Reached max retry cnt = 5, Exiting > Sun Sep 12 16:52:20 2021: ERROR: JackAudioDriver::ProcessAsync: read > error, stopping... > Sun Sep 12 16:52:20 2021: Jack: JackPosixThread::ThreadHandler : exit > > I am willing to provide additional info. > > Thank you in advance, > > AreYouLoco? > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev

1 1

[PATCH] ASoC: Fix warning related to 'sound-name-prefix' binding
by Sameer Pujar 21 Sep '21

21 Sep '21

commit 82d3ec1d89fa ("ASoC: Use schema reference for sound-name-prefix") added name-prefix.yaml schema and the same reference was used in couple of other schemas. But this is causing following warning and the same is fixed in current patch. Documentation/devicetree/bindings/sound/nxp,tfa989x.example.dt.yaml: audio-codec@34: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml Documentation/devicetree/bindings/sound/nxp,tfa989x.example.dt.yaml: audio-codec@36: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml Fixes: 82d3ec1d89fa ("ASoC: Use schema reference for sound-name-prefix") Reported-by: Rob Herring <robh+dt(a)kernel.org> Suggested-by: Rob Herring <robh+dt(a)kernel.org> Signed-off-by: Sameer Pujar <spujar(a)nvidia.com> --- Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml | 2 ++ Documentation/devicetree/bindings/sound/simple-audio-mux.yaml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml index 68e5ad2..7667471 100644 --- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -24,6 +24,8 @@ properties: '#sound-dai-cells': const: 0 + sound-name-prefix: true + vddd-supply: description: regulator phandle for the VDDD power supply. diff --git a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml index c597d9d..b5fc35e 100644 --- a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml +++ b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml @@ -24,6 +24,8 @@ properties: description: | GPIOs used to select the input line. + sound-name-prefix: true + required: - compatible - mux-gpios -- 2.7.4

2 1

[PATCH] ASoC: pcm512x: Mend accesses to the I2S_1 and I2S_2 registers
by Peter Rosin 21 Sep '21

21 Sep '21

>From 625f858894af2b7e547cc723b97361081438b123 Mon Sep 17 00:00:00 2001 From: Peter Rosin <peda(a)axentia.se> Commit 25d27c4f68d2 ("ASoC: pcm512x: Add support for more data formats") breaks the TSE-850 device, which is using a pcm5142 in I2S and CBM_CFS mode (maybe not relevant). Without this fix, the result is: pcm512x 0-004c: Failed to set data format: -16 And after that, no sound. This fix is not 100% correct. The datasheet of at least the pcm5142 states that four bits (0xcc) in the I2S_1 register are "RSV" ("Reserved. Do not access.") and no hint is given as to what the initial values are supposed to be. So, specifying defaults for these bits is wrong. But perhaps better than a broken driver? Fixes: 25d27c4f68d2 ("ASoC: pcm512x: Add support for more data formats") Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Kirill Marinushkin <kmarinushkin(a)birdec.com> Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Cc: alsa-devel(a)alsa-project.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Peter Rosin <peda(a)axentia.se> --- sound/soc/codecs/pcm512x.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c index 4dc844f3c1fc..60dee41816dc 100644 --- a/sound/soc/codecs/pcm512x.c +++ b/sound/soc/codecs/pcm512x.c @@ -116,6 +116,8 @@ static const struct reg_default pcm512x_reg_defaults[] = { { PCM512x_FS_SPEED_MODE, 0x00 }, { PCM512x_IDAC_1, 0x01 }, { PCM512x_IDAC_2, 0x00 }, + { PCM512x_I2S_1, 0x02 }, + { PCM512x_I2S_2, 0x00 }, }; static bool pcm512x_readable(struct device *dev, unsigned int reg) -- 2.20.1

3 13

[PATCH 0/7] add internal channels support
by Olivier Moysan 21 Sep '21

21 Sep '21

This patchset adds support of ADC2 internal channels VDDCORE, VREFINT and VBAT on STM32MP15x SoCs. The generic IIO channel bindings is also introduced here to provide this feature. The legacy channel binding is kept for backward compatibility. Olivier Moysan (7): dt-bindings: iio: adc: add generic channel binding dt-bindings: iio: adc: add nvmem support for vrefint internal channel iio: adc stm32-adc: split channel init into several routines iio: adc: stm32-adc: add support of generic channels binding iio: adc: stm32-adc: add support of internal channels iio: adc: stm32-adc: add vrefint calibration support iio: adc: stm32-adc: use generic binding for sample-time .../bindings/iio/adc/st,stm32-adc.yaml | 108 ++++- drivers/iio/adc/stm32-adc-core.h | 8 + drivers/iio/adc/stm32-adc.c | 418 ++++++++++++++++-- 3 files changed, 482 insertions(+), 52 deletions(-) -- 2.17.1

3 14

[PATCH] ALSA: firewire-motu: fix truncated bytes in message tracepoints
by Takashi Sakamoto 21 Sep '21

21 Sep '21

In MOTU protocol v2/v3, first two data chunks across 2nd and 3rd data channels includes message bytes from device. The total size of message is 48 bits per data block. The 'data_block_message' tracepoints event produced by ALSA firewire-motu driver exposes the sequence of messages to userspace in 64 bit storage, however lower 32 bits are actually available since current implementation truncates 16 bits in upper of the message as a result of bit shift operation within 32 bit storage. This commit fixes the bug by perform the bit shift in 64 bit storage. Fixes: c6b0b9e65f09 ("ALSA: firewire-motu: add tracepoints for messages for unique protocol") Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/motu/amdtp-motu.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/firewire/motu/amdtp-motu.c b/sound/firewire/motu/amdtp-motu.c index 5388b85fb60e..a18c2c033e83 100644 --- a/sound/firewire/motu/amdtp-motu.c +++ b/sound/firewire/motu/amdtp-motu.c @@ -276,10 +276,11 @@ static void __maybe_unused copy_message(u64 *frames, __be32 *buffer, /* This is just for v2/v3 protocol. */ for (i = 0; i < data_blocks; ++i) { - *frames = (be32_to_cpu(buffer[1]) << 16) | - (be32_to_cpu(buffer[2]) >> 16); + *frames = be32_to_cpu(buffer[1]); + *frames <<= 16; + *frames |= be32_to_cpu(buffer[2]) >> 16; + ++frames; buffer += data_block_quadlets; - frames++; } } -- 2.30.2

2 1

[GIT PULL] ASoC fixes for v5.15-rc2
by Mark Brown 21 Sep '21

21 Sep '21

The following changes since commit fcb958ee8e832e9cdf43408535207e15f14af755: ASoC: rockchip: i2s: Fix concurrency between tx/rx (2021-09-03 16:19:01 +0100) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-fix-v5.15-rc2 for you to fetch changes up to cfacfefd382af3b42905108b54f02820dca225c4: ASoC: SOF: trace: Omit error print when waking up trace sleepers (2021-09-17 13:16:36 +0100) ---------------------------------------------------------------- ASoC: Fixes for v5.15 A crop of mostly device specific fixes that have been applied since the merge window, nothing particularly standout here. ---------------------------------------------------------------- Arnaud Pouliquen (1): MAINTAINERS: fix update references to stm32 audio bindings Marc Herbert (1): ASoC: SOF: loader: release_firmware() on load failure to avoid batching Mark Brown (1): Merge series "ASoC: fsl: register platform component before registering cpu dai" from Shengjiu Wang <shengjiu.wang(a)nxp.com>: Peter Ujfalusi (4): ASoC: SOF: imx: imx8: Bar index is only valid for IRAM and SRAM types ASoC: SOF: imx: imx8m: Bar index is only valid for IRAM and SRAM types ASoC: SOF: loader: Re-phrase the missing firmware error to avoid duplication ASoC: SOF: trace: Omit error print when waking up trace sleepers Pierre-Louis Bossart (1): ASoC: Intel: sof_sdw: tag SoundWire BEs as non-atomic Shengjiu Wang (5): ASoC: fsl_sai: register platform component before registering cpu dai ASoC: fsl_esai: register platform component before registering cpu dai ASoC: fsl_micfil: register platform component before registering cpu dai ASoC: fsl_spdif: register platform component before registering cpu dai ASoC: fsl_xcvr: register platform component before registering cpu dai Trevor Wu (3): ASoC: mediatek: add required config dependency ASoC: mediatek: common: handle NULL case in suspend/resume function ASoC: mediatek: mt8195: remove wrong fixup assignment on HDMITX Yong Zhi (1): ASoC: SOF: Fix DSP oops stack dump output contents MAINTAINERS | 3 ++- sound/soc/fsl/fsl_esai.c | 16 ++++++++++------ sound/soc/fsl/fsl_micfil.c | 15 ++++++++++----- sound/soc/fsl/fsl_sai.c | 14 +++++++++----- sound/soc/fsl/fsl_spdif.c | 14 +++++++++----- sound/soc/fsl/fsl_xcvr.c | 15 ++++++++++----- sound/soc/intel/boards/sof_sdw.c | 5 +++++ sound/soc/mediatek/Kconfig | 3 +++ sound/soc/mediatek/common/mtk-afe-fe-dai.c | 19 +++++++++++-------- .../soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c | 7 +++---- sound/soc/sof/core.c | 4 +--- sound/soc/sof/imx/imx8.c | 9 ++++++++- sound/soc/sof/imx/imx8m.c | 9 ++++++++- sound/soc/sof/loader.c | 8 +++++--- sound/soc/sof/trace.c | 1 - sound/soc/sof/xtensa/core.c | 4 ++-- 16 files changed, 96 insertions(+), 50 deletions(-)

2 1

Re: [PATCH] ALSA: usx2y: Prefer struct_size over open coded arithmetic
by Takashi Iwai 21 Sep '21

21 Sep '21

On Sun, 19 Sep 2021 15:37:27 +0200, Len Baker wrote: > > As noted in the "Deprecated Interfaces, Language Features, Attributes, > and Conventions" documentation [1], size calculations (especially > multiplication) should not be performed in memory allocator (or similar) > function arguments due to the risk of them overflowing. This could lead > to values wrapping around and a smaller allocation being made than the > caller was expecting. Using those allocations could lead to linear > overflows of heap memory and other misbehaviors. > > In this case this is not actually dynamic size: all the operands > involved in the calculation are constant values. However it is better to > refactor this anyway, just to keep the open-coded math idiom out of > code. > > So, use the struct_size() helper to do the arithmetic instead of the > argument "size + size * count" in the kzalloc() function. > > Also, take the opportunity to refactor the declaration variables to make > it more easy to read. > > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-a… > > Signed-off-by: Len Baker <len.baker(a)gmx.com> Thanks, applied. Takashi

1 0