Re: [opensource-dev] 3D soound

2011-05-25 Thread Boroondas Gupte 
On 05/24/2011 07:42 PM, Lee ponzu wrote:
> I saw this cool demo of 3D sound.  This is totally different from the
> SL Voice technology, and I think it would compliment it perfectly.
>
> Take a look...
>
> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=princeton+3D+sound
> 
OK, let's see. (Haven't watched the video
 fully, yet, as I can't turn up the
speakers where I am right now.)

> The basic idea is that stereo gives a weak illusion of 3D.
Oh? Stereo can give you the most perfect illusion of 3D, /when listened
to over headphones/ and mixed or recorded for headphones. Listen to the
popular "virtual barbershop" recording to know what I mean. The only
real problem there is that when you turn your head, the sound sources
seem to turn with it, while the picture on a screen won't move. (Off
course, with VR glasses instead of a fixed screen, you don't have that
problem.)

The challenge is '3D sound' via stereo /speakers/. This poses several
issues: When you turn your head so the line connecting your ears is
perpendicular to the line connecting the two speakers, the stereo effect
goes away almost completely. If you turn your head less, the stereo
effect is still being damped (which is bad, if you want the impression
of 3D), but at least the sound sources don't move with your head (which
is good, assuming you don't combine fixed position speakers with VR
glasses without head tracking).

Off course, because of the cross-talking mentioned in the video (which
is almost negligible for headphones, but very present for speakers at
fixed positions) you need very different mixing for speakers than for
headphones, to get a comparable 3D illusion.

That observation is not new, though. Actually I remember an infotainment
application (a PC planetarium or interactive space object encyclopaedia
or something like that) from the last century that had two modes for its
(synthesized?) stereo sound, one for speakers and one for headphones.
The sound there was 'just' music and some UI sounds (like when you click
a button), so I'm not sure why that was important to the makers of the
program, but it certainly gave the thing a very 'spacey' feeling.

> You have the left signal, ls, and the right signal, rs.  A filter computes
>
> rs_new = rs - ls
> ls_new = ls - rs
>
> and then play rs_new and ls_new.  (Details left as an exercise...)
Dunno if it's a detail, but your equation are so oversimplified that
they've become wrong (or useless, rather): With the computation above,
you have rs_new = - ls_new. Duh. Now all spatial information is lost,
you just have a mono signal on one speaker and its inversion on the
other. (Which might further lead to funny destructive interference
issues, when your distance to both speakers is exactly the same.)

> In English---when you record in stereo, you record cross talk between
> the mics which is recreated when you play back.  This idea removes the
> cross talk, and dramatically increases the 3D illusion.  It is a
> simple filter and works totally at playback time on all sound sources
> and any stereo recording.  It would be easy to add it to the viewer...
If something like that is added, it has to be optional, or at least have
a headphone and a speakers mode, so that headphone users aren't worse
off than today.

Cheers,
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 3D soound

2011-05-25 Thread Celierra Darling 
Hmm, SL would first need to synthesize stereo sound, as should be heard
through headphones, very well, it seems. From what I can tell, the technique
ends up simulating wearing headphones when you're actually listening through
speakers.  According to the site, the idea is that the stereo sounds with
all the right audio cues (time and volume differences) were recorded, but if
you play it back using speakers, the illusion ends up destroyed by the
interfering crosstalk. [1]

But I'm pretty sure that some SL sounds (at least, voice - I vaguely recall
SL inworld audio stuff being more nuanced?) aren't synthesized with the
correct-for-headphones effects.  I remember feeling very disoriented in
voice meetings because people to my left or right ended up having their
voice playing pretty much exclusively in my left or right ear, which isn't
correct.  I could imagine that, in such situations, real-world crosstalk
from loudspeakers actually helps recreate the illusion during playback -
perhaps it was a bit of a hack based on having the volume difference be
interpreted as attenuation.
It does look like implementation is a lot more complicated than it, er,
sounds... There's something involving something called a BACCH filter, with
"some aspects not published for propriety reasons". [2]

So to apply this to SL, there'd need to be:
1) accurate synthesizing of sounds as would be heard next to the ears (i.e.
what headphones should play) for both inworld clips and voice, using both
time delay and attenuation
 2) knowledge of whether the listener is using headphones or speakers
3) implementation of this crosstalk cancellation thing if they're using
speakers
3b) permission/licensing to use it from Princeton

Celi

[1]
http://www.princeton.edu/3D3A/PureStereo/Pure_Stereose10.html#x21-110
[2] http://www.princeton.edu/3D3A/Papers.html

On Tue, May 24, 2011 at 1:42 PM, Lee ponzu  wrote:

> I saw this cool demo of 3D sound.  This is totally different from the SL
> Voice technology, and I think it would compliment it perfectly.
>
> Take a look...
>
> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=princeton+3D+sound
>
> The basic idea is that stereo gives a weak illusion of 3D.  You have the
> left signal, ls, and the right signal, rs.  A filter computes
>
> rs_new = rs - ls
> ls_new = ls - rs
>
> and then play rs_new and ls_new.  (Details left as an exercise...)
>
> In English---when you record in stereo, you record cross talk between the
> mics which is recreated when you play back.  This idea removes the cross
> talk, and dramatically increases the 3D illusion.  It is a simple filter and
> works totally at playback time on all sound sources and any stereo
> recording.  It would be easy to add it to the viewer...
>
> Just an idea.
> ponzu
>
>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-05-25 Thread Boroondas Gupte 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/313/
---

Review request for Viewer.


Summary
---

Context: We are currently using Boost 1.45, which already comes with the new 
Boost Filesystem Library API (Version 3) but still defaults to the old one 
(Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be 
the last one to come with V2. The Boost Filesystem Library documentation 
recommends "Existing code should be moved to Version 3 as soon as convenient. 
New code should be written for Version 3. Version 2 is deprecated, and will not 
be included in Boost releases 1.48 and later."

This change overrides the default, so that the V3 API is used, and makes the 
necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we 
feel like it.)

Note: I only changed stuff that the compiler complained about. If the new API 
also changes semantic of still-compiling library usage, more changes might be 
necessary.


This addresses bug OPEN-67.
http://jira.secondlife.com/browse/OPEN-67


Diffs
-

  doc/contributions.txt 959f9340da92 
  indra/llvfs/lldiriterator.cpp 959f9340da92 

Diff: http://codereview.secondlife.com/r/313/diff


Testing
---

* Compiled Viewer (standalone) with Boost 1.45
* Started Viewer
* Logged in

* Compiled Viewer (standalone) with Boost 1.46
* Started Viewer
* Logged in

Not tested:
* non-standalone


Thanks,

Boroondas

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-05-25 Thread Boroondas Gupte 


> On May 24, 2011, 3:32 p.m., Boroondas Gupte wrote:
> > indra/llvfs/lldiriterator.cpp, lines 140-144
> > 
> >
> > Meh, my backwards-compatibility approach does not work: The existance 
> > of fs::path::native() will be checked by the compiler, even when this 
> > method is never called and thus (as it's inlined) would never even show up 
> > in the binary.

A hopefully better fix is under review at 
https://codereview.secondlife.com/r/313/


- Boroondas


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/307/#review712
---


On May 24, 2011, 3:41 p.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/307/
> ---
> 
> (Updated May 24, 2011, 3:41 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Some trickery needed to make this forward compatible to newer Boost versions 
> while keeping compatibility to the currently used Boost version.
> 
> 
> This addresses bug OPEN-67.
> http://jira.secondlife.com/browse/OPEN-67
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 959f9340da92 
>   indra/llvfs/lldiriterator.cpp 959f9340da92 
> 
> Diff: http://codereview.secondlife.com/r/307/diff
> 
> 
> Testing
> ---
> 
> * Compiled Viewer (standalone) with Boost 1.46
> * Started Viewer
> * Logged in
> 
> * Tried to compile Viewer (standalone) with Boost 1.45 (which has the new 
> API, but apparently defaults to the old one)
> ** this fails with
>indra/llvfs/lldiriterator.cpp:143: error: ‘const struct 
> boost::filesystem2::path’ has no member named ‘native’
> 
> Not tested:
> * non-standalone
> 
> 
> Thanks,
> 
> Boroondas
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-05-25 Thread Altair Memo 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/313/#review714
---

Ship it!


work fine with both 1.45 from 3p-libs both custom 1.46 prebuilt libs 
(non-standalone)

- Altair


On May 25, 2011, 1:25 p.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/313/
> ---
> 
> (Updated May 25, 2011, 1:25 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Context: We are currently using Boost 1.45, which already comes with the new 
> Boost Filesystem Library API (Version 3) but still defaults to the old one 
> (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will 
> be the last one to come with V2. The Boost Filesystem Library documentation 
> recommends "Existing code should be moved to Version 3 as soon as convenient. 
> New code should be written for Version 3. Version 2 is deprecated, and will 
> not be included in Boost releases 1.48 and later."
> 
> This change overrides the default, so that the V3 API is used, and makes the 
> necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever 
> we feel like it.)
> 
> Note: I only changed stuff that the compiler complained about. If the new API 
> also changes semantic of still-compiling library usage, more changes might be 
> necessary.
> 
> 
> This addresses bug OPEN-67.
> http://jira.secondlife.com/browse/OPEN-67
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 959f9340da92 
>   indra/llvfs/lldiriterator.cpp 959f9340da92 
> 
> Diff: http://codereview.secondlife.com/r/313/diff
> 
> 
> Testing
> ---
> 
> * Compiled Viewer (standalone) with Boost 1.45
> * Started Viewer
> * Logged in
> 
> * Compiled Viewer (standalone) with Boost 1.46
> * Started Viewer
> * Logged in
> 
> Not tested:
> * non-standalone
> 
> 
> Thanks,
> 
> Boroondas
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-05-25 Thread Ricky 
I like the very descriptive comment above the #define - Makes the purpose
crystal clear, AND places an expiration on the line so it will be easy to
know when/if it is time to remove said line!

As to the functionality - havent tested it :(

Ricky
Cron Stardust

On Wed, May 25, 2011 at 1:25 PM, Boroondas Gupte  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/313/
>   Review request for Viewer.
> By Boroondas Gupte.
> Description
>
> Context: We are currently using Boost 1.45, which already comes with the new 
> Boost Filesystem Library API (Version 3) but still defaults to the old one 
> (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will 
> be the last one to come with V2. The Boost Filesystem Library documentation 
> recommends "Existing code should be moved to Version 3 as soon as convenient. 
> New code should be written for Version 3. Version 2 is deprecated, and will 
> not be included in Boost releases 1.48 and later."
>
> This change overrides the default, so that the V3 API is used, and makes the 
> necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever 
> we feel like it.)
>
> Note: I only changed stuff that the compiler complained about. If the new API 
> also changes semantic of still-compiling library usage, more changes might be 
> necessary.
>
>   Testing
>
> * Compiled Viewer (standalone) with Boost 1.45
> * Started Viewer
> * Logged in
>
> * Compiled Viewer (standalone) with Boost 1.46
> * Started Viewer
> * Logged in
>
> Not tested:
> * non-standalone
>
>   *Bugs: * OPEN-67 
> Diffs
>
>- doc/contributions.txt (959f9340da92)
>- indra/llvfs/lldiriterator.cpp (959f9340da92)
>
> View Diff 
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] about VWR-10710

2011-05-25 Thread Philippe (Merov) Bossut 
Hi,

I think there are 2 issues here:
1- wrong textures: this is likely a texture cache corruption as explained by
Moy Loon in the JIRA (VWR-10710). Still, we should find a way to avoid this
kind of cache confusion.
2- console overwriting itself: a similar bug was fixed in Snowglobe 1.x (
https://jira.secondlife.com/browse/SNOW-205). I *did not* port the patch
when rebasing Snowglobe 2.x as it was a bit of work to do and I couldn't
repro the issue. The patch is still available in the SNOW-205 JIRA though
and, since you now have a repro case, it could be worth to port it.

Cheers,
- Merov

On Mon, May 23, 2011 at 11:22 AM, Altair Sythos  wrote:

> i've spent last weekend testing and investigating about the jira in
> subject (i think is a bug more annoying than a lot other why corrupt a
> lot of creations). I've seen mistexturized textures on sculpt and
> profile pics, and increasing monitor resolution and playing with
> screenshot i've noticed the textures aren't "really" broken, are just
> the wrong resolution. (btw:
> https://jira.secondlife.com/browse/VWR-10710 )
>
> As uploaded here: https://picasaweb.google.com/sythos/RainbowTextures
> i've seen profile pics became more or less 25% or widht/height, spare
> place are filled with fuzzy/random pixels.
> Same happen on sculpt textures, the "broken" textures is rescaled on
> upper left corner of object (i mean mapping direction).
>
> opening texture console (hoping no UI bug) i've noticed too a random
> miscaled progressive bar: every time a progressive bar go over 100%
> (supposing right limit is 100%) the texture appear broken, this happen
> both for profile pics and both for sculpts.
>
> I've noticed this happen on both profile pics uplodaed via web profiles
> both old ones from inventory, without any relations with image format.
> On sculpts same, misresizing happen both png, jpg or tga...
>
> Sincerely cannot repro on planar or other kind of obj but sculpt.
>
> i've snorked into the code, looking for a typo, bug or something
> suspicious into images lenght routines, without any success :-\
>
>
> Somebody can hint where check to understand what/where the bug born?
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges