Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Andy Ross wrote: Hardware mixing is, of course, the best solution, but note also that OpenAL can be built with any of a zillion back ends, among them the various sounds servers (esd, arts) which do their own mixing. In fact they *all* get included and an option in ~/.openalrc can define which one to use: ; Contains user settings for OpenAL ; Goes in ~/.openalrc ; Which backend? Tried in order of appearance (define devices '(native alsa sdl esd arts null)) ; Four speaker surround with ALSA (define speaker-num 4) (define alsa-out-device surround40:0,0) ; Some drivers do not support select (define native-use-select ;t) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Vassilii Khachaturov wrote: I wonder if the openal library, when being paused by simgear as a consequence of the sound mute request, can somehow be made to close the sound device? (I.e., is it possible to have simgear init openal in a different way for this to happen, or does it need a change in openal?) In theory this might be possible, but what would we gain by this? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
I wonder if the openal library, when being paused by simgear as a consequence of the sound mute request, can somehow be made to close the sound device? (I.e., is it possible to have simgear init openal in a different way for this to happen, or does it need a change in openal?) In theory this might be possible, but what would we gain by this? People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Am Thursday 13 October 2005 15:29 schrieb Erik Hofman: Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Oliver Schroeder wrote: Am Thursday 13 October 2005 15:29 schrieb Erik Hofman: Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. I know it's a minor inconvenience if you are on a long flightgear flight and would like to fire up your mp3 player in the background (and find that you can't) but this is going to be a problem for any application that uses sound and I don't really like the idea of overly complicating the flightgear audio code just for this. This isn't a problem on most newer audio hardware which happily knows how to share/mix between multiple audio applications. Personally I think that this problem is outside of the scope of FlightGear and we shouldn't worry about it. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
On Thursday 13 October 2005 14:42, Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. Not as far as I'm aware - with ALSA, one should use /dev/adsp which is nonblocking IIRC, but of course ALSA is only on Linux. No idea what the options are for a cross-platform solution.. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. I think something like this is badly needed - trying to fly with any degree of coordination with other people is practically impossible using any system which involves typing. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Oliver Schroeder wrote: Am Thursday 13 October 2005 15:29 schrieb Erik Hofman: Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. It looks like that isn't such a wise idea: http://opensource.creative.com/pipermail/openal-devel/2004-June/000346.html Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. esd or artsd would allow you to share the device. I suspect you'd need to start the sound daemon, then your comms s/w (which would need to use the device read/write), then flightgear (write only). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
This isn't a problem on most newer audio hardware which happily knows how to share/mix between multiple audio applications. Personally I think that this problem is outside of the scope of FlightGear and we shouldn't worry about it. Curt. Fair enough. I was just hoping for a simple openal-level solution known --- I agree it's not worth deep complications. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
AJ MacLeod wrote: On Thursday 13 October 2005 14:42, Oliver Schroeder wrote: I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. I think something like this is badly needed - trying to fly with any degree of coordination with other people is practically impossible using any system which involves typing. I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. This would allow for one conference channel per 'frequency' in use. On the other end this would require someone to wire a useful VoIP client library into FlightGear - like IAXClient, which is my favourite: http://iaxclient.sourceforge.net/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. This would allow for one conference channel per 'frequency' in use. On the other end this would require someone to wire a useful VoIP client library into FlightGear - like IAXClient, which is my favourite: http://iaxclient.sourceforge.net/ This could be setup as a completely separate application. If FlightGear was running with the telnet interface enabled, the remote audio communication application could easily fetch the currently tuned com frequencies from FlightGear. A separate application would keep the core of Flightgear simpler and wouldn't add additional prerequisites to building/installing FG. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Am Thursday 13 October 2005 16:03 schrieb Curtis L. Olson: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. I hope we don't need to change anything code-wise I know it's a minor inconvenience if you are on a long flightgear flight and would like to fire up your mp3 player in the background (and find that you can't) but this is going to be a problem for any application that uses sound and I don't really like the idea of overly complicating the flightgear audio code just for this. Actually I was thinking about VoiP applications which can be used as real comms. I'm not familiar with multimeadia things and thought /dev/dsp is used directly without any wrapper which then blocks other applications. However, I will try to use some sound daemons. But does it work on all supported plattforms? regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Hi, Jon Stockill schrieb: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. esd or artsd would allow you to share the device. I suspect you'd need to start the sound daemon, then your comms s/w (which would need to use the device read/write), then flightgear (write only). I'm starting FlightGear on Linux as esddsp fgfs which essentially detours access from /dev/dsp to the sound daemon. There is a delay in audio of about 1/2s (try the flaps), but otherwise it's fine. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Am Thursday 13 October 2005 16:33 schrieb Martin Spott: I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. This would allow for one conference channel per 'frequency' in use. On the other end this would require someone to wire a useful VoIP client library into FlightGear - like IAXClient, which is my favourite: which would be a good start. So we have voice ready to use now, even if we currently have to set up frequencies (channels) manually. I was planning (and therefor testing) to use a point-to-point VoiP client, sending data to fg_server, which knows about a players position and can know players frequencies, so it can send VoiP-data to all clients in reach. But, as said, this needs more thoughts and testing. Meanwhile I think, that your approach is more suitable (and usable!) now. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: Martin Spott wrote: I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. [...] This could be setup as a completely separate application. Oh, no - please ! :-)) [...] If FlightGear was running with the telnet interface enabled, the remote audio communication application could easily fetch the currently tuned com frequencies from FlightGear. It's not just about comm _frequencies_, it's not only about automated ATC messages. I'm talking about the ability to transport sim pilot's blather over the net. I heavily object against running this as a separate application after I've seen M$FS pilots running into heavy trouble while connecting multiple add-on applications to their sim. Over the time we'll run into version imcompatibilities and sort of that stuff. This is why I'd prefer to have such an interface built into FlightGear. IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: Oh, no - please ! :-)) It's not just about comm _frequencies_, it's not only about automated ATC messages. I'm talking about the ability to transport sim pilot's blather over the net. I heavily object against running this as a separate application after I've seen M$FS pilots running into heavy trouble while connecting multiple add-on applications to their sim. Over the time we'll run into version imcompatibilities and sort of that stuff. This is why I'd prefer to have such an interface built into FlightGear. IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) The counter argument though is: 1. I'm adverse to adding another somewhat large dependency to FlightGear. 2. FlightGear and MSFS have entirely different interfacing mechanisms. People may have trouble with FlightGear, but I don't think that you can say that trouble with MSFS's external interface mechanism implies similar trouble with FlightGear's ... different trouble, maybe, but not similar trouble. 3. Using the property system minimizes version incompatibility problems since property names don't change all that often. Perhaps I could propose that we start by developing this as a separate application and then if it works really well and there is a strong consensus, we could merge it in with the FlightGear code directly. It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Only 4.5 Mb ... in terms of source code, I don't think I would could call that small. I don't know what this would come out as when it's compressed, but it could easily double the size of the FlightGear source tarball. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient IAX is also NAT friendly (it runs a single udp port at each end, unlike SIP for example). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Oliver Schroeder wrote: Meanwhile I think, that your approach is more suitable (and usable!) now. I would not spent effort into that if I weren't convinced that this approach is very much foresighted. Is there a better solution than using standard OpenSource tools and protocols for such a job !? ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: Perhaps I could propose that we start by developing this as a separate application and then if it works really well and there is a strong consensus, we could merge it in with the FlightGear code directly. Hey, as in most cases your ideas are not that bad ;-)) quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Only 4.5 Mb ... in terms of source code, I don't think I would could call that small. We are intersted only in the lib/ directory, and only in parts of it. For example all sorts of conversion routines could be dropped and the focus set to one or two codecs only. Additionally everything that has to do with video stuff would be dropped and the Microsoft Developer Studio Project files don't count either :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Just my $0.02 John W. Curtis L. Olson wrote: Martin Spott wrote: Oh, no - please ! :-)) It's not just about comm _frequencies_, it's not only about automated ATC messages. I'm talking about the ability to transport sim pilot's blather over the net. I heavily object against running this as a separate application after I've seen M$FS pilots running into heavy trouble while connecting multiple add-on applications to their sim. Over the time we'll run into version imcompatibilities and sort of that stuff. This is why I'd prefer to have such an interface built into FlightGear. IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) The counter argument though is: 1. I'm adverse to adding another somewhat large dependency to FlightGear. 2. FlightGear and MSFS have entirely different interfacing mechanisms. People may have trouble with FlightGear, but I don't think that you can say that trouble with MSFS's external interface mechanism implies similar trouble with FlightGear's ... different trouble, maybe, but not similar trouble. 3. Using the property system minimizes version incompatibility problems since property names don't change all that often. Perhaps I could propose that we start by developing this as a separate application and then if it works really well and there is a strong consensus, we could merge it in with the FlightGear code directly. It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Only 4.5 Mb ... in terms of source code, I don't think I would could call that small. I don't know what this would come out as when it's compressed, but it could easily double the size of the FlightGear source tarball. Regards, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
John Wojnaroski wrote: Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Here's my take on that. I would think that people would voluntarily setup ATC voip servers on their own hardware. At the moment I don't think there would be resources to setup a dedicated FG ATC voip server, but if we get a system that works well and it made sense to centralize it, we could discuss that. So in terms of people setting up servers, I would suspect that some servers would be managed more professionally than others. If a particluar server degenerates into a voip 'chat' room and the server maintainer doesn't care, then so be it. But I would assume that at least a few voip servers would be held to pretty rigorous standards and people abusing the airwaves or not taking the 'game' seriously could be booted off and sent to a less serious server. I think this could be controlled pretty well with social/cultural pressure, especially if there was some ultimate enforcement mechanism (which might be as simple as adding an entry to a /etc/hosts.deny file on the server if someone persists in breaking the rules ...) or perhaps we need a virtual airforce with guns and missles to keep the airwaves pristine ... :-) Back to serioiusness, I think since most FlightGear participants are not active licensed pilots, there would be some need for flexibility and education on the proper procedures ... just like in real life, but obviously without real lives directly at stake so we can afford to allow more mistakes and more active learning. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
On Thursday 13 October 2005 18:11, Curtis L. Olson wrote: Back to serioiusness, I think since most FlightGear participants are not active licensed pilots, there would be some need for flexibility and education on the proper procedures ... just like in real life, but obviously without real lives directly at stake so we can afford to allow more mistakes and more active learning. Phew, a sense of proportion, and much more coherent than my intended reply :-) Like you say, most FG users are not pilots IRL, and speaking personally, the new MP capability has increased my knowledge and understanding of basic airfield operations in a way that just reading a book could not. I currently know practically _nothing_ about ATC procedures, but if the facility was in place in conjunction with the MP servers, I (and plenty others) would obviously have the chance to learn and practice the basics... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: John Wojnaroski wrote: Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Here's my take on that. I would think that people would voluntarily setup ATC voip servers on their own hardware. At the moment I don't think there would be resources to setup a dedicated FG ATC voip server, but if we get a system that works well and it made sense to centralize it, we could discuss that. So in terms of people setting up servers, I would suspect that some servers would be managed more professionally than others. If a particluar server degenerates into a voip 'chat' room and the server maintainer doesn't care, then so be it. But I would assume that at least a few voip servers would be held to pretty rigorous standards and people abusing the airwaves or not taking the 'game' seriously could be booted off and sent to a less serious server. I think this could be controlled pretty well with social/cultural pressure, especially if there was some ultimate enforcement mechanism (which might be as simple as adding an entry to a /etc/hosts.deny file on the server if someone persists in breaking the rules ...) or perhaps we need a virtual airforce with guns and missles to keep the airwaves pristine ... :-) Back to serioiusness, I think since most FlightGear participants are not active licensed pilots, there would be some need for flexibility and education on the proper procedures ... just like in real life, but obviously without real lives directly at stake so we can afford to allow more mistakes and more active learning. You' re reading my mind :-). It would be a great tool for training and teaching. Some of the MS ATC systems have a mentoring and training program for newbies and I suppose some sort of certification before one is allowed to go live. Again, a lot of work and dedication required Seems the only reason to include such a capability inside FlightGear would be for a centralized controller and a desire to operate in compliance with the appropriate rules. Otherwise let folks set up servers on their own, set the rules for participation, and press go and no need to engage FG. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. I think we should focus on text-based ATC first. With text, it would be much more easier to create an automatic ATC. We can always expand it to include some sort of speech-to-text engine later on. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. The primary purpose of ATC is *separation* of planes. Not navigation assistance, not terrain avoidance, not weather advisories. These are secondary functions. Until we have collision detection between planes, the *need* for ATC is nil --- the planes fly through each other w/o creating a collision hazard :-) With the current pigeon's map in place, even I could play tower and approach occasionally and juggle up to 4 *VFR* planes :-) separation-wise. Incorporating SID/STAR/IAP knowledge would be much more difficult task, but VATSIM et al show that once the framework is in place, a lot of people step forward to help, and there are ways to peer- certify people capable of doing it, as well as tutoring newcomers. There is one caveat: the VATSIM services are not completely free in the FSF sense --- one has to accept some license that allows them to terminate services and has them get one's agreement not to abuse. I wouldn't mind accepting such, but I don;t know if it's OK with the GNU spirit of the Flightgear project. IMO, as long as the software is free, it's fine, but actually logging on to some such network that the FG project endorses could be guarded by smth like the VATSIM approach. I think we should focus on text-based ATC first. With text, it would be much more easier to create an automatic ATC. We can always expand it to include some sort of speech-to-text engine later on. You meant text-to-speech, didn't you? If you are talking about automatic tower/plane comms, then fine. Otherwise, it's pretty useless during actual flying low and slow (i.e. around the airport) since it would require alternating typing with flying. Unless we can include some sort of speech-to-text capabilities :-) V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: So in terms of people setting up servers, I would suspect that some servers would be managed more professionally than others. If a particluar server degenerates into a voip 'chat' room and the server maintainer doesn't care, then so be it. But I would assume that at least a few voip servers would be held to pretty rigorous standards and people abusing the airwaves or not taking the 'game' seriously could be booted off and sent to a less serious server. John Wojnaroski wrote: To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. Well, I'm holding a so called General Flight Radiotelephone Operator's Certificate, which - at least in theory - entitles you to operate the radio from the co-pilot's seat in an airliner. You might expect that I know what I'm talking about when I call this blather :-) I realize very well that we are at risk to see 'misuse' on such a voice channel and I'd suggest to open such a channel to registered users only - as other ATC simulation networks do as well. This doesn't prevent us from offering an 'open' channel, similar to common air-to-air frequencies, as an addition to other 'frequencies' where we expect people to comply with the usual phraseology. My long-term goal would be to erect a network of voice-communication servers among several people around the world. I know that we don't necessarily need voice communication just to transmit some ATC instructions into sim cockpits but on the other hand I think that without such a feature we'll never attract a single person willing to provide 'life' ATC service to FlightGear users. I not only consider this to be a thrilling idea, I happen to see in real life that there are _lots_ of people on the world to run such networks - it's just that they use the 'wrong' sim with proprietary protocols ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Ampere K. Hardraade wrote: Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. The other way 'round nobody would think of playing ATC for FlightGear users as long as the software simply lacks the required features. I know, this could lead into an endless discussion but I think you at least have to admit that there's more than a single valid view on the topic. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: Ampere K. Hardraade wrote: Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. The other way 'round nobody would think of playing ATC for FlightGear users as long as the software simply lacks the required features. I know, this could lead into an endless discussion but I think you at least have to admit that there's more than a single valid view on the topic. There's no harm in someone working on this, especially if it's done as an external app initially. We all have our individual priorities ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Vassilii Khachaturov wrote: There is one caveat: the VATSIM services are not completely free in the FSF sense --- one has to accept some license that allows them to terminate services and has them get one's agreement not to abuse. [...] Well, obviously the network is attractive enough for users to let people agree to these rules. Personally I would not object to setting up such rules: If people want to have a private communication channel, then, why not - everyone is allowed to set up such a voice communication service. If somebody really wishes to practice correct praseology then it's unlikely that he'll object to rules that allow him to actually _get_ that practice. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
On Thursday 13 October 2005 01:13 pm, Ampere K. Hardraade wrote: Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. I think we should focus on text-based ATC first. With text, it would be much more easier to create an automatic ATC. We can always expand it to include some sort of speech-to-text engine later on. This sounds good to me. Voice-ATC in the real world is a dying technology anyway. In a few years it will be gone and replaced by data-link, at least for commercial flying. I do think, however, that plane-2-plane comm at the multiplayer arena is a good idea. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Curtis L. Olson wrote: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. [...] This isn't a problem on most newer audio hardware which happily knows how to share/mix between multiple audio applications. Hardware mixing is, of course, the best solution, but note also that OpenAL can be built with any of a zillion back ends, among them the various sounds servers (esd, arts) which do their own mixing. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
I wonder if the openal library, when being paused by simgear as a consequence of the sound mute request, can somehow be made to close the sound device? (I.e., is it possible to have simgear init openal in a different way for this to happen, or does it need a change in openal?) Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
