<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>193147</bug_id>
          
          <creation_ts>2007-09-20 08:13 0000</creation_ts>
          <short_desc>media-libs/openal-0.0.8-r2 - no sound w/ ALSA / Intel HDA at 48k sampling rate</short_desc>
          <delta_ts>2007-09-22 07:08:11 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Applications</component>
          <version>2007.0</version>
          <rep_platform>AMD64</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>minor</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>schnake.newsletter@t-online.de</reporter>
          <assigned_to>wolf31o2@gentoo.org</assigned_to>
          <cc>schnake.newsletter@t-online.de</cc>
    
    <cc>sound@gentoo.org</cc>
    
    <cc>xanas3712@matrixcentral.net</cc>

      

      
          <long_desc isprivate="0">
            <who>schnake.newsletter@t-online.de</who>
            <bug_when>2007-09-20 08:13:32 0000</bug_when>
            <thetext>Summary
=======
No sound from OpenAL apps when using the ALSA backend on an Intel HDA soundchip until sampling rate is explicitly set to 44.1 kHz in both .asoundrc (or /etc/asound.conf) AND .openalrc.

Description
===========
There is no error message, apps using OpenAL simply remain silent. I did test this with UT2004 (using the systems libopenal.so instead of the one shipped with UT2004) and FlightGear. But I am pretty sure that the problem is at the OpenAL layer and affects all apps using OpenAL.

Sound works fine otherwise (ALSA and ALSA OSS emulation in mplayer, xine, amarok ... everywhere but in OpenAL apps). And using OpenAL with the &quot;native&quot; backend (/dev/sound/dsp provided by ALSA OSS emulation) works with 48kHz, too (but grabs the soundcard exclusively, so no dmix possible, and has some (minor) audible artifacts).

System
======
- IBM/Lenovo Thinkpad Z61m, 2 MB RAM
- Kernel: Linux spock 2.6.22-gentoo-r5 #5 SMP PREEMPT Tue Sep 18 20:48:14 CEST 2007 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux
- Intel HDA (AD1981)
- ALSA modules from kernel (&quot;Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC&quot;)

I will post my &quot;emerge --info&quot; output on request, but do not think it is relevant for the bug at hand.

Workaround
==========
After explicitly forcing the sampling rate to 44.1 kHz (by adding &quot;rate 44100&quot; to /etc/asound.conf and &quot;(define sampling-rate 44100)&quot; to ~/.openalrc) sound from OpenAL apps works perfectly fine (without &quot;crackles&quot; or glitches).

I also told the ALSA module my exact model name by adding &quot;options snd-hda-intel model=thinkpad&quot; to /etc/modules.d/alsa. But I&apos;m not sure whether this is necessary.

Expected behaviour
==================
I want to be able to run OpenAL -&gt; ALSA at the &quot;natural&quot; sampling rate of my Intel HDA sound card (= 48kHz) to avoid sampling rate conversion (both for perfomance and quality reasons).

Additional info
===============

Working /etc/asound.conf
------------------------
pcm.!default {
	type plug
	slave.pcm &quot;dmixer&quot;
}

pcm.dmixer {
	type dmix
	ipc_key 1024
	slave {
		pcm &quot;hw:0,0&quot;
		channels 2
		period_time 0
		period_size 2048
		buffer_size 4096
		rate 44100
	}

	bindings {
		0 0
		1 1
	}
}

ctl.dmixer {
	type hw
	card 0
}

Working ~/.openalrc
-------------------
(define devices &apos;(alsa null))
(define alsa-device &quot;default&quot;)
(define speaker-num 2)
(define sampling-rate 44100)

I am pretty sure that this an OpenAL bug that has to be fixed upstream, but it took me quite some time to figure this out and finally get (&quot;dmix&quot;ed) sound from OpenAL. Possibly Gentoo can come up with a patch (maybe something like already proposed at http://thread.gmane.org/gmane.comp.lib.openal.devel/2034/focus=2034).

Feel free to close this bug if you think it is nothing that Gentoo should care about. But even then the report may still serve as a solution for others having the same problem ;-)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>schnake.newsletter@t-online.de</who>
            <bug_when>2007-09-20 10:07:55 0000</bug_when>
            <thetext>Created an attachment (id=131357)
For Intel HDA. Provides full-duplex and forces 44.1 kHz sampling rate.

</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>schnake.newsletter@t-online.de</who>
            <bug_when>2007-09-20 10:15:53 0000</bug_when>
            <thetext>Note: With the asound.conf from the bug report UT2004 complains about dmix having no capture support (but it works still fine, anyway). The asound.conf file attached in comment #1 fixes this by adding dsnoop to the mix to provide full-duplex.

And remember to run &quot;/etc/init.d/alsasound restart&quot; as root after changing your ALSA config. I had a very confusing and frustrating time before doing so, because sometimes changes seem to be not picked up correctly otherwise ;-)

This comment is not relevant for the bug itself (= unable to use 48kHz sampling rate with OpenAL) but may help if you want to try the workaround yourself.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>wolf31o2@gentoo.org</who>
            <bug_when>2007-09-20 22:50:35 0000</bug_when>
            <thetext>OK.  I added a modified version of the upstream patch since it applies to the SVN code.  Let me know if you&apos;re still having problems.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>schnake.newsletter@t-online.de</who>
            <bug_when>2007-09-21 20:33:32 0000</bug_when>
            <thetext>Created an attachment (id=131558)
Results for ALSA / OpenAL sample rate compatibility

</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>schnake.newsletter@t-online.de</who>
            <bug_when>2007-09-21 20:34:54 0000</bug_when>
            <thetext>Since things became more and more confusing to me, I decided to bite the bullet and test the results of all possible ALSA / OpenAL / OSS sampling rate combinations. The result is attached as textfile in comment #4, to prevent my &quot;ASCII art&quot; tables from being munched by bugzilla ;-)

TAKE A LOOK AT THE ATTACHED TEXTFILE! Well, the variety of results was kind of a surprise to me. Now I understand why the question &quot;No sound with game XYZ?&quot; is so difficult to be answered in a &quot;now works for everyone&quot; way.

I suggest to remove the 005_all_alsa_default_freq.patch again, since the odds to get perfect OpenAL 44.1kHz sound are slightly better without it, and the less patches the better. Sorry for suggesting that basically useless patch :-(

After enjoying the OpenAL sources from subversion trunk and diffing the &quot;debug maximus&quot; (sounds like something developed by Harry Potter ;-) messages from working and non-working runs it seems that the sampling rate conversion stuff in OpenAl-Sample (the Linux implementation) is still seriously broken even in current OpenAL. Different sample rates on input (sound) and output (backend) are simply a no-go ATM.

Conclusion:
- Since games use 44.1kHz sounds (does anyone know one with 48kHz sounds and
  using OpenAL?),
- and since OpenAL is mostly used with games (the only exception I know of is
  the 3D-Modeller Blender),
- and since using OSS disables DMIX capability,
the only viable options for gamers are #6 and #7 (from the table without 005_all_alsa_default_freq.patch, see attached file).

So, if you want sound from OpenAL with games (44.1kHz), and

... your soundcard defaults to 48kHz, you 
-----------------------------------------
- *HAVE TO* provide an /etc/asound.conf forcing the card to 44.1kHz sampling
  rate (see attachment from comment #1 for an example).
- *HAVE TO* provide an /etc/openal forcing ALSA default device usage (instead of
  using OSS):
	(define devices &apos;(alsa))
	(define alsa-device &quot;default&quot;)
- *MAY* explicitly define the sampling rate in /etc/openal with the additional
  line:
	(define sampling-rate 44100) 

... your soundcard defaults to 44.1kHz, you
-------------------------------------------
- *MAY* provide an /etc/asound.conf leaving the card at 44.1kHz sampling rate
  (see attachment from comment #1 for an example).
- *HAVE TO* provide an /etc/openal forcing ALSA default device usage (instead of
  using OSS):
	(define devices &apos;(alsa))
	(define alsa-device &quot;default&quot;)
- *MAY* explicitly define the sampling rate in /etc/openal with the additional
  line:
	(define sampling-rate 44100) 

... your soundcard defaults to 48kHz and does not work with 44.1kHz, you
------------------------------------------------------------------------
- *MAY* provide an /etc/asound.conf (but you can not do anything about your
  sample rate) (see attachment from comment #1 for an example).
- *MUST NOT* have an /etc/openal at all, or one that explicitly selects OSS via:
	(define devices &apos;(native))
- *HAVE TO* accept that you can not currently play OpenAL games and have DMIX at
  the same time, as you must use the OSS emulation ;-)

As on how to proceed, I suggest adding an ewarn and / or README to the openal ebuild that explains the issue / points to this bug, and close this bug as resolved. Additionally I will put a pointer to this bug on the openal mailing list. The developers seem to be more focused on the Windows version these days, but IMHO we should give it try anyway.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>xanas3712@matrixcentral.net</who>
            <bug_when>2007-09-21 22:47:47 0000</bug_when>
            <thetext>I had to increase the buffer size on my system or mplayer audio (using alsa) was glitchy (crackling) but besides that I made no changes from the other notes in here thus far.

</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>schnake.newsletter@t-online.de</who>
            <bug_when>2007-09-22 07:08:11 0000</bug_when>
            <thetext>Matthew,
glad it worked for you. Yes, configuring ALSA on your system may of course involve changing parameters like buffer/period sizes, number of periods, module parameters etc. That&apos;s a topic on itself. But even after you have a perfectly working ALSA, you still have to watch out for some nasty pitfalls to get *OpenAL* running on top of it. And that&apos;s what this bug is about ;-)

</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>131357</attachid>
            <date>2007-09-20 10:07 0000</date>
            <desc>For Intel HDA. Provides full-duplex and forces 44.1 kHz sampling rate.</desc>
            <filename>asound.conf</filename>
            <type>text/plain</type>
            <data encoding="base64">IyMjIyMKIyBGb3IgdXNlIHdpdGggSW50ZWwgSERBLgojIC0gUHJvdmlkZXMgZnVsbC1kdXBsZXgg
Zm9yIHRoZSBkZWZhdWx0IGRldmljZSB2aWEgZG1peCAvIGRzbm9vcCBhbmQgYXN5bS4KIyAtIEZv
cmNlcyA0NC4xa0h6IHNhbXBsaW5nIHJhdGUgKGluc3RlYWQgb2YgNDhrSHopIGZvciBPcGVuQUwg
Y29tcGF0aWJpbGl0eS4KIyAgIE5vdGU6IEZvciB0aGlzIHRvIHdvcmsgIihkZWZpbmUgc2FtcGxp
bmctcmF0ZSA0NDEwMCkiIG11c3QgYmUgc3BlY2lmaWVkIGluIH4vLm9wZW5hbHJjIGFsc28uCiMg
ICAgICAgICBTZWUgaHR0cDovL2J1Z3MuZ2VudG9vLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTkzMTQ3
IGZvciBkZXRhaWxzLgojCiMgUkVNRU1CRVIgVE8gU1RPUCBBTEwgQVBQUyBVU0lORyBBTFNBIEFO
RCBSVU4gIi9ldGMvaW5pdC5kL2Fsc2Fzb3VuZCByZXN0YXJ0IiBBUyBST09UIQojIE90aGVyd2lz
ZSBjaGFuZ2VzIHNlZW0gbm90IHRvIGJlIHBpY2tlZCB1cCBjb3JyZWN0bHkgc29tZXRpbWVzICh2
ZXJ5IGNvbmZ1c2luZyA7LSkKIyMjIyMKCnBjbS4hZGVmYXVsdCB7Cgl0eXBlIHBsdWcKCXNsYXZl
LnBjbSAiZHVwbGV4Igp9CgpjdGwuIWRlZmF1bHQgewoJdHlwZSBodwoJY2FyZCAwCn0KCnBjbS5k
dXBsZXggewoJdHlwZSBhc3ltCglwbGF5YmFjay5wY20gImRtaXhlciIKCWNhcHR1cmUucGNtICJk
c25vb3BlciIKfQoKcGNtLmRtaXhlciB7Cgl0eXBlIGRtaXgKCWlwY19rZXkgMTAyNAoJc2xhdmUg
ewoJCXBjbSAiaHc6MCwwIgoJCWNoYW5uZWxzIDIKCQlwZXJpb2RfdGltZSAwCgkJcGVyaW9kX3Np
emUgMjA0OAoJCWJ1ZmZlcl9zaXplIDQwOTYKCQlyYXRlIDQ0MTAwCgl9CgoJYmluZGluZ3MgewoJ
CTAgMAoJCTEgMQoJfQp9CgpwY20uZHNub29wZXIgewoJdHlwZSBkc25vb3AKCWlwY19rZXkgMTAy
NQoJc2xhdmUgewoJCXBjbSAiaHc6MCwwIgoJCWNoYW5uZWxzIDIKCQlwZXJpb2RfdGltZSAwCgkJ
cGVyaW9kX3NpemUgMjA0OAoJCWJ1ZmZlcl9zaXplIDQwOTYKCQlyYXRlIDQ0MTAwCgl9CgoJYmlu
ZGluZ3MgewoJCTAgMAoJCTEgMQoJfQp9Cg==
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>131558</attachid>
            <date>2007-09-21 20:33 0000</date>
            <desc>Results for ALSA / OpenAL sample rate compatibility</desc>
            <filename>Intel-HDA_OpenAL-ALSA_sampling-rate_tables.txt</filename>
            <type>text/plain</type>
            <data encoding="base64">T3BlbkFMIC8gQUxTQSBzYW1wbGluZyByYXRlIGNvbXBhdGliaWxpdHkgZm9yIEludGVsIEhEQSBz
b3VuZGNhcmRzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PQoKbWVkaWEtbGlicy9vcGVuYWwtMC4wLjgtcjIgd2l0aCAwMDVf
YWxsX2Fsc2FfZGVmYXVsdF9mcmVxLnBhdGNoCistLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t
LS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0t
LS0rLS0tLS0tKwp8ICMgfCBBTFNBOiByYXRlIHwgT3BlbkFMOiBkZXZpY2UgfCBPcGVuQUw6IHJh
dGUgfCBlZmYuIGRldmljZSAgfCA0NC4xa0h6ICAgfCA0OGtIeiAgICAgfCBETUlYIHwKKy0tLSst
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0rCnwgMSB8ICA0ODAwMCBIeiAgfCAgdW5z
cGVjaWZpZWQgICB8IHVuc3BlY2lmaWVkICB8IE9TUyAoZHNwKSAgICB8IGRpc3RvcnRlZCB8IHBl
cmZlY3QgICB8IE5vICAgfAp8IDIgfCAgNDgwMDAgSHogIHwgYWxzYSAvIGRlZmF1bHQgfCB1bnNw
ZWNpZmllZCAgfCBBTFNBIGRlZmF1bHQgfCBubyBzb3VuZCAgfCBwZXJmZWN0ICAgfCBZZXMgIHwK
fCAzIHwgIDQ4MDAwIEh6ICB8IGFsc2EgLyBkZWZhdWx0IHwgICA0NDEwMCBIeiAgIHwgQUxTQSBk
ZWZhdWx0IHwgc3R1dHRlcnMgIHwgbm8gc291bmQgIHwgWWVzICB8CnwgNCB8ICA0ODAwMCBIeiAg
fCBhbHNhIC8gZGVmYXVsdCB8ICAgNDgwMDAgSHogICB8IEFMU0EgZGVmYXVsdCB8IG5vIHNvdW5k
ICB8IHBlcmZlY3QgICB8IFllcyAgfAp8IDUgfCAgNDQxMDAgSHogIHwgIHVuc3BlY2lmaWVkICAg
fCB1bnNwZWNpZmllZCAgfCBPU1MgKGRzcCkgICAgfCBkaXN0b3J0ZWQgfCBwZXJmZWN0ICAgfCBO
byAgIHwKfCA2IHwgIDQ0MTAwIEh6ICB8IGFsc2EgLyBkZWZhdWx0IHwgdW5zcGVjaWZpZWQgIHwg
QUxTQSBkZWZhdWx0IHwgbm8gc291bmQgIHwgc3R1dHRlcnMgIHwgWWVzICB8CnwgNyB8ICA0NDEw
MCBIeiAgfCBhbHNhIC8gZGVmYXVsdCB8ICAgNDQxMDAgSHogICB8IEFMU0EgZGVmYXVsdCB8IHBl
cmZlY3QgICB8IG5vIHNvdW5kICB8IFllcyAgfAp8IDggfCAgNDQxMDAgSHogIHwgYWxzYSAvIGRl
ZmF1bHQgfCAgIDQ4MDAwIEh6ICAgfCBBTFNBIGRlZmF1bHQgfCBubyBzb3VuZCAgfCBzdHV0dGVy
cyAgfCBZZXMgIHwKKy0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0rCgptZWRp
YS1saWJzL29wZW5hbC0wLjAuOC1yMiB3aXRob3V0IDAwNV9hbGxfYWxzYV9kZWZhdWx0X2ZyZXEu
cGF0Y2ggKFJFQ09NTUVOREVEKQorLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0t
LSsKfCAjIHwgQUxTQTogcmF0ZSB8IE9wZW5BTDogZGV2aWNlIHwgT3BlbkFMOiByYXRlIHwgZWZm
LiBkZXZpY2UgIHwgNDQuMWtIeiAgIHwgNDhrSHogICAgIHwgRE1JWCB8CistLS0rLS0tLS0tLS0t
LS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tKwp8IDEgfCAgNDgwMDAgSHogIHwgIHVuc3BlY2lmaWVk
ICAgfCB1bnNwZWNpZmllZCAgfCBPU1MgKGRzcCkgICAgfCBwZXJmZWN0ICAgfCBkaXN0b3J0ZWQg
fCBObyAgIHwKfCAyIHwgIDQ4MDAwIEh6ICB8IGFsc2EgLyBkZWZhdWx0IHwgdW5zcGVjaWZpZWQg
IHwgQUxTQSBkZWZhdWx0IHwgc3R1dHRlcnMgIHwgbm8gc291bmQgIHwgWWVzICB8CnwgMyB8ICA0
ODAwMCBIeiAgfCBhbHNhIC8gZGVmYXVsdCB8ICAgNDQxMDAgSHogICB8IEFMU0EgZGVmYXVsdCB8
IHN0dXR0ZXJzICB8IG5vIHNvdW5kICB8IFllcyAgfAp8IDQgfCAgNDgwMDAgSHogIHwgYWxzYSAv
IGRlZmF1bHQgfCAgIDQ4MDAwIEh6ICAgfCBBTFNBIGRlZmF1bHQgfCBubyBzb3VuZCAgfCBwZXJm
ZWN0ICAgfCBZZXMgIHwKfCA1IHwgIDQ0MTAwIEh6ICB8ICB1bnNwZWNpZmllZCAgIHwgdW5zcGVj
aWZpZWQgIHwgT1NTIChkc3ApICAgIHwgcGVyZmVjdCAgIHwgZGlzdG9ydGVkIHwgTm8gICB8Cnwg
NiB8ICA0NDEwMCBIeiAgfCBhbHNhIC8gZGVmYXVsdCB8IHVuc3BlY2lmaWVkICB8IEFMU0EgZGVm
YXVsdCB8IHBlcmZlY3QgICB8IG5vIHNvdW5kICB8IFllcyAgfAp8IDcgfCAgNDQxMDAgSHogIHwg
YWxzYSAvIGRlZmF1bHQgfCAgIDQ0MTAwIEh6ICAgfCBBTFNBIGRlZmF1bHQgfCBwZXJmZWN0ICAg
fCBubyBzb3VuZCAgfCBZZXMgIHwKfCA4IHwgIDQ0MTAwIEh6ICB8IGFsc2EgLyBkZWZhdWx0IHwg
ICA0ODAwMCBIeiAgIHwgQUxTQSBkZWZhdWx0IHwgbm8gc291bmQgIHwgc3R1dHRlcnMgIHwgWWVz
ICB8CistLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tKwoKTGVnZW5kOgoKLSAi
QUxTQToiIG1lYW5zICJBTFNBIGNvbmZpZ3VyYXRpb24gZmlsZSI6CgktIC9ldGMvYXNvdW5kLmNv
bmYgKHN5c3RlbSB3aWRlKSwgb3IKCS0gfi8uYXNvdW5kcmMgKHVzZXIgc3BlY2lmaWMpCgotICJP
cGVuQUw6IiBtZWFucyAiT3BlbkFMIGNvbmZpZ3VyYXRpb24gZmlsZSI6CgktIC9ldGMvb3BlbmFs
IChzeXN0ZW0gd2lkZSksIG9yCgktIH4vLm9wZW5hbHJjICh1c2VyIHNwZWNpZmljKQoKLSBDb2x1
bW5zIDItNCBkZXNjcmliZSB3aGF0IGlzIHNwZWNpZmllZCB2aWEgdGhlIHJlc3BlY3RpdmUgY29u
ZmlndXJhdGlvbiBmaWxlLgoKLSAiZWZmLiBkZXZpY2UiIGlzIHRoZSBkZXZpY2UgYmVpbmcgdXNl
ZCBieSBPcGVuQUwgLSBlaXRoZXIgdGhlIEFMU0EgZGVmYXVsdCBkZXZpY2UsIG9yIEFMU0EncyBP
U1MgZW11bGF0aW9uICgvZGV2L3NvdW5kL2RzcCkuCgotIHRoZSBuZXh0IHR3byBjb2x1bW5zIHNo
b3cgdGhlIHJlc3VsdCBvZiBwbGF5aW5nIGEgNDQuMWtIeiAvIDQ4a0h6IGZpbGUgdmlhICJtcGxh
eWVyIC1hbyBvcGVuYWwiCgotIHRoZSBsYXN0IGNvbHVtbiBzdGF0ZXMgd2hldGhlciBhbm90aGVy
IGZpbGUgY291bGQgYmUgcGxheWVkIGNvbmN1cnJlbnRseSAoPSBETUlYIGZ1bmN0aW9uYWxpdHkp
</data>        

          </attachment>
    </bug>

</bugzilla>