Sound and Music

SDL Development
21

Tyler Montbriand wrote:

I had to find out the actual host IP address for one of my projects, faf,
derived from SDL_webserver… the IP address detection currently works under
win, linux, and mac. It’s in it’s own file in the tarball somewhere, maybye
you’ll find it helpful. http://burningsmell.org/faf/

Of course, even that is not useful for anyone behind a NAT who wants
people on the Internet at large to be able to connect. In that case,
it’s not possible to detect the NAT’s IP address without asking an
external server on the Internet. Hence a lot of programs have an
"External IP Address" preference somewhere, which the user has to fill in.

I say this because I suspect the original poster might want to write a
program that is usable in that sort of situation.

-Graue

22

I’d stream from file. You might get a little performance benefit from
having it all in memory but not much, and using excessive amounts of memory
can lead to swapping, which will slow things down a LOT.

Of course, that’s what I’m worrying about. I’ll just keep it as it is then.

If you want to get fancy, you can “map” the file into to memory, to have
the OS automatically load the appropriate bits as needed; but not
everything can do this.

That doesn’t sound very portable?

Thx,
Marian.On Sunday 18 September 2005 06:18, Tyler Montbriand wrote:

–
Hofstadter’s law: “It always takes longer than you think, even when you take
account of Hofstadter’s law”.

23

It’s about as portable as portable gets under UNIXes. mmap originated in BSD
and now almost everything has it. Even Windows has something like it 95 and
CE included. I doubt things like Palm and Playstation support it.

I’ve been toying with making an SDL_mmap library to make it portable-r,
because I think memory mapping is very elegant; you get the simplicity of
loading the whole 50 megs into memory(not even kidding, I’ve seen lots of
things do that) without the huge memory waste. The OS decides which bits
float in memory, and doesn’t have to swap any of it to disk to get rid of it
– it’s already on disk! You can even warn the OS you’re going to use the
memory sequentially, so it doesn’t pollute the cache with stuff that’s only
needed once every music loop.On September 18, 2005 07:12 pm, Marian Schedenig wrote:

If you want to get fancy, you can “map” the file into to memory, to have
the OS automatically load the appropriate bits as needed; but not
everything can do this.

That doesn’t sound very portable?

24

I fully agree, a portable mmap abstraction would be an incredible
addition to SDL. There should be a decent fallback on platforms that
don’t support it though…

  • SROn 9/18/05, Tyler Montbriand wrote:

It’s about as portable as portable gets under UNIXes. mmap originated in BSD
and now almost everything has it. Even Windows has something like it 95 and
CE included. I doubt things like Palm and Playstation support it.

I’ve been toying with making an SDL_mmap library to make it portable-r,
because I think memory mapping is very elegant; you get the simplicity of
loading the whole 50 megs into memory(not even kidding, I’ve seen lots of
things do that) without the huge memory waste. The OS decides which bits
float in memory, and doesn’t have to swap any of it to disk to get rid of it
– it’s already on disk! You can even warn the OS you’re going to use the
memory sequentially, so it doesn’t pollute the cache with stuff that’s only
needed once every music loop.

25

Now there’s a toughie. How does one emulate memory mapping without
actually /doing/ memory mapping? The only sane thing I can think of is using
size-limited, allocated buffers; but that’s no good for writing, and for any
decently sized file, forces people to do all the seek-abstraction they’d be
doing without mmap in the first place.

Worst case, emulated mmap would be slower and waste more memory than plain
file operations. It might end up just being something that’s either
supported or not, like CDROMs and timers. If it ever becomes internal to
SDL, maybye it can be used for optimizations there when present…

Interestingly, while Palm doesn’t support mmap /yet/ afaik, future versions
ought to via a linux kernel. http://www.palmsource.com/opensource/On September 18, 2005 09:56 pm, Simon Roby wrote:

I fully agree, a portable mmap abstraction would be an incredible
addition to SDL. There should be a decent fallback on platforms that
don’t support it though…

  • SR
26

Tyler Montbriand wrote:>On September 18, 2005 09:56 pm, Simon Roby wrote:

I fully agree, a portable mmap abstraction would be an incredible
addition to SDL. There should be a decent fallback on platforms that
don’t support it though…

  • SR

Now there’s a toughie. How does one emulate memory mapping without
actually /doing/ memory mapping? The only sane thing I can think of is using
size-limited, allocated buffers; but that’s no good for writing, and for any
decently sized file, forces people to do all the seek-abstraction they’d be
doing without mmap in the first place.

Worst case, emulated mmap would be slower and waste more memory than plain
file operations. It might end up just being something that’s either
supported or not, like CDROMs and timers. If it ever becomes internal to
SDL, maybye it can be used for optimizations there when present…

Interestingly, while Palm doesn’t support mmap /yet/ afaik, future versions
ought to via a linux kernel. http://www.palmsource.com/opensource/

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

i just want to note that the latest boost library ( www.boost.org ) adds
a set of iostream classes, that include abstraction for memory mapped
files!!!

"Boost.Iostreams has three aims:
To make it easy to create standard C++ streams and stream buffers for
accessing new Sources and Sinks.
To provide a framework for defining Filters and attaching them to
standard streams and stream buffers.
To provide a collection of ready-to-use Filters, Sources and Sinks.

For example, Boost.Iostreams can be used to create streams to access TCP
connections or as a framework for cryptography and data compression. The
library includes components for accessing

!!! memory-mapped files, !!!

for file access using operating system file descriptors, for code
conversion, for text filtering with regular expressions, for line-ending
conversion and for compression and decompression in the zlib, gzip and
bzip2 formats."

http://www.boost.org/libs/iostreams/doc/classes/mapped_file.html
"The classes mapped_file_source, mapped_file_sink and mapped_file
provide access to memory-mapped files on Windows and POSIX systems. "

27

boost.org looks like a very nice operating system, but I prefer linux. ;p

Seriously, I’m glad there’s people trying to make iostreams less of a joke,
but if all you want is a silly memory buffer, iostreams are overkill*10^23.
They also make porting hell, there still exist systems that don’t support
them. They’re also not easily applicable to SDL, which has it’s own stream
types in pure C.

Here’s SDL_mmap 0.1: http://burningsmell.org/SDL_mmap/
No fallback emulation as of yet.On September 19, 2005 02:23 pm, Andre Krause wrote:

i just want to note that the latest boost library ( www.boost.org ) adds
a set of iostream classes, that include abstraction for memory mapped
files!!!

28

Sounds promising, thanks! Linux, Windows and (when I get a chance to try one)
Mac are my primary targets. For now I’ll leave my HD streaming code, but I’ll
probably try and include this at one point.

What license is this going to be? Your site doesn’t mention it ( || I’m
blind :).

Marian.On Tuesday 20 September 2005 02:12, Tyler Montbriand wrote:

Here’s SDL_mmap 0.1: http://burningsmell.org/SDL_mmap/
No fallback emulation as of yet.

–
http://www.msched.no-ip.org/

Hofstadter’s law: “It always takes longer than you think, even when you take
account of Hofstadter’s law”.

29

Oops. It’s LGPL.On September 20, 2005 12:18 pm, Marian Schedenig wrote:

What license is this going to be? Your site doesn’t mention it ( || I’m
blind :).

30

FMOD is a really nice x-platform sound API, and Ex has added a C++
interface that is pretty darn nice. Certainly fits more nicely into my
code.

Not to refuel this debate, but I had to rip FMOD out of Lugaru right
before shipping because it was having a bad time with ALSA users, and
for a game that was only going to sell a handful of Linux copies, we
weren’t interested in paying for the source-access licensing (especially
when we’d be paying to fix someone else’s bugs at the last minute).

We put OpenAL in there instead; complete replacement took less than a day.

Frankly, there isn’t much I like about FMOD after that experience. FMOD
Ex sounds nicer, but I’m genuinely hoping that we’ll soon be thinking
about paying for audio libraries the way we think about paying for web
browsers.

–ryan.

31

I’ve heard similar things from other people. Just recently I wrote a
c++ class which abstracts much of openal and adds streaming from ogg
vorbis files, urls (ogg), and icecast streams. While FMOD may claim to
be the fastest audio API (which I’ve yet to see any real data to back
up), the implementation I’ve built is nearly as stable, more compatible
across Windows/Linux (from my and others experiences) and didn’t cost a
penny to implement. I don’t plan on adding mp3 support to the library
for a few reasons: 1) mp3 licensing is expensive 2) mp3s have a stigma
associated with them now as being the pirates chosen audio format 3)
most listener tests confirm ogg as having better audio clarity at higher
bitrates and better compression at lower bitrates (this isn’t MY
opinion, but that by many people including the hydrogenaudio guys) I
have been communicating with the icecast guys to make sure the class is
fully compatible with icecast. I’ve noticed no speed differences
between OpenAL (using my library) and FMOD EX. (Not that is noticable
without extensive testing with specialized equipment)
I plan on adding speex and FLAC support as well (without using a library
such as fishsound). Where am I going with this? Why pay for Fmod (5000
copies of a game or application is exceeded QUITE easily, especially
when you distribute via the internet.) when there are viable
alternatives which have actually proven themselves in commercial
games/applications? Like Ryan, I’m not trying to start a debate. I
just want to point out that the majority of the benefits that you pay
for in FMOD are available in OpenAL.

Ryan C. Gordon wrote:>>FMOD is a really nice x-platform sound API, and Ex has added a C++

interface that is pretty darn nice. Certainly fits more nicely into my
code.

Not to refuel this debate, but I had to rip FMOD out of Lugaru right
before shipping because it was having a bad time with ALSA users, and
for a game that was only going to sell a handful of Linux copies, we
weren’t interested in paying for the source-access licensing (especially
when we’d be paying to fix someone else’s bugs at the last minute).

We put OpenAL in there instead; complete replacement took less than a day.

Frankly, there isn’t much I like about FMOD after that experience. FMOD
Ex sounds nicer, but I’m genuinely hoping that we’ll soon be thinking
about paying for audio libraries the way we think about paying for web
browsers.

–ryan.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

32

do you plan to release your c++ wrapper it to the open source community?
i’m especially interested in the streaming code to stream ogg files. in
conjunction woth boost::iostreams (
http://www.boost.org/libs/iostreams/doc/index.html ) this would allow to
stream ogg files directly out of an archive / resource file…

Elden Armbrust wrote:> I’ve heard similar things from other people. Just recently I wrote a

c++ class which abstracts much of openal and adds streaming from ogg
vorbis files, urls (ogg), and icecast streams. While FMOD may claim
to be the fastest audio API (which I’ve yet to see any real data to
back up), the implementation I’ve built is nearly as stable, more
compatible across Windows/Linux (from my and others experiences) and
didn’t cost a penny to implement. I don’t plan on adding mp3 support
to the library for a few reasons: 1) mp3 licensing is expensive 2)
mp3s have a stigma associated with them now as being the pirates
chosen audio format 3) most listener tests confirm ogg as having
better audio clarity at higher bitrates and better compression at
lower bitrates (this isn’t MY opinion, but that by many people
including the hydrogenaudio guys) I have been communicating with the
icecast guys to make sure the class is fully compatible with icecast.
I’ve noticed no speed differences between OpenAL (using my library)
and FMOD EX. (Not that is noticable without extensive testing with
specialized equipment)
I plan on adding speex and FLAC support as well (without using a
library such as fishsound). Where am I going with this? Why pay for
Fmod (5000 copies of a game or application is exceeded QUITE easily,
especially when you distribute via the internet.) when there are
viable alternatives which have actually proven themselves in
commercial games/applications? Like Ryan, I’m not trying to start a
debate. I just want to point out that the majority of the benefits
that you pay for in FMOD are available in OpenAL.

Ryan C. Gordon wrote:

FMOD is a really nice x-platform sound API, and Ex has added a C++
interface that is pretty darn nice. Certainly fits more nicely into my
code.

Not to refuel this debate, but I had to rip FMOD out of Lugaru right
before shipping because it was having a bad time with ALSA users, and
for a game that was only going to sell a handful of Linux copies, we
weren’t interested in paying for the source-access licensing (especially
when we’d be paying to fix someone else’s bugs at the last minute).

We put OpenAL in there instead; complete replacement took less than a
day.

Frankly, there isn’t much I like about FMOD after that experience. FMOD
Ex sounds nicer, but I’m genuinely hoping that we’ll soon be thinking
about paying for audio libraries the way we think about paying for web
browsers.

–ryan.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

33

Actually, I’ve been contemplating porting the whole thing over to SDL,
using pointers to FILE and TCPSocket pointers to read the data from
files and network locations respectively. Once I finish up with this
project (it’s a work related project, and thus can’t be (L)GPL sadly) I
plan on basically using similar techniques to write a streaming media
library specifically for SDL. Obviously, like this project, I won’t
personally be including anything related to mp3. That is why we have
CVS/SVN servers and fantastic contributors. :slight_smile: And yes, before the
question is even raised, if I do get to do it, it will definitely be
LGPL like the rest of SDL.
I will definitely be doing it in c, however, for SDL. Though knowing
me, it will likely be pretty easy to abstract into some sort of c++
class. :slight_smile:

-Elden

Andre Krause wrote:> do you plan to release your c++ wrapper it to the open source

community? i’m especially interested in the streaming code to stream
ogg files. in conjunction woth boost::iostreams (
http://www.boost.org/libs/iostreams/doc/index.html ) this would allow
to stream ogg files directly out of an archive / resource file…

Elden Armbrust wrote:

I’ve heard similar things from other people. Just recently I wrote a
c++ class which abstracts much of openal and adds streaming from ogg
vorbis files, urls (ogg), and icecast streams. While FMOD may claim
to be the fastest audio API (which I’ve yet to see any real data to
back up), the implementation I’ve built is nearly as stable, more
compatible across Windows/Linux (from my and others experiences) and
didn’t cost a penny to implement. I don’t plan on adding mp3 support
to the library for a few reasons: 1) mp3 licensing is expensive 2)
mp3s have a stigma associated with them now as being the pirates
chosen audio format 3) most listener tests confirm ogg as having
better audio clarity at higher bitrates and better compression at
lower bitrates (this isn’t MY opinion, but that by many people
including the hydrogenaudio guys) I have been communicating with the
icecast guys to make sure the class is fully compatible with
icecast. I’ve noticed no speed differences between OpenAL (using my
library) and FMOD EX. (Not that is noticable without extensive
testing with specialized equipment)
I plan on adding speex and FLAC support as well (without using a
library such as fishsound). Where am I going with this? Why pay for
Fmod (5000 copies of a game or application is exceeded QUITE easily,
especially when you distribute via the internet.) when there are
viable alternatives which have actually proven themselves in
commercial games/applications? Like Ryan, I’m not trying to start a
debate. I just want to point out that the majority of the benefits
that you pay for in FMOD are available in OpenAL.

Ryan C. Gordon wrote:

FMOD is a really nice x-platform sound API, and Ex has added a C++
interface that is pretty darn nice. Certainly fits more nicely into my
code.

Not to refuel this debate, but I had to rip FMOD out of Lugaru right
before shipping because it was having a bad time with ALSA users, and
for a game that was only going to sell a handful of Linux copies, we
weren’t interested in paying for the source-access licensing
(especially
when we’d be paying to fix someone else’s bugs at the last minute).

We put OpenAL in there instead; complete replacement took less than
a day.

Frankly, there isn’t much I like about FMOD after that experience. FMOD
Ex sounds nicer, but I’m genuinely hoping that we’ll soon be thinking
about paying for audio libraries the way we think about paying for web
browsers.

–ryan.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl