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

[alsa-devel] Steinberg MIDEX8 driver attempt
by Hedde Bosman 26 May '17

26 May '17

Dear Alsa developers, I've owned a MIDEX8 for some years now and wanted to do something with it in Linux , so I started some analysis and coding. The current result can be found at https://github.com/sgorpi/midex8 it looks a bit like the standard midi class driver, but it requires some periodic (i guess timer) messages on endpoint 0x82. Therefore, I've took quite some inspiration from the sound/usb/midi.c driver. In general, it seems to work now for simple cases, but I'm having a few issues, that might be due to my lack of knowledge on the USB subsystem, or something else. In the (simplified) libusb test in the above repository, I do not seem to have these issues. Issue 1: Not all (interrupt) urbs that are submitted will complete (within 25 ms at least). Wireshark doesn't show the packets being sent out, and the completeion handler never gets called for those urbs, but also no errors are given by usb_submit_urb. This happens mainly with the timer messages, and my current solution is to unlink the urbs that haven't completed within 25ms. However, I feel there is something going wrong there. If I do not send urbs on the midi-in endpoint, I do not see any missing urbs... Do I have to mutex anything for a shared urb queue or so? Issue 2: Sometimes after sending a few midi messages, an empty urb shows up in wireshark. However, in code, there's an if-statement that should allow only messages of length > 0 to be submitted (line 568, if (num_read > 0)). Might this have to do with issue 1? I intend to improve on the driver some more, but if you could give me any advice on the above issues that would be highly appreciated. With kind regards, Hedde

1 0

[alsa-devel] [PATCH 0/2] ALSA: pcm: add local header for module-local functions
by Takashi Sakamoto 26 May '17

26 May '17

Hi, This patchset is a supplement for merged patchset[1]. As I suggested[2], an added helper function is useful to some parts of PCM core module. Although it's better to replace existent code block with it, there's an issue to share it with several objects, because there is no header files for external symbols not exported to kernel space. This patchset adds a header file for the module-local symbols, then adds calls of the function in several parts of the module. [1] [alsa-devel] [PATCH 0/7] ALSA: Fix/improve PCM ack callback http://mailman.alsa-project.org/pipermail/alsa-devel/2017-May/120886.html [2] [alsa-devel] [PATCH 0/7] ALSA: Fix/improve PCM ack callback http://mailman.alsa-project.org/pipermail/alsa-devel/2017-May/120910.html Takashi Sakamoto (2): ALSA: pcm: add local header file for snd-pcm module ALSA: pcm: add arrangement for applying appl_ptr include/sound/pcm.h | 32 ----------------------------- sound/core/pcm.c | 2 ++ sound/core/pcm_lib.c | 14 +++++++------ sound/core/pcm_local.h | 54 +++++++++++++++++++++++++++++++++++++++++++++++++ sound/core/pcm_misc.c | 3 +++ sound/core/pcm_native.c | 13 +++++++----- 6 files changed, 75 insertions(+), 43 deletions(-) create mode 100644 sound/core/pcm_local.h -- 2.11.0

2 10

[alsa-devel] [PATCH] pcm: dmix: Workaround for binary incompatibility
by Takashi Iwai 26 May '17

26 May '17

The commit 1a9bd0f04481 ("pcm: direct: Fix for sync issue on xrun recover") introduced a new field "recoveries" in snd_pcm_direct_share_t. Unfortunately this caused two issues: - It changed the size of the struct which is used as the magic key - The struct size differs between 32bit and 64bit due to alignment The former brought the incompatibility with the older alsa-lib, e.g. when you run an app with an older alsa-lib via LD_PRELOAD, it doesn't work any longer. The latter is more serious, it disallows running 32bit apps dmix with 64bit together. As a workaround, put recoveries field to the unused field "s.xfer_align", so that the struct is in an old form. This is a one-time workaround, and we may need to reconsider more about a breakage in future... Reported-and-tested-by: Cheng Sun <chengsun9(a)gmail.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- src/pcm/pcm_direct.c | 8 ++++---- src/pcm/pcm_direct.h | 3 +-- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/src/pcm/pcm_direct.c b/src/pcm/pcm_direct.c index 89468d3537d0..43702601b0f2 100644 --- a/src/pcm/pcm_direct.c +++ b/src/pcm/pcm_direct.c @@ -615,7 +615,7 @@ int snd_pcm_direct_slave_recover(snd_pcm_direct_t *direct) } return ret; } - direct->shmptr->recoveries++; + direct->shmptr->s.recoveries++; semerr = snd_pcm_direct_semaphore_up(direct, DIRECT_IPC_SEM_CLIENT); if (semerr < 0) { @@ -631,11 +631,11 @@ int snd_pcm_direct_slave_recover(snd_pcm_direct_t *direct) */ int snd_pcm_direct_client_chk_xrun(snd_pcm_direct_t *direct, snd_pcm_t *pcm) { - if (direct->shmptr->recoveries != direct->recoveries) { + if (direct->shmptr->s.recoveries != direct->recoveries) { /* no matter how many xruns we missed - * so don't increment but just update to actual counter */ - direct->recoveries = direct->shmptr->recoveries; + direct->recoveries = direct->shmptr->s.recoveries; pcm->fast_ops->drop(pcm); /* trigger_tstamp update is missing in drop callbacks */ gettimestamp(&direct->trigger_tstamp, pcm->tstamp_type); @@ -1539,7 +1539,7 @@ int snd_pcm_direct_open_secondary_client(snd_pcm_t **spcmp, snd_pcm_direct_t *dm dmix->slave_buffer_size = spcm->buffer_size; dmix->slave_period_size = dmix->shmptr->s.period_size; dmix->slave_boundary = spcm->boundary; - dmix->recoveries = dmix->shmptr->recoveries; + dmix->recoveries = dmix->shmptr->s.recoveries; ret = snd_pcm_mmap(spcm); if (ret < 0) { diff --git a/src/pcm/pcm_direct.h b/src/pcm/pcm_direct.h index 24e85f096310..582f055a5451 100644 --- a/src/pcm/pcm_direct.h +++ b/src/pcm/pcm_direct.h @@ -66,7 +66,6 @@ typedef struct { char socket_name[256]; /* name of communication socket */ snd_pcm_type_t type; /* PCM type (currently only hw) */ int use_server; - unsigned int recoveries; /* no of executed recoveries on slave*/ struct { unsigned int format; snd_interval_t rate; @@ -95,7 +94,7 @@ typedef struct { unsigned int stop_threshold; unsigned int silence_threshold; unsigned int silence_size; - unsigned int xfer_align; /* not used */ + unsigned int recoveries; /* no of executed recoveries on slave*/ unsigned long long boundary; unsigned int info; unsigned int msbits; -- 2.13.0

1 0

[alsa-devel] [PATCH] ASoC: wm_adsp: Fix typo in algorithm list warning message
by Richard Fitzgerald 26 May '17

26 May '17

The list terminator is 0xbedead but the message warning if it wasn't found was showing that 0xbeadead was expected. Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm_adsp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c index 5aff83b..65c059b5 100644 --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -1888,7 +1888,7 @@ static void *wm_adsp_read_algs(struct wm_adsp *dsp, size_t n_algs, } if (be32_to_cpu(val) != 0xbedead) - adsp_warn(dsp, "Algorithm list end %x 0x%x != 0xbeadead\n", + adsp_warn(dsp, "Algorithm list end %x 0x%x != 0xbedead\n", pos + len, be32_to_cpu(val)); alg = kzalloc(len * 2, GFP_KERNEL | GFP_DMA); -- 1.9.1

2 1

[alsa-devel] [PATCH] ASoC: rsnd: fixup parent_clk_name of AUDIO_CLKOUTx
by Kuninori Morimoto 26 May '17

26 May '17

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> commit 25165f79adc7 ("ASoC: rsnd: enable clock-frequency for both 44.1kHz/48kHz") supported both 44.1kHz/48kHz for AUDIO_CLKOUTx, but it didn't care its parent clock name. This patch fixes it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/sh/rcar/adg.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/soc/sh/rcar/adg.c b/sound/soc/sh/rcar/adg.c index 36bece8..4a72fd7 100644 --- a/sound/soc/sh/rcar/adg.c +++ b/sound/soc/sh/rcar/adg.c @@ -510,7 +510,8 @@ static void rsnd_adg_get_clkout(struct rsnd_priv *priv, rbga = rbgx; adg->rbga_rate_for_441khz = rate / div; ckr |= brg_table[i] << 20; - if (req_441kHz_rate) + if (req_441kHz_rate && + !(adg_mode_flags(adg) & AUDIO_OUT_48)) parent_clk_name = __clk_get_name(clk); } } @@ -525,7 +526,8 @@ static void rsnd_adg_get_clkout(struct rsnd_priv *priv, rbgb = rbgx; adg->rbgb_rate_for_48khz = rate / div; ckr |= brg_table[i] << 16; - if (req_48kHz_rate) + if (req_48kHz_rate && + (adg_mode_flags(adg) & AUDIO_OUT_48)) parent_clk_name = __clk_get_name(clk); } } -- 1.9.1

2 1

[alsa-devel] [PATCH] ASoC: simple-card-utils: remove strict limitation of bit/frame master
by Kuninori Morimoto 26 May '17

26 May '17

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Current asoc_simple_card_parse_daifmt is keeping backward compatibility for bitmaster/framemaster which didn't use phandle. The keep compatibility, it is checking prefix length, but it is too strict. let's loosen it. Otherwise, OF-graph base sound card which doesn't have prefix can't detect daifmt. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/generic/simple-card-utils.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c index b5047e2..f5a3e32 100644 --- a/sound/soc/generic/simple-card-utils.c +++ b/sound/soc/generic/simple-card-utils.c @@ -21,14 +21,13 @@ int asoc_simple_card_parse_daifmt(struct device *dev, { struct device_node *bitclkmaster = NULL; struct device_node *framemaster = NULL; - int prefix_len = prefix ? strlen(prefix) : 0; unsigned int daifmt; daifmt = snd_soc_of_parse_daifmt(node, prefix, &bitclkmaster, &framemaster); daifmt &= ~SND_SOC_DAIFMT_MASTER_MASK; - if (prefix_len && !bitclkmaster && !framemaster) { + if (!bitclkmaster && !framemaster) { /* * No dai-link level and master setting was not found from * sound node level, revert back to legacy DT parsing and -- 1.9.1

2 1

[alsa-devel] 1.1.3 bug report: dmix reports inconsistent status
by Cheng Sun 26 May '17

26 May '17

Hi all, The following commit (released in v1.1.3) introduced an issue where dmix reports its state differently when snd_pcm_state is queried, compared to snd_pcm_status. 38a2d2eda880fda9ed5a4a219db498d9c0856d71 (I suspect faf53c197cabeb1eb0fd1f66cd001d1469ebac09 affects dshare similarly, but this is not tested) The sample program attached at the bottom of this email demonstrates this behaviour by printing the following on underrun: try 1: status_state=3, state=4 try 2: status_state=3, state=4 ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred Cheers, Cheng --- #include <assert.h> #include <alsa/asoundlib.h> #include <stdint.h> #define FRAMES 100 int32_t buffer[FRAMES][2]; int main(int argc, char *argv[]) { const char *pcmname = argc == 2 ? argv[1] : "default"; snd_pcm_t *pcm; assert( snd_pcm_open(&pcm, pcmname, SND_PCM_STREAM_PLAYBACK, 0) == 0 ); assert( snd_pcm_set_params(pcm, SND_PCM_FORMAT_S32_LE, SND_PCM_ACCESS_RW_INTERLEAVED, 2, 48000, 1, 250) == 0 ); for (;;) { snd_pcm_sframes_t written = snd_pcm_writei(pcm, buffer, FRAMES); if (written <= 0) { snd_pcm_status_t *status; snd_pcm_status_alloca(&status); assert( snd_pcm_status(pcm, status) == 0 ); int status_state, state; status_state = snd_pcm_status_get_state(status); state = snd_pcm_state(pcm); printf("try 1: status_state=%d, state=%d\n", status_state, state); status_state = snd_pcm_status_get_state(status); state = snd_pcm_state(pcm); printf("try 2: status_state=%d, state=%d\n", status_state, state); assert( snd_pcm_recover(pcm,written,0) == 0 ); } } }

1 1

Re: [alsa-devel] 1.1.4 bug report: dmix fails when using both 32-bit and 64-bit clients
by Takashi Iwai 26 May '17

26 May '17

On Thu, 25 May 2017 22:17:45 +0200, Cheng Sun wrote: > > On 25 May 2017 at 19:55, Takashi Iwai <tiwai(a)suse.de> wrote: > > On Thu, 25 May 2017 20:34:23 +0200, > > Cheng Sun wrote: > >> > >> On 25 May 2017 at 19:17, Takashi Iwai <tiwai(a)suse.de> wrote: > >> > On Thu, 25 May 2017 18:51:10 +0200, > >> > Cheng Sun wrote: > >> >> > >> >> On 25 May 2017 at 17:31, Takashi Iwai <tiwai(a)suse.de> wrote: > >> >> > On Thu, 25 May 2017 17:43:44 +0200, > >> >> > Cheng Sun wrote: > >> >> >> > >> >> >> On 25 May 2017 14:49, "Takashi Iwai" <tiwai(a)suse.de> wrote: > >> >> >> > > >> >> >> > On Wed, 24 May 2017 21:13:46 +0200, > >> >> >> > Cheng Sun wrote: > >> >> >> > > > >> >> >> > > Hi all, > >> >> >> > > > >> >> >> > > The following commit (released in v1.1.4) introduced an issue where a > >> >> >> > > client compiled against a 32-bit (x86) compile of alsa-lib cannot use > >> >> >> > > the same dmix as a client compiled against a 64-bit alsa-lib. > >> >> >> > > > >> >> >> > > 1a9bd0f0448106b917ae7f7bedccfcbf6ce84802 > >> >> >> > > > >> >> >> > > The error message is: > >> >> >> > > > >> >> >> > > ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC > >> >> >> > > shm instance > >> >> >> > > > >> >> >> > > The following forum post (not mine) describes the symptoms of the > >> >> >> > > issue in more detail (although the git commit the poster specified is > >> >> >> > > not correct): > >> >> >> > > > >> >> >> > > > >> >> >> https://forums.gentoo.org/viewtopic-p-8072290.html?sid=c2fbca45102933ddf9ca… > >> >> >> > > >> >> >> > There is a known problem when you mix up two alsa-lib versions because > >> >> >> > of the changes in dmix shmem struct. The solution should upgrade all > >> >> >> > users. > >> >> >> > >> >> >> (Apologies for duplicate email --accidentally sent the first reply to the > >> >> >> wrong address.) > >> >> >> > >> >> >> Arch Linux has upgraded both its 32 and 64 bit packages to v1.1.4, and I'm > >> >> >> still experiencing this problem. > >> >> >> > >> >> >> While bisecting the bug I linked against two compiles of the same alsa-lib > >> >> >> versions each time. > >> >> >> > >> >> >> Let me know if I can provide any other information. > >> >> > > >> >> > OK, at first to see whether it's the issue of the struct size > >> >> > mismatch, check the following patch. If it is, you'll see the error > >> >> > message. To be sure, check both cases: 64bit -> 32bit, and 32bit -> > >> >> > 64bit. > >> >> > >> >> The behaviour is different for the two cases. > >> >> > >> >> 1) If 64bit client is started first, then the 32bit client prints the following: > >> >> > >> >> magic mismatch: shmptr=a15ad4f0, expected=a15ad4ec > >> >> ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC shm instance > >> >> > >> >> 2) If 32bit client is started first, then the 64bit client only prints: > >> >> > >> >> ALSA lib pcm_dmix.c:1077:(snd_pcm_dmix_open) unable to create IPC shm instance > >> >> > >> >> I've added some further print statements and it turns out that this is > >> >> because the "return err;" on line 115 is triggered. > >> > > >> > Hm, so at least the struct size difference is a problem. > >> > Doese the patch below change the behavior? > >> > >> Your patch did not change the behaviour. > > > > Hmm, then it's 8 bytes alignment. > > > >> However, as an experiment I added "__attribute__((__packed__))" to the > >> struct, which fixed the problem. So this does seem to be caused by gcc > >> padding structs differently when compiling 32-bit vs 64-bit. > >> > >> I don't think "__attribute__((__packed__))" is necessarily the correct > >> solution here though. > > > > OK, that's at least one way to fix. Another way would be to put > > another 4 bytes integer as a padding. Could you give it a try, too? > > > > > > Takashi > > The following patch works. I'm a little worried that future > rearrangement/additions to the struct will cause it to break again > though... Yes, maybe the combination of both is the better way. That is, we should add packed attribute, but OTOH we should avoid the incompatibility again from 1.1.4 at least on x86-64. If a padding + packed doesn't change the struct size on x86-64 from the unpatched struct, we can go with it. Alternatively, we may move the new field into some of unused old fields. Below is an example. This will make it backward compatible with 1.1.3 and older versions. thanks, Takashi -- 8< -- --- a/src/pcm/pcm_direct.c +++ b/src/pcm/pcm_direct.c @@ -615,7 +615,7 @@ int snd_pcm_direct_slave_recover(snd_pcm } return ret; } - direct->shmptr->recoveries++; + direct->shmptr->s.recoveries++; semerr = snd_pcm_direct_semaphore_up(direct, DIRECT_IPC_SEM_CLIENT); if (semerr < 0) { @@ -631,11 +631,11 @@ int snd_pcm_direct_slave_recover(snd_pcm */ int snd_pcm_direct_client_chk_xrun(snd_pcm_direct_t *direct, snd_pcm_t *pcm) { - if (direct->shmptr->recoveries != direct->recoveries) { + if (direct->shmptr->s.recoveries != direct->recoveries) { /* no matter how many xruns we missed - * so don't increment but just update to actual counter */ - direct->recoveries = direct->shmptr->recoveries; + direct->recoveries = direct->shmptr->s.recoveries; pcm->fast_ops->drop(pcm); /* trigger_tstamp update is missing in drop callbacks */ gettimestamp(&direct->trigger_tstamp, pcm->tstamp_type); @@ -1539,7 +1539,7 @@ int snd_pcm_direct_open_secondary_client dmix->slave_buffer_size = spcm->buffer_size; dmix->slave_period_size = dmix->shmptr->s.period_size; dmix->slave_boundary = spcm->boundary; - dmix->recoveries = dmix->shmptr->recoveries; + dmix->recoveries = dmix->shmptr->s.recoveries; ret = snd_pcm_mmap(spcm); if (ret < 0) { --- a/src/pcm/pcm_direct.h +++ b/src/pcm/pcm_direct.h @@ -66,7 +66,6 @@ typedef struct { char socket_name[256]; /* name of communication socket */ snd_pcm_type_t type; /* PCM type (currently only hw) */ int use_server; - unsigned int recoveries; /* no of executed recoveries on slave*/ struct { unsigned int format; snd_interval_t rate; @@ -95,7 +94,7 @@ typedef struct { unsigned int stop_threshold; unsigned int silence_threshold; unsigned int silence_size; - unsigned int xfer_align; /* not used */ + unsigned int recoveries; /* no of executed recoveries on slave*/ unsigned long long boundary; unsigned int info; unsigned int msbits;

2 1

[alsa-devel] [PATCH 0/3] ALSA: Add rewind disable support
by Subhransu S. Prusty 26 May '17

26 May '17

Rewinds can be disabled when data written in ring buffer will never be validated. This allows for new HDaudio SPIB DMA functionality(allow fetch up to the application pointer, no rewind supported). Skylake driver changes using SPIB will be posted once the core changes are merged. Based on discussion on community, .ack callback is extended with new attribute argument, to allow fetch up to the application pointer. Also drop the mmap of status and control if SPIB functionality is reported by driver. There may be some slight performance downside, but it's likely very small. Verified the changes with tinyalsa and alsa-lib, with both mmap and without mmap support and it works fine. Pierre-Louis Bossart (3): ALSA: core: let low-level driver or userspace disable rewinds ALSA: core: modify .ack callback to take arguments for updating appl ptr ALSA: pcm: conditionally avoid mmap of control data include/sound/pcm-indirect.h | 4 ++-- include/sound/pcm.h | 9 +++++++- include/uapi/sound/asound.h | 2 ++ sound/core/pcm_lib.c | 6 ++++-- sound/core/pcm_native.c | 49 ++++++++++++++++++++++++++++++++++++++++++- sound/mips/hal2.c | 14 ++++++++++--- sound/pci/cs46xx/cs46xx_lib.c | 18 ++++++++++++---- sound/pci/emu10k1/emupcm.c | 8 +++++-- sound/pci/rme32.c | 15 ++++++++++--- 9 files changed, 107 insertions(+), 18 deletions(-) -- 1.9.1

5 30

[alsa-devel] Problems with the DP MST audio support patchset
by Pascal Wichmann 26 May '17

26 May '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I am not sure whether alsa-devel is the right place for this kind of question. If it is not, please tell me a better place for them. I am building my kernel against the drm-tip freedesktop repository which includes the patches from December 2016 (message id <1480992519-108079-1-git-send-email-libin.yang(a)intel.com> and follow-ups on alsa-devel). I am using a ThinkPad X250 and the ThinkPad Ultra Dock with the HDMI output connected to my YAMAHA HTR-2866; this hdmi output is seen as display port and uses DP MST from the dock. In principle, everything is working quite well; however, I frequently recognize two weird behaviours: * First of all, my audio receiver has 5.1 support. When I configure my laptop to send 5.1 audio using alsa or pulseaudio, there is only silence and no audio signal reaches the receiver; however, when I choose 7.1 digital surround (which my receiver actually does not suppo rt natively), everything works well and the two additional speakers are split to the existing ones (I do not know whether alsa/the kernel or the receiver does this, probably it is the receiver). This problem is pretty much only esthetical, as everything works fine if I use the 7.1 "work-around" (Digital Stereo does work also, but obviously does not support the full 5.1 setup) * The other problem -- which is actually very annoying -- is that there frequently is silence though there is audio playing; this happens now and then, but when there has been *no* output for a while, it always happens a few seconds after starting the new output and lasts for two to three seconds. During these periods of silence, the icons on my receiver indicating that there is an audio source are also gone. This problem occurs with 7.1 configuration as well as with Digital Stereo. I am not sure what these problems are caused by and do not know what kin d of debug information you may require to get more hints on how to solve them. Any hints are appreciated. Thank you for your advice, Pascal Wichmann -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE/gJ8Tpn0OtJz8hxD6+YIa34W/zYFAljbj5cACgkQ6+YIa34W /zbIVg//QP4A0wUE2MyaEAenN8nUpNV5ASglRTZ0N5hXBjD+B/sxIMkJdtSynlcB eBYL90ZLuFHxdfXsltifeY29D7CaHfyqQCeJUfzV+RgUGrlv0wqk2vA9Dfc+RTIT PBORlyuknqIV14z8vxMGO/1+Po/S8AFplK/QJs9Y+irGAX+CAhBMlVMt8V5rbL+e oD8KRWgPIwuYShhd0f3tmgqdhRn9RUQgBaYOaq1pXdI/nNDHZuRA021zytkkV4rR NGG2zOsgrrXo82ac1AAeUXlNczqUCM7UXNLjpVYUQQotEMZd9d6oL5/Iq/bD7Z8i Z+bzOWymzaaThqarc11UL9ngJr6JsDNXgdDrLgLbkSE1r6Knq66qzOmzZL7qeUDI 1JeCNkmztn82VLovRogQTY8p8Ye7gXwVUPNDocCoeBKgRA6u2VGs+zJljCDOiyT9 cCA+QGMpRMz+KLt82Bt5/vE6TzngUEOZli34wNhf6DaHYo+0j4TpiCZT3roIVlp+ C+tPvDsbt9SfVLKvmoDCKAS8o5wp7+jESAsTEMzssBeN6LYKTWeAJeZHymf17ckb Y3oub8Wk5bEvZh0AO5q7wqdWMLuTc9BSmJ8eJA0jNV+m9sGKxaTB/qFMfNoJjfFD yvBBeYvic0btTtOiQAPEia1igNR9vt1hpj5wCI6xNQwSekM1bOQ= =/6Dp -----END PGP SIGNATURE-----

4 13