With SDL you can write Games for MAC Classic, MAC OS X, IRIX. You all know that :=)
What Audio Quality does a Mac and an IRIX have ??? CD Quality 16Bit/44100Hz/Stereo or more
or less ???
CU
Torsten Giebl wrote:
With SDL you can write Games for MAC Classic, MAC OS X, IRIX. You all know that :=)
What Audio Quality does a Mac and an IRIX have ??? CD Quality 16Bit/44100Hz/Stereo or more
or less ???
Related question:
Audio support in SDL appears to imply multi-threaded
programming (unless I have misinterpreted the documentation,
which is possible), but also, threads don’t seem to be
supported on the Mac (?). If you can do audio on the Mac,
both statements can’t be true can they?
Anyway, I’m still working on a game engine design and
haven’t really determined whether or not threading is
required. Right now the inclusion of audio seems to
imply threads, so there’s no reason to avoid them, and
there are some advantages to running the video blitting
in a separate thread from the game logic. However, I’d
prefer not to lose the Mac platform – so I’m not sure
what that requires of my design.
Any suggestions or pointers would be appreciated!
Thanks–
Terry Hancock
@Terry_Hancock
Torsten Giebl wrote:
With SDL you can write Games for MAC Classic, MAC OS X, IRIX. You all
know that :=)
What Audio Quality does a Mac and an IRIX have ??? CD Quality
16Bit/44100Hz/Stereo or more
or less ???
?ll PowerPC-based Macs have 16bit/44khz/Stereo capable audio output. The
CDROM drive is usually configured to play through the sound chip too.
Related question:
Audio support in SDL appears to imply multi-threaded
programming (unless I have misinterpreted the documentation,
which is possible), but also, threads don’t seem to be
supported on the Mac (?). If you can do audio on the Mac,
both statements can’t be true can they?
This is true. The MacOS implementation uses an interrupt-based
mechanism. When the hardware needs more audio data, your program is
interrupted until you get the buffers filled up (not executing
concurrently, like a thread)
I believe the other OS’s use a semaphore-type mechanism in a thread to
block the thread until more audio is needed.
Rather than being thread-safe, the interrupt you specify in the MacOS
implementation has to be Interrupt Safe. There are not very many
functions that are interrupt safe currently. malloc(), free(), and
printf() are commonly used here unknowingly and cause a hard crash (as
do many of the non-compatible functions).
Your best bet for portability is to avoid any system calls in the
interrupt.
For efficiency, you want to make the work you do in the interrupt as
small as possible, as I said, interrupts completely take over the
machine, usually suspending all I/O until they are finished. You can do
less work in the interrupt by, for example, setting aside some time in
your game loop to do more expensive audio operations (3D effects, etc).
If you want more info on MacOS audio, I suggest you check out
The “asynchronous sound” tutorial at www.idevgames.com. I know you won’t
be writing any Mac-specific code, but this should give you a better
picture of how thing work.
Anyway, I’m still working on a game engine design and
haven’t really determined whether or not threading is
required. Right now the inclusion of audio seems to
imply threads, so there’s no reason to avoid them, and
there are some advantages to running the video blitting
in a separate thread from the game logic. However, I’d
prefer not to lose the Mac platform – so I’m not sure
what that requires of my design.Any suggestions or pointers would be appreciated!
Thanks
Terry Hancock
hancock at earthlink.net
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: text/enriched
Size: 2755 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010402/5b4b5485/attachment.binOn Monday, April 2, 2001, at 08:55 PM, Terry Hancock wrote:
[…]
Your best bet for portability is to avoid any system calls in the
interrupt.
IMHO, that’s the best bet, period.
(Missed deadlines in a audio callback or thread come out as very audible
drop-outs, so stay away from non-deterministic calls; basically all system
calls on normal platforms…)
For efficiency, you want to make the work you do in the interrupt as
small as possible, as I said, interrupts completely take over the
machine, usually suspending all I/O until they are finished. You can do
less work in the interrupt by, for example, setting aside some time in
your game loop to do more expensive audio operations (3D effects, etc).
I don’t know how Mac OS beaves if you stay too long in an interrupt, but on
other platforms in general, you’ll have to abuse the system to get "reliable"
low latency audio.
Whether that’s nice or not is another issue. One could claim that you should
just use a real time OS if you want low latency audio. OTOH, as long as the
only desktop OS that even gets close without modifications is BeOS, one has
to figure out how to get the job done - dreaming does not produce code.
//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 Tuesday 03 April 2001 03:13, Darrell Walisser wrote: