Hi everyone !
I just wanted to ask, whether there are any plans to implement audio input?
Related to this question are the other questions:
Would be happy to here from you all…
Regards,
Sascha G?nther wrote:
Hi everyone !
I just wanted to ask, whether there are any plans to implement audio input?
I would also like this feature. I’d be willing to write OSS input code,
if others could handle the other platforms.
-John–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software
You know, even tho I am such a minimalist (I usually knock down most other
feature suggestions 
I do think this would be a very neat feature.
I am certain it would tricky to impliment on all platforms… but a
cross-platform way of doing this would be /extremely/ nice.On Sat, 24 Mar 2001, you wrote:
Hi everyone !
I just wanted to ask, whether there are any plans to implement audio input?
Related to this question are the other questions:
- does anyone think this could be needed in some way ?
- does it make sense to implement it in the libSDL ?
- is anyone actually working on such a thing ?
- are there already plans to implement it (maybe in 1.3 ?)
Would be happy to here from you all…
–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >
I just wanted to ask, whether there are any plans to implement audio input?
- are there already plans to implement it (maybe in 1.3 ?)
Yes, it’s on the SDL 1.3 TODO list.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I am certain it would tricky to impliment on all platforms… but a
cross-platform way of doing this would be /extremely/ nice.
On one hand, since SDL is already handling some audio output stuff, it would
be natural for SDL to handle audio input stuff especially if a lot of code
could be shared. (I could see some scenarios where games accept voice
commands or SDL being used for videoconferencing) On the other, people
without a full-duplex sound device could only use one way at a time, so they
might as well have seperate libraries.
I guess it all depends on how many people have full- versus half-duplex
sound devices.
Olivier A. Dagenais - Software Architect and Developer
The next question is: if audio input is allowed, what about video input?
I see audio input as part and parcel of game-oriented multimedia.
However, video input is a broad enough topic that it’s outside the scope
of SDL. There are some very nice open projects devoted entirely to video
capture.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
The next question is: if audio input is allowed, what about video
input?
I see audio input as part and parcel of game-oriented multimedia.
Olivier A. Dagenais - Software Architect and Developer
I always though a score table that allowed you to record a sound instead
of a name would be kinda cool:)
There are also things like Voice Over Ip and other 21st century
advancements.On Sat, Mar 24, 2001 at 10:18:35AM -0800, Olivier Dagenais wrote:
Although I have heard of software that translates voice commands to
keystrokes, it was made independent of any game and acted more like an OS
hook. I don’t remember seeing any game, however, that directly captured
audio. (ok, so I haven’t seen ALL games, so there may be some out there that
do this…)
Bother! said Pooh, as he quietly hid Piglet’s body away.
Speaking of which, an SDL_capture library for video input would be kind of
neat. Basically a bridge between V4L (a very straightforward interface, btw,
I was surprised) and whatever Windows uses for the same.
-JohnOn Saturday 24 March 2001 13:00, you wrote:
The next question is: if audio input is allowed, what about video input?
I see audio input as part and parcel of game-oriented multimedia.
However, video input is a broad enough topic that it’s outside the scope
of SDL. There are some very nice open projects devoted entirely to video
capture.
–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software
I see audio input as part and parcel of game-oriented multimedia.
Yeah, thats right, but put it in an external lib. I think the word “Simple” in "Simple Directmedia Layer"
is very important. Keep it as “Simple” as it could be. Keyboard input and mouse input you need every-
day but not AUDIO Input.
“John R. Hall” schrieb im Newsbeitrag news:01032413580400.20643 at quark…> On Saturday 24 March 2001 13:00, you wrote:
The next question is: if audio input is allowed, what about video input?
I see audio input as part and parcel of game-oriented multimedia.
However, video input is a broad enough topic that it’s outside the scope
of SDL. There are some very nice open projects devoted entirely to video
capture.Speaking of which, an SDL_capture library for video input would be kind of
neat. Basically a bridge between V4L (a very straightforward interface, btw,
I was surprised) and whatever Windows uses for the same.-John
–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software
Audio input is a driver function. Its not something you can cleanly put
in an external lib because it may depend on information thats only
available internally to the SDL audio drivers.On Sat, Mar 24, 2001 at 11:41:00AM -0800, Torsten Giebl wrote:
I see audio input as part and parcel of game-oriented multimedia.
Yeah, thats right, but put it in an external lib. I think the word “Simple” in "Simple Directmedia Layer"
is very important. Keep it as “Simple” as it could be. Keyboard input and mouse input you need every-
day but not AUDIO Input.“John R. Hall” schrieb im Newsbeitrag news:01032413580400.20643 at quark…
On Saturday 24 March 2001 13:00, you wrote:
The next question is: if audio input is allowed, what about video input?
I see audio input as part and parcel of game-oriented multimedia.
However, video input is a broad enough topic that it’s outside the scope
of SDL. There are some very nice open projects devoted entirely to video
capture.Speaking of which, an SDL_capture library for video input would be kind of
neat. Basically a bridge between V4L (a very straightforward interface, btw,
I was surprised) and whatever Windows uses for the same.-John
–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software
Bother! said Pooh, as Winn started foaming at the mouth.
Yeah, thats right, but put it in an external lib. I think the word
"Simple" in “Simple Directmedia Layer” is very important. Keep it as
"Simple" as it could be. Keyboard input and mouse input you need every-
day but not AUDIO Input.
Well, I do not agree at this point. As we all see, software gains more
interactivity, by giving the user different options to do his input. I could
think of AUDIO input in many situations, e.g. voice controll (as one of the
most complex), just voice over net (as a medium-comlicated) and voice-input
for (like mentioned in this list before) a players name.
This means, the AUDIO-Input functions SDL provides should be as basic, as
its video functions. And this brings me to the point, what i intended to ask
in the questions, with wich I opened this thread:
This Audio-Input could be based on a structure, such as SDL_AudioStream.
This structure keeps some basic audio-data and information about volume and
the audio-curve. The developer decides, when to open the stream and when to
close it (so no problems with duplex, etc… for sure we need a
SDL_AudioHardwareInfo here, so the developer can decide, what to do).
By giving the reading of the stream an own thread, for example, the
developer can decide about the number of audio-information per secound
(maybe the timing becomes a problem here), he himself decides about sample
rate and stuff. The same could be (in my oppinion) done with
SDL_VideoStream: The developer is enabled to catch a still-video-image from
any video input device as a sdl-surface, not more, not less.
Everything “over” those described functions was not intended with my
questions. So just enable the developer to “easy-access” audio-data, not
handle that data for him. No compression, decompression functions should be
in this, no handling at all, just the basic information a “tune” has at a
time: it’s frequency and it’s volume.
Regards,
Sascha
I am certain it would tricky to impliment on all platforms… but
a cross-platform way of doing this would be /extremely/ nice.On one hand, since SDL is already handling some audio output stuff,
it would be natural for SDL to handle audio input stuff especially
if a lot of code could be shared. (I could see some scenarios
where games accept voice commands or SDL being used for
videoconferencing) On the other, people without a full-duplex
sound device could only use one way at a time, so they might as
well have seperate libraries.I guess it all depends on how many people have full- versus
half-duplex sound devices.
All PCI sound cards I know of support full duplex properly, as well
as a great deal of the ISA based cards. In fact, it’s only the
SoundBlaster Pro, 8 and 16 chipsets, and some of the clones that
can’t do full duplex - and even the later ones do it, although with
poor quality in one direction. (Older ones screw up the input, while
AWE64 cards wreck the output instead, which is preferable in some
cases.)
OTOH, there are lots of these crap SB16 and clones around… 
The next question is: if audio input is allowed, what about video
input? (although one could argue that video capture can be made
totally independent from video output, hence it should only go in a
seperate library)
That’s a bit different generally, I think. Most video input solutions
are completely independent of the video output hardware (often even
when both are placed on the same card), whereas the vast majority of
full duplex audio solutions use a single chip for both, and input is
usually synchronized with output. Many audio APIs don’t even support
input and output being used independently unless you have multiple
sound cards, and in some cases, not even then.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Saturday 24 March 2001 18:26, Olivier Dagenais wrote:
Sorry, but it’s not possible to do that on all platforms. It’s the
rule rather than the exception, that audio input and output must be
handled in a very cooperative fashion. If it’s not enforced by the
API, it’s enforced by the poor real time multithreading capabilities
of all existing platforms, possibly with the exception of BeOS,
Linux/lowlatency and some high end multimedia Unix variants.
It would probably be possible to use an external library for audio
input and output, replacing SDL audio entirely, but I don’t think
that makes sense.
Besides, if you already have audio output, input is usually rather
trivial to implement. (I know it is for OSS, ALSA and Win32 MME, and
IIRC, it’s rather easy with DirectSound as well.)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Saturday 24 March 2001 20:41, Torsten Giebl wrote:
I see audio input as part and parcel of game-oriented multimedia.
Yeah, thats right, but put it in an external lib. I think the word
"Simple" in “Simple Directmedia Layer” is very important. Keep it
as “Simple” as it could be. Keyboard input and mouse input you need
every- day but not AUDIO Input.
It would probably be possible to use an external library for audio
input and output, replacing SDL audio entirely, but I don’t think
that makes sense.
Olivier A. Dagenais - Software Architect and Developer
Audio input is a very basic function of almost every bit of sound
hardware there is. Its more common than hardware blitting and hardware
alpha blending in graphics drivers. Hell, I bet there are more PC’s
in the world with soundcards and drivers that support audio input than
there are with mouse wheels. There are certainly a lot more than there
are joysticks with trackballs (The only known one in existance is in
Sam’s office). Audio input has been common place since 1989 when the
original Sound Blaster card was released and has been common place
since. And you think it doesn’t belong in SDL? Remember SDL is not a
Game API, its not a Graphics API, its a Media API.
Anyway, this is all irrelevant, its on the TODO list.
I’m just ranting to let off steam.On Sun, Mar 25, 2001 at 02:06:33PM -0800, Olivier Dagenais wrote:
It would probably be possible to use an external library for audio
input and output, replacing SDL audio entirely, but I don’t think
that makes sense.Yes, yes it does: you don’t need to initialize the SDL soundsystem and
access to a sound device is not a requirement for accessing a video device.–
Olivier A. Dagenais - Software Architect and Developer
Bother! said Pooh, as yet another condom ruptured.
since. And you think it doesn’t belong in SDL? Remember SDL is not a
Game API, its not a Graphics API, its a Media API.
Yes! 
I’d like to briefly throw my vote in to support audio input!
-bill!
(crawling back under his 200-mesg-inbox)
Sascha G?nther wrote:
Well, I do not agree at this point. As we all see, software gains more
interactivity, by giving the user different options to do his input. I could
think of AUDIO input in many situations, e.g. voice controll (as one of the
most complex), just voice over net (as a medium-comlicated) and voice-input
for (like mentioned in this list before) a players name.This means, the AUDIO-Input functions SDL provides should be as basic, as
its video functions. And this brings me to the point, what i intended to ask
in the questions, with wich I opened this thread:This Audio-Input could be based on a structure, such as SDL_AudioStream.
This structure keeps some basic audio-data and information about volume and
the audio-curve. The developer decides, when to open the stream and when to
close it (so no problems with duplex, etc… for sure we need a
SDL_AudioHardwareInfo here, so the developer can decide, what to do).
It just occured to me that you might like to have an "Audio Trigger"
event –
i.e. that you can set a volume to trigger an SDL event. That would be
like a voice-activated mike. It’d be very handy for a voice-command
system,
and would seem to fit into the SDL API reasonably well. Voice events
could
be interpreted by application code just like keyboard events etc. The
callback function would probably have to go and get the buffered audio
input datastream. You could also use this threshhold to determine when
audio
should be recorded to the buffer.
Just an idea.–
Terry Hancock
@Terry_Hancock
Right, but why reimplement all of what’s in SDL already in an
external library, just to add a minor feature? Or are you suggesting
to split audio entirely from the main SDL library…?
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 26 March 2001 00:06, Olivier Dagenais wrote:
It would probably be possible to use an external library for
audio input and output, replacing SDL audio entirely, but I
don’t think that makes sense.Yes, yes it does: you don’t need to initialize the SDL soundsystem
and access to a sound device is not a requirement for accessing a
video device.
Oisin Mulvihill wrote:
you could go a step further. I don’t know if you’ve
done much dsp, its also been a while since I did dsp,
but you could recognise a set of simple sounds. This
could be achieved by using an FIR (finite impulse
response) or IIR (infinte impulse response) filter
and train it to recognise a simple set of tones/sounds,
dum beat, whistle, etc. There could be more to it
then that, however as I mentioned earlier, its been a
while. It would be an interesting project alright.
Maybe someone out there with more experience in this,
could correct my errors/give a little more info about
it.
Surely, though, that’s separate enough to take out of SDL –
it ought to go into an SDL_Voice lib or something: The
main thing is, once you have the chunk of audio data you
are no longer hardware dependent and you don’t have
hardware acceleration of any kind. At that point you’re
just doing DSP on the data, so it’s separable from SDL.
That’s also desireable, because although you talk about
very simple voice recognition, someone is unquestionably
going to want more, so the voice features will creep
over time to include more and more. Better to keep it
separate now, I would think – then there’s no reason
why it shouldn’t grow.
Given the “simple core + add ons” strategy of SDL so far,
that sounds like the right approach. IMHO this is like
vector graphics primitives with respect to video –
SDL doesn’t do them, but you can use SGE or some other
SDL-based library to do them.–
Terry Hancock
@Terry_Hancock