Re: [Flightgear-devel] FlightGear Sound System redux
Erik Hofman wrote: Most of the work to transition to the new sound system has been done now and the patch size starts toe exceed the comfort level for most so I'm going to commit the current result somewhere today. I'm going to take this back, I discovered a problem that needs more investigation. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Most of the work to transition to the new sound system has been done now and the patch size starts toe exceed the comfort level for most so I'm going to commit the current result somewhere today. The code is not completely finished yet but it will allow others to look at it and add small updates at a time while working on the same code repository. When I commit it I will also provide a short developer description of the internals. Right now I'm going to look at the diff for obvious errors. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
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. 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. Greetings Olaf -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 Sat, Sep 26, 2009 at 11:29 AM, Olaf Flebbe f...@oflebbe.de 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Matias D'Ambrosio wrote: This is almost certainly a bug in fgfs or PulseAudio. Yeah, no use in hunting this down until I've got the new sound system ready. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
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. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 e...@ehofman.com 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Matias D'Ambrosio wrote: 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. I was talking about my own written version of OpenAL compared to a relatively recent version of OpenAL-Soft. The Sample implementation is 3 times slower all the way (except for very specific cases). -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
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) [ 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 ] Greetings, Olaf -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 f...@oflebbe.de 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Hi, 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. The version from ubuntu jaunty is 1.4.272 Olaf -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
While reworking the sound system I started to wonder about the ATC chatter and such (like beacons and morse code). Should these be tied to the main aircraft (and hence fade away when the aircraft gets further away) or should these be audible no matter what? Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 22/09/09 20:22, Erik Hofman wrote: While reworking the sound system I started to wonder about the ATC chatter and such (like beacons and morse code). Should these be tied to the main aircraft (and hence fade away when the aircraft gets further away) or should these be audible no matter what? Personally. I do not want to hear inside sounds while outside the aircraft. I mean, you wouldn't hear he radio or beacons etc in real life if you were looking at the aircraft fly past you. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 22 Sep 2009, at 09:28, James Sleeman wrote: While reworking the sound system I started to wonder about the ATC chatter and such (like beacons and morse code). Should these be tied to the main aircraft (and hence fade away when the aircraft gets further away) or should these be audible no matter what? Personally. I do not want to hear inside sounds while outside the aircraft. I mean, you wouldn't hear he radio or beacons etc in real life if you were looking at the aircraft fly past you. I suspect this should be a pref - either the local cockpit sounds are associated with the aircraft model (realistic operation) or they are associated with the view position (unrealistic but useful if you like switching to an outside view but don't want to miss a bit of ATC or an alert) Regards, James -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
James Turner wrote: I suspect this should be a pref - either the local cockpit sounds are associated with the aircraft model (realistic operation) or they are associated with the view position (unrealistic but useful if you like switching to an outside view but don't want to miss a bit of ATC or an alert) Why was I already suspecting it would end up like this? :) Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 22 Sep 2009, at 10:10, Erik Hofman wrote: Why was I already suspecting it would end up like this? :) Well, putting on my Apple user-interface hat, adding a pref is always a thing to be cautious about - much better to make the software smart (since the user is dumb!) and do the 'right thing'. But I think this is genuinely a case where a pref might make sense. If one was doing voice ATC via another program (FGCom, etc), clearly that wouldn't be affected by changing views at all. Regards, James -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
James Turner wrote: I suspect this should be a pref - either the local cockpit sounds are associated with the aircraft model (realistic operation) or they are associated with the view position (unrealistic but useful if you like switching to an outside view but don't want to miss a bit of ATC or an alert) On 09/22/09 02:10, Erik Hofman wrote: Why was I already suspecting it would end up like this? :) Let's discuss the realistic options first, and then see to what extent we can and/or should implement unrealistic options. 1) If you are inside the cockpit and have the NAV radio tuned up, you should be able to hear Morse code IDENT signals. Similarly if you have the Tower frequency tuned up, you should be able to hear chatter appropriate to that frequency. If you have the Approach frequency tuned up, you should hear chatter appropriate to that frequency. 2) If you are standing outside the aircraft, the engine sound will be 20 or 30 dB louder, while the radio sounds will be 20 or 30 or 40 dB quieter, i.e. completely inaudible. 3) If you are in the Tower, partaking of the Tower View you should hear chatter appropriate to the Tower frequency. It is verrry unlikely that Tower has any approach frequencies or navaid frequencies tuned up. If the Tower job is divided into multiple sectors, as it generally is at large busy fields, that introduces additional complexity. There are ways of dealing with this, which we can discuss later if anybody is interested. 4a) If you are in a chase plane, partaking of the Chase View, you might hear chatter appropriate to whatever frequencies are tuned up on the chase plane's radios ... not the chased plane's radios. 4b) However, it would not be unreasonable to posit that the chase plane would have tuned up the same frequencies as the chased plane. Call it a coincidence if you wish, but not a completely unreasonable coincidence. Note that in this scenario, and indeed all of the scenarios considered here, the radio sounds do not exhibit any Doppler shift, since the observers are always stationary relative to the relevant radio receiver, even if they are not stationary relative to the aircraft we are observing. 4c) If somebody wants to flesh out the chase plane to the point where it has its own radios, distinct from the chased plane's radios, that's fine with me ... but it might be a whole lot of work for relatively little value to typical users. I reckon this should be rather low on the priority list. == Just saying let it be a preference available in unrealistic mode is not a panacea. For starters, there are infinitely more unrealistic behaviors than there are realistic behaviors, so deciding what to implement is sure to be hard, and then implementing it is likely to be hard also. Furthermore, it raises all sorts of user-interface issues, since it is not even obvious how the user could _express_ such preferences in any natural way. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Good idea's John, I'll try to think about it when going further. It might need adjustment after the first commit but I'll try to make it easy. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 Tue, 2009-09-22 at 20:28 +1200, James Sleeman wrote: On 22/09/09 20:22, Erik Hofman wrote: While reworking the sound system I started to wonder about the ATC chatter and such (like beacons and morse code). Should these be tied to the main aircraft (and hence fade away when the aircraft gets further away) or should these be audible no matter what? Personally. I do not want to hear inside sounds while outside the aircraft. I mean, you wouldn't hear he radio or beacons etc in real life if you were looking at the aircraft fly past you. By this argument, we should lock the control inputs, too, because you can't control the aircraft if you are outside. I would like to hear all the cockpit sounds in exterior views because I am still sitting in the cockpit. My rudder pedals are under my feet, my throttle quadrant is at my knee, and the stick is in my hand. I am still flying the aircraft so it is important to hear the common cockpit sounds. Markers, radio calls, etc. Thanks, Ron -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 09/22/09 08:03, Ron Jensen wrote: I would like to hear all the cockpit sounds in exterior views because I am still sitting in the cockpit. My rudder pedals are under my feet, my throttle quadrant is at my knee, and the stick is in my hand. I am still flying the aircraft so it is important to hear the common cockpit sounds. Markers, radio calls, etc. 1) By that argument, there should be no Doppler effects -- or distance effects, or azimuth effects -- in any view, including flyby view, Tower view, et cetera. That would greatly simplify the audio code! 2) The counterargument is that maybe you are sitting somewhere, flying the plane via remote control. There are lots of RC pilots in the world, including in the FGFS user community. And even some in the USAF. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 Tue, Sep 22, 2009 at 10:24 AM, John Denker wrote: On 09/22/09 08:03, Ron Jensen wrote: I would like to hear all the cockpit sounds in exterior views because I am still sitting in the cockpit. My rudder pedals are under my feet, my throttle quadrant is at my knee, and the stick is in my hand. I am still flying the aircraft so it is important to hear the common cockpit sounds. Markers, radio calls, etc. 1) By that argument, there should be no Doppler effects -- or distance effects, or azimuth effects -- in any view, including flyby view, Tower view, et cetera. That would greatly simplify the audio code! 2) The counterargument is that maybe you are sitting somewhere, flying the plane via remote control. There are lots of RC pilots in the world, including in the FGFS user community. And even some in the USAF. The thing to remember here is that this is a virtual experience ... a simulation. We can do things in the simulation that cannot be done in real life. We can experience the simulation from perspectives that are not available in real life. In many ways, this is the power of simulation and visualization. When practicing IFR approaches in a simulator, you don't have to fly back to the start each time. You can reposition yourself instantaneously and fly many more practice approaches in the simulator than you could in real life within that same time period. So we need to be careful about justifying decisions based solely on realism or non-realism. We can spend the rest of our lives presenting examples and counter examples if we look at the issues from only that level. We need to be asking not only what is realistic or not realistic, but what makes sense? What would users possibly want to be able to do? And what would the most common usage or default configuration be? I love having our various external views available when I'm replaying real flight data. Sure, some of these perspectives would be *very* hard to recreate in real life, but they are a very useful tool for visualization and validating that the aircraft looks like it is flying right, or looks like it is flying the same way it flew in real life. If you are primarily acting as a pilot of an aircraft, how much of the external world can you actually hear over the sound of your own engines? How much time does a typical user spend in the simulator with the engines off? I would say this is not a high priority for a flight simulator based solely on a realism argument. But in a simulator I (and I imagine many others) spend a lot of time viewing our airplane from the outside. In that case having the sound system perform in a way that makes sense for an external view is nice. Sure, from a realism perspective I would die quickly after I saw my 747 flying at 45,000 from the outside. That's not a view I really would be excited to see in real life. At that point, I'm probably not paying attention to Doppler effects and if I can hear the cockpit audio or not, and I probably wouldn't hear any of that anyway over the sound of my own ears exploding. So keep in mind that a simulator offers unique features and unique abilities not available in real life. When we diverge from what's possible in reality, the best we can do is offer something that makes sense and fits within the flow of what's going on. If we can't agree on exactly what that is, making the behavior configurable with a reasonable default is often a good option. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Hi, I would like to hear all the cockpit sounds in exterior views because I am still sitting in the cockpit. My rudder pedals are under my feet, my throttle quadrant is at my knee, and the stick is in my hand. I am still flying the aircraft so it is important to hear the common cockpit sounds. Markers, radio calls, etc. 1) By that argument, there should be no Doppler effects -- or distance effects, or azimuth effects -- in any view, including flyby view, Tower view, et cetera. That would greatly simplify the audio code! 2) The counterargument is that maybe you are sitting somewhere, flying the plane via remote control. There are lots of RC pilots in the world, including in the FGFS user community. And even some in the USAF. I must admit that I want not hear usually any sounds from cockpit outside. When making videos and showing them the most critic was about the fact that you can hear the aircrafts noise like the callouts even 1000m awayThat made FGFs looks a bit funny! On the other side I can understand Ron that in many situations it would be very needful to hear them outside. And right, this is a sim, but it doesn't mean we have to make it all like in realitity. We don't have to forget that our sim is used in may ways, so we need many ways to simulate things. Maybe again a switch with whitch the user can decide if he wants to hear the sound outside or not would be helpful. cheers HHS -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
I'd prefer not to hear cockpit sounds from exterior views myself , so it would be nice if there was a way to enable/disable them . Would be nice too, if engine volumes would really go to 0 from exterior views . Cheers -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Maybe a bit of a tangent question about the sound but.. The scenario in mind for xmas is a couple of new proper PC's (multiscreen) set up with FG, so two kids in different parts of the house are concerting. In the meantime there can be some ATC presence from some laptop in the garden shed as its raining. This is the FlightGear-Fun verison, unlike maybe FlightGear-Cat3. So the scenario in this situation is communications between the two child pilots who can interactivelyy chat to each other live. Crash into each other,, umm? So the muppet noise/verbosity questions are: Would that audio forwarding be in flight gear? Probably Not we can do that over the LAN with a voice server, eg asterix Can an external socket fire off events within the audio framework? ? probably Can the plane do a proper flaps noise, that very low hertz noise ? NO cos its below 40hz and therby sub_sonic ie you ears sense it but dont feel pete -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
James Turner wrote: Excellent news. My biggest two requests would be to get the sound code out of main.cxx, and proper support for positional sources - i.e AI or MP traffic. Being able to position sounds on the airframe would be good too - engine and gear noises especialy. Tom P wrote: When switching to an external view like the tower, the same channel is used for both, and the sound pitch is scaled to account for the Doppler effect. The effect is not realistic, you hear a high-pitch version of the warning messages from a mile away. Both will be adressed. The problem Tom describes has something to do with improper doppler effect and a nasty way to fix it. I Think I've found why doppler didn't work properly in the first place. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Hi John, John Denker wrote: That's a good thing to work on. Thanks for the heads-up. Here's one more thing to think about in this context: text to speech. AFAICT the status is: 1) The existing home-brew TTS system (involving ATC/default.vce and ATC/default.wav) is very limited. It does not claim to handle the general case. It does not even have enough vocabulary to handle an ICAO standard ATIS (with perhaps verrry rare exeptions). It only knows the names of a few airports. 2) There is a documented interface to the Festival TTS system. Alas, the preponderance of the evidence indicates this has not worked in several years. AFAICT all reports of working TTS refer to the home-brew system (item 1 above). I have no opinion on _how_ to implement TTS, whether home-brew, Festival, or other. For the sake of simplicity (or actually avoiding extra complexity) this will have to wait until after the update which shouldn't be a real problem since it only uses the sound infrastructure but is no part of it. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Hi Durk, Durk Talsma wrote: That sounds pretty awesome. (Sorry for the lame pun). :-) :) Seriously, though, since you mention that this is something you're working on for the longer term, do you think this planned update should be included in the new release (planned beta release around FSWeekend), or do you want to schedule this for a later inclusion? I'm not by any means trying to push you, I'm just trying to get a bit of an idea what new developments we might expect in the next few weeks/months. Much of it is moving code around but I can't predict if it may cause nasty bugs that have to be hunted down. I hope to get it finished as soon as possible though. If it gets delayed it might be a good idea to hold it off for inclusion after the event. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 20 Sep 2009, at 08:18, Erik Hofman wrote: Both will be adressed. The problem Tom describes has something to do with improper doppler effect and a nasty way to fix it. I Think I've found why doppler didn't work properly in the first place. That's fantastic news! Let me know if I can help at all. One thing I thing I would strongly suggest on the FG side, would be to ensure the SG side uses Mathias' excellent basic types (SGVec3d/f, SGQuatd, etc) to express positions, vectors and orientations to the code. The SG layer itself could then manage converting to OpenAL co-ordinates and types (which are usually just ALfloat*, I know). My impression is that this would make *all* the client code much smaller, simpler, and less prone to 'which co-ordinate system am I in?' confusion. Regards, James -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
James Turner wrote: Let me know if I can help at all. One thing I thing I would strongly suggest on the FG side, would be to ensure the SG side uses Mathias' excellent basic types (SGVec3d/f, SGQuatd, etc) to express positions, vectors and orientations to the code. The SG layer itself could then manage converting to OpenAL co-ordinates and types (which are usually just ALfloat*, I know). I might need some help to understand quads, but I am converting it to SGVec3f where ever possible. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 20 Sep 2009, at 09:25, Erik Hofman wrote: I might need some help to understand quads, but I am converting it to SGVec3f where ever possible. No problem, I'm sure Mathias / Tim / myself can oblige. 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! I do recall some story, that there was a problem with giving the OpenAL listener a non-default position, but I've totally forgotten the origin of that story, whether it applied to a specific OpenAL version/ platform, or whatever. Or maybe I imagined it. Regards, James -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
James Turner wrote: On 20 Sep 2009, at 09:25, Erik Hofman wrote: I might need some help to understand quads, but I am converting it to SGVec3f where ever possible. No problem, I'm sure Mathias / Tim / myself can oblige. Thanks! 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). 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 do recall some story, that there was a problem with giving the OpenAL listener a non-default position, but I've totally forgotten the origin of that story, whether it applied to a specific OpenAL version/ platform, or whatever. Or maybe I imagined it. It might have been a long time ago but it doesn't ring a bell for me. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 e...@ehofman.com 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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 20 Sep 2009, at 10:23, Erik Hofman wrote: 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). 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. Sounds great to me - should make MP much more exciting, as well as engine starting / failures. Regards, James -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Hi Erik One issue I've noticed with the current system is that all sounds are played on the same channel. Let me give an example: On the Beechcraft B1900D, sound inside the cabin is engine noise + warning messages (1000 ft, 500 ft, excessive banking, etc..). When switching to an external view like the tower, the same channel is used for both, and the sound pitch is scaled to account for the Doppler effect. The effect is not realistic, you hear a high-pitch version of the warning messages from a mile away. I was wondering if this can be kept into account during the rework. Thanks Tom On Sat, Sep 19, 2009 at 6:13 AM, Erik Hofman e...@ehofman.com wrote: Hi, This is a heads up that I'm working on improving the sound system quite a bit with a few new concepts in mind. Right now the FX class is the heart of the audio system while the SoundManager is loosely tied between the samples and the FX class. In the future the Sound Manager will be the heart of the system and a SGSampleGroup class is introduced that holds all sounds for a particular model. The FX class will be derived from it and Samples will need to be register to one of the SampleGroup classes. Instead of using the SoundManager in the future subsystems will have to deal with the new (and privately held but registered) SampleGroup class instead. (It still can create new Samples at will) Another advantage of this approach is that all updates to the OpenAL state will be inside the update() function of the SoundManager which should make subtle differences due to interdependencies (almost) impossible. The update will be quite large but the result would be that AI models also would be able to generate sound effects (if all goes well). I do not yet have a time frame when it will be committed but I wanted it to be known in advance. Erik -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 09/19/09 06:13, Erik Hofman wrote: This is a heads up that I'm working on improving the sound system quite a bit with a few new concepts in mind. That's a good thing to work on. Thanks for the heads-up. Here's one more thing to think about in this context: text to speech. AFAICT the status is: 1) The existing home-brew TTS system (involving ATC/default.vce and ATC/default.wav) is very limited. It does not claim to handle the general case. It does not even have enough vocabulary to handle an ICAO standard ATIS (with perhaps verrry rare exeptions). It only knows the names of a few airports. 2) There is a documented interface to the Festival TTS system. Alas, the preponderance of the evidence indicates this has not worked in several years. AFAICT all reports of working TTS refer to the home-brew system (item 1 above). I have no opinion on _how_ to implement TTS, whether home-brew, Festival, or other. However, _some_ sort of robust TTS would be extremely valuable. (If this is not obvious, I would be happy to discuss _why_ it is valuable.) -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 Sat, 19 Sep 2009, John Denker wrote: 2) There is a documented interface to the Festival TTS system. Alas, the preponderance of the evidence indicates this has not worked in several years. AFAICT all reports of working TTS refer to the home-brew system (item 1 above). Using Festival from FlightGear works very well for various types of text messages, mainly from the MP and auto-ATC subsystems (and aircraft specific systems). See Docs/README.voice.html for setup information. If ATIS also used the that system I think we'd be home. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Hi Erik, On Saturday 19 September 2009 03:13:21 pm Erik Hofman wrote: Hi, This is a heads up that I'm working on improving the sound system quite a bit with a few new concepts in mind. That sounds pretty awesome. (Sorry for the lame pun). :-) Seriously, though, since you mention that this is something you're working on for the longer term, do you think this planned update should be included in the new release (planned beta release around FSWeekend), or do you want to schedule this for a later inclusion? I'm not by any means trying to push you, I'm just trying to get a bit of an idea what new developments we might expect in the next few weeks/months. cheers, Durk -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
