Re: [Flightgear-devel] New Sound system committed
On Sun, Oct 18, 2009 at 12:59 PM, Geoff McLane wrote: > Hi Vivian, > >>> using anything other than the >>> latest build from Creative Labs? > > Well they could for example be using the openal-soft > http://sourceforge.net/projects/openal-soft/ > which suggests it is version 1.2.??? And has a CVS > download, and uses the 'AL' sub-directory! > Software versions and standard versions are two different things, the OpenAL specification is currently at version 1.1, OpenAL-Soft implements it. Also, that's the wrong place, http://kcat.strangesoft.net/openal.html is the right one, which doesn't use CVS but git. >>> cause a crash on exit here > > Have not been particularly following ALL the posts on > this, but with MSVC9's debugger you should be able to > 'see' _EXACTLY_ where/when this happens... > > Quite frequently, in Debug mainly, but can happen also > in 'random' memory in Release, it is due to things like - > if ( _data ) > delete _data; // a crash exit > since, in Debug especially, such a variable is likely filled > with a debug value, by the MSVC compiler, deliberately, and > has has never been initialized to NULL in the code... > > This is very common... It seems GCC quite frequently ensures > such 'memory', 'variables' etc are all zeros... I believe in debug mode gcc indeed initialises all memory to 0, this of course should not be done in release mode. Release code should not depend on the value of uninitialised variables. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On Sat, Sep 26, 2009 at 11:29 AM, Olaf Flebbe wrote: > Hi Erik, > > >> Did you know that the sound system eats up to 30% of CPU time, > depending > >> on hardware? This even with --disable-sound on the command line. > > > > That's OpenAL version specific. Mine is twice as fast with 256 voices > > but 3.5 times more efficient with less than 32 voices. > > Ooops, I have to admit that I am a OpenAL newbie. Do I have to use a > different set of shared libs? Are these soundcard/codec specfic? Where > should I get alternative implementations from? I thought there are only > specific implementations for high-end hardware. > On Linux you should use OpenAL-Soft (which is used by Ubuntu), Creative Labs was/is developing their own driver for their cards, but I can't speak about their status since I don't know anyone using it or interested in doing so. OpenAL-Soft is a software-only implementation, which of course means there are a few features it doesn't implement, none of which are used by fgfs, I think. > My findings are that 30% of total fgfs CPU time on the eee was spend in > in routines resampling audio, regardless if --disable-sound was set or > not. (Later I found out that --disable-sound does not disable the sound > at all: It only mutes sound.) IMHO this is an undesirable overhead even > if resampling would be 3.5 times faster. I would have expected the top > one performance bottleneck for fgfs on low end hardware is in graphics, > not sound. > This is almost certainly a bug in fgfs or PulseAudio. Cheers, Matt D. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On Fri, Sep 25, 2009 at 3:58 AM, Erik Hofman wrote: > > Olaf Flebbe wrote: > > Erik, > > > > I would like to see an option to disable sound at all. > > The changes should make that easy. Actually it was the reason I started > changing some code and decided it could use a real update in the end. > > > Did you know that the sound system eats up to 30% of CPU time, depending > > on hardware? This even with --disable-sound on the command line. > > That's OpenAL version specific. Mine is twice as fast with 256 voices > but 3.5 times more efficient with less than 32 voices. > On linux there are two implementations, the old one (OpenAL Sample Implementation, last version was 0.0.8), which had several issues (including broken Doppler), and the new OpenAL-Soft which most desktop distros are now carrying. Around 1.4 or 1.5 there were a few releases with new features that hadn't been optimised, and that caused the high CPU usage, the situation has improved greatly, Ubuntu is about to release again and therefore Ubuntu users should have a lighter OpenAL-Soft this time around. In any case, OpenAL should be using no processing if sound is disabled, I will check why this is happening over the weekend (I was unabled to check last night as I had planned). Cheers, Matt D. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On Thu, Sep 24, 2009 at 5:38 PM, Olaf Flebbe wrote: > Erik, > > I would like to see an option to disable sound at all. > > Did you know that the sound system eats up to 30% of CPU time, depending > on hardware? This even with --disable-sound on the command line. > > I found it while profiling fgfs on my eeepc with ubuntu, which is > largely affected because of its low end hardware. > > Enabling OpenAL starts a thread which is constantly eating up CPU > cycles. 30% of CPU. (pulseaudio _is_ disabled BTW) > Which version of OpenAL? There were recently (over a month ago?) some improvements in that respect, still, OpenAL shouldn't be using any processing at all. I'm at work and leaving in a few minutes, so I'll check once I get home. > > [ I was able to improve FPS rate from 1 FPS to 15 FPS with disabling > OpenAL altogether and further quirks. But fgfs still is barely useable > on the eeepc ] > > I would say something about fgfs on the EeePC, but I would like to run it on an N900 as soon as I get my hands on one, so... ;-) Cheers, Matt D. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On Sun, Sep 20, 2009 at 6:23 AM, Erik Hofman wrote: > > > > One other I've remember from looking at the code - for some reason we > > always positioned the listener at (0,0,0), and do a lot of work to > > transform world positions into a listener-relative basis. As I > > understand it, OpenAL can do that itself, i.e we could use a 'world' > > transform for most of the source positions (which would be simpler), > > and pass the FGViewer orientation as the OpenAL listener orientation. > > I *think* at that point the OpenAL and OSG local cartesian systems > > would be in-sync, which might help people generally understanding the > > code! > > True, and I expect it's also the reason why doppler didn't work > correctly (besides that the listener velocity wasn't updated while > OpenAL needs both the listener velocity and the source velocity for > proper calculation of the doppler effect). > There were also some issues with OpenAL 1.0, which were solved by 1.1, I recall sending a patch for this issue a while ago, I never check if it got accepted, etc, since life has been hectic :-) The issue of not setting listener velocity would of course also need addressing (doppler is all about relative velocity!). > What I'm planning on doing is let the SoundManager handle the OpenAL > context suff /and/ the listener properties and let the individual > SampleGroups handle positioning and handling the properties of all > associated samples. > I'm also interested in OpenAL and did a little work on this area, I'm very busy these days but I would like to continue contributing :) Matias D'Ambrosio -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Thu, Sep 3, 2009 at 7:09 PM, Anders Gidenstam wrote: > > > An update on the shallow clone: > git keeps a compressed pack of the data in addition to the working copy. > When cloning the current fgdata git repository from the map server with > depth 1 this overhead adds up to about 1 GB. More overhead than I hoped > for but still less than what one would get with SVN. > > It is possible to create and work on local branches even in a shallow > clone. > Another issue to consider is that of migration tools, I'm guessing CVS->SVN is rather painless, anyone has any idea regarding git and hg? Here is a nice git vs SVN comparison: http://git.or.cz/gitwiki/GitSvnComparsion -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Wed, Sep 2, 2009 at 4:19 PM, Curtis Olson wrote: > On Wed, Sep 2, 2009 at 2:02 PM, Tom P wrote: > >> Hi Curt >> >> My only concern with SVN is that it stores every file twice in the local >> file system, so it's not ideal for the 'data' portion of FlightGear. For >> example, right now a complete checkout of Aircraft is ~ 2 GB, and it would >> double overnight. >> > > A quick check of the 'data' repository reports it's size is about 5Gb. > Presumably with a distributed source code control system, each end user > would be downloading this much data + the disk space foot print would be at > least this much (+ maybe the extra 2Gb for a working copy?) > > Is this an argument to stay with CVS for the data portion of the project? > When using a distributed system it's not necessary to download the entire history, it's just fine to download just the last revision and work from there. In any case, I would bet Hg is more space efficient than CVS. > This is a good point to bring up though in advance. The default project > quota at code.google.com (is there a shorter abbreviation?) is 1Gb so we'd > be fine for SimGear and FlightGear code, but we'd blow way over that for > data. > I'm not sure how well Hg can handle binary data, it might be a good idea to keep that elsewhere anyway for other reasons. All current SCCM allow for separate servers for different parts. Matias D'Ambrosio -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Wed, Sep 2, 2009 at 4:02 PM, Tom P wrote: > Hi Curt > > My only concern with SVN is that it stores every file twice in the local > file system, so it's not ideal for the 'data' portion of FlightGear. For > example, right now a complete checkout of Aircraft is ~ 2 GB, and it would > double overnight. > > I know, disk space is cheap in these days, but the double-write also > results in slower checkouts. > In other words, I think we should import FlightGear as well into > code.google.com and see if we are happy with the performance before > jumping. > > Apart from this concern, I've used CVS, SVN and GIT and I'm not religious > about the choice. > In the end, any tool will work as long as it's: > - fast > - easy to use > - well integrated with other tools like bug tracking SW <- and this > is very important IMHO > (you have bugs referring to check-ins, check-ins referring to bugs, RSS > feeds of changes, etc ...) > I've used a few as well, though not Mercurial (the other available system on Google Code). I'm partial to git, and if mercurial is similar (which I believe it is), it's a lot more robust than SVN. It might make sense to go directly to Mercurial (maybe going through SVN, then Mercurial, if the tools are better for that). Even if the distriguted aspect were not an issue (I believe it is!), SVN is lacking in some aspects. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] include TTF with GPL compatible license into base package?
On Fri, Aug 28, 2009 at 6:25 PM, Torsten Dreyer wrote: > Hi > > with the new osgText feature we can place arbitray text in the scenegraph. > For > that, font files are required. Not many fonts around are compatible with > GPL. > One that is - or seems to be - is "Bitstream Vera": > http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/ > I think it's a very clean and usable font family to be used with FlightGear > and I'd like to include it in the base package under data/Fonts. > > What do you think? http://en.wikipedia.org/wiki/Liberation_fonts That one is GPL and very nice. I haven't seen bitstream vera, so I won't comment on it :-) Matias D'Ambrosio -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SGIntersect.hxx / GCC question - disable multi-line comment warnings
On Sunday 21 June 2009 19:30:32 James Turner wrote: > On 20 Jun 2009, at 12:12, Mathias Fröhlich wrote: > > Better with that added spaces past the '\' ? > > Sadly it made no difference - I already tried that fix locally. Use a multi-line comment. /* and */, then the warning goes away. It can be opened and closed in the same line, of course. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OpenAL in SimGear - pause patch
Sorry for not replying to my previous email, I think gmail is not showing it
(or it was lost somewhere else...).
This is a quick patch to have pause and resume working on alsoft and any
other implementation. I just finished and haven't even tried to compile it,
it's late and I have to install quite a few packages to be able to do it, so
I'll try to test it tomorrow, sorry :-)
The most obvious issue with this patch is that now the bool member of
SGSoundSample called 'playing' is true whether it's paused or not. I think
it's fine code-wise, but the name might mislead people. Maybe renaming it to
'active' or something similar would make sense.
I tried to maintain the coding style, and used 'cvs diff -u' to generate the
patch. Comments welcome.
Cheers,
Matias D'Ambrosio
Index: simgear/sound/sample_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.cxx,v
retrieving revision 1.33
diff -u -r1.33 sample_openal.cxx
--- simgear/sound/sample_openal.cxx 12 Dec 2008 07:41:44 - 1.33
+++ simgear/sound/sample_openal.cxx 27 May 2009 01:58:30 -
@@ -230,6 +230,21 @@
}
+// pause or unpause the sample
+void SGSoundSample::pause( bool _pause ) {
+if ( playing ) {
+if ( _pause) {
+alSourcePause( source);
+print_openal_error("play (alSourcePause)");
+}
+else {
+alSourcePlay( source );
+print_openal_error("play (alSourcePlay)");
+}
+}
+}
+
+
// stop playing the sample
void SGSoundSample::stop() {
if (playing) {
Index: simgear/sound/sample_openal.hxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.hxx,v
retrieving revision 1.23
diff -u -r1.23 sample_openal.hxx
--- simgear/sound/sample_openal.hxx 23 Oct 2008 18:46:55 - 1.23
+++ simgear/sound/sample_openal.hxx 27 May 2009 01:58:30 -
@@ -151,6 +151,13 @@
void play( bool _loop );
/**
+ * Pause or unpause this sample.
+ *
+ * @param _pause Define whether the sound should be paused or unpaused.
+ */
+void pause( bool _pause = true );
+
+/**
* Stop playing this sample.
*
* @param sched A pointer to the appropriate scheduler.
Index: simgear/sound/soundmgr_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.cxx,v
retrieving revision 1.29
diff -u -r1.29 soundmgr_openal.cxx
--- simgear/sound/soundmgr_openal.cxx 25 Jul 2008 18:35:42 - 1.29
+++ simgear/sound/soundmgr_openal.cxx 27 May 2009 01:58:30 -
@@ -188,7 +188,12 @@
SGSoundMgr::pause ()
{
if (context) {
-alcSuspendContext( context );
+sample_map_iterator sample_current = samples.begin();
+sample_map_iterator sample_end = samples.end();
+for ( ; sample_current != sample_end; ++sample_current ) {
+SGSoundSample *sample = sample_current->second;
+sample->pause( true );
+}
if ( alGetError() != AL_NO_ERROR) {
SG_LOG( SG_GENERAL, SG_ALERT,
"Oops AL error after soundmgr pause()!" );
@@ -201,7 +206,12 @@
SGSoundMgr::resume ()
{
if (context) {
-alcProcessContext( context );
+sample_map_iterator sample_current = samples.begin();
+sample_map_iterator sample_end = samples.end();
+for ( ; sample_current != sample_end; ++sample_current ) {
+SGSoundSample *sample = sample_current->second;
+sample->pause( false );
+}
if ( alGetError() != AL_NO_ERROR) {
SG_LOG( SG_GENERAL, SG_ALERT,
"Oops AL error after soundmgr resume()!" );
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OpenAL in SimGear
Hello all, I have just subscribed to this list, but I did search in the archives for emails regarding OpenAL and the doppler effect in particular. Hopefully I didn't miss any important emails. I have some experience with OpenAL, definitely a lot more than I do with FlightGear and SimGear, so when someone in #flightgear mentioned a lack of doppler possibly dating to changing from the OpenAL SI (0.0.8) to OpenAL Soft (many versions, the one I used as reference here is 1.4.711) I decided to investigate why. So here are a few comments on OpenAL & SimGear: First, the use of alcSuspendContext and alcProcessContext. These two functions are not clearly defined in the OpenAL specification, and the OpenAL SI, OpenAL Soft and Creative differ in the implementation. Here is an email from a Creative Labs person in the OpenAL-devel list: http://opensource.creative.com/pipermail/openal-devel/2008- February/005077.html It is probably best not to use these calls, and interpreting them as "pause" is not a good idea, in particular considering that in OpenAL Soft they are both noops (and I believe, though I'm not certain, that it is also the case for Creative's implementation). A proper way to pause sound would be to call alSourcePause or alSourcePausev for all sources. On the use of AL_VERSION_1_2 to detect a functioning doppler effect... well, there is no OpenAL 1.2 specification. Also, this is a compile time option, the proper thing would be to call alGetString with AL_VERSION as a parameter, the specification says: version string in format “. ” From the 0.0.8 release of the OpenAL SI, one can see that it returns "1.1", which is not quite right... OpenAL Soft 1.4.711 return "1.1 ALSOFT". Both return "OpenAL Community" for AL_VENDOR, and for AL_RENDERER they return "Software" and "OpenAL Soft". So checking AL_VERSION="1.1", AL_VENDOR="OpenAL Community" and AL_RENDERER="Software" should give you confidence that you're using the broken OpenAL SI and you should use the same path as for 1.0. Many distributions are not using 0.0.8 since that was a very old release, but rather are using CVS versions. Even so, the OpenAL SI has long since been deprecated (and it takes a couple of minutes to actually find it these days). While speaking of OpenAL Soft, you might be interested to know that the release version currently used in a few major distros (I know gentoo and debian are using OpenAL Soft, I don't know what other distros use) supports the EFX extension and the reverb effect. The git version also supports the echo effect. I hope this information comes in useful and results in improvements to FlightGear, keep up the good work :-) Matias D'Ambrosio -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
