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
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
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
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
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
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
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
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,
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
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
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
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
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
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
14 matches
Mail list logo
