From torbjorn.e.andersson at tietoenator.com  Mon Oct  1 02:41:18 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Mon, 01 Oct 2001 08:41:18 +0200
Subject: MIDI support (was: Autoconf working yet?)
References: <Pine.LNX.4.33.0109301318001.23403-100000@gemini.verizon.net>
Message-ID: <3BB8100E.6090908@tietoenator.com>

Ryan C. Gordon wrote:

 > Either we will embed the classic Timidity source in SDL_sound, or
 > we'll have to send patches to the Timidity++ folks that seperate out
 > the functionality we need into a shared library, AND get permission to
 > link against SDL_sound/get them to relicense the library parts as
 > LGPL.

I can think of another option, but it's extremely UNIX-centric: Fork off 
a process that runs TiMidity[++] with stdin and stdout as input and 
output respectively. Connect two pipes to said stdin and stdout and use 
them for communication between the two processes.

I have a rough, proof-of-concept version of this, but it doesn't quite 
work yet. I think it's ignoring the sample frequency I tell it to use, 
but I don't know why. Is this approach worth pursuing?

Torbj?rn Andersson



From torbjorn.e.andersson at tietoenator.com  Mon Oct  1 02:54:33 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Mon, 01 Oct 2001 08:54:33 +0200
Subject: Small memory-leak in MOD decoder
Message-ID: <3BB81329.8020105@tietoenator.com>

It looks like I've put a small memory-leak in the MOD decoder. In 
MOD_close() I only call Player_Free(m->module), I never call free(m).

Ryan, I assume you've been busy elsewhere lately (working for money 
again, eh? ;-), but could you please make that change when you get the time?

(Ideally I'd also like to see the libtool and "test for MP3-ness" 
patches discussed in the past few days applied. I can't even build 
SDL_sound unless I use rev 1.1 of acinclude.m4 instead of 1.2, which 
makes it look as if we're in much worse shape than we really are.)

Torbj?rn Andersson



From icculus at clutteredmind.org  Mon Oct  1 05:05:12 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 1 Oct 2001 05:05:12 -0400 (EDT)
Subject: MIDI support (was: Autoconf working yet?)
In-Reply-To: <3BB8100E.6090908@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0110010459030.25209-100000@gemini.verizon.net>


> I have a rough, proof-of-concept version of this, but it doesn't quite
> work yet. I think it's ignoring the sample frequency I tell it to use,
> but I don't know why. Is this approach worth pursuing?

Actually? Yes, but not specific to Timidity.

If we're going to fork off and read from a pipe, we might as well make it
generic enough to read from any process that's willing to send waveform
data over stdio...sox comes to mind here.

I think SDL_mixer does something like this (the music_cmd file?) but I'm
not sure. Still, it's not a bad idea to have, Timidity or otherwise.

In reality, it's a flexible little hack, but it has drawbacks. First, you
can't say you support MIDI decoding when in fact the Timidity binary is
magically missing from the system. The way around this is the init()
method in the DecoderFunctions, but that's awkward. Second, if we make it
a general read-from-another-process "decoder", how do we specify what file
formats are supported, when it might be any number of things? How do we
tell this general interface where to read from and what binary to run?

These are not impossible questions, but they will need answers.

Ultimately, I'd like the MIDI support to be built in, or be optionally
compiled in to call a MIDI specific API (timidity or otherwise), but
again, I like the idea of having a generic read-from-another-process
decoder module.

Let's talk about this some more.

--ryan.




From icculus at clutteredmind.org  Mon Oct  1 05:20:36 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 1 Oct 2001 05:20:36 -0400 (EDT)
Subject: Small memory-leak in MOD decoder
In-Reply-To: <3BB81329.8020105@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0110010505500.25209-100000@gemini.verizon.net>


> It looks like I've put a small memory-leak in the MOD decoder. In
> MOD_close() I only call Player_Free(m->module), I never call free(m).

It's fixed in CVS now.

> Ryan, I assume you've been busy elsewhere lately (working for money
> again, eh? ;-), but could you please make that change when you get the time?

Working for free at this moment.  :)  I just made the change.

> (Ideally I'd also like to see the libtool and "test for MP3-ness"
> patches discussed in the past few days applied. I can't even build
> SDL_sound unless I use rev 1.1 of acinclude.m4 instead of 1.2, which
> makes it look as if we're in much worse shape than we really are.)

I'll look at the MP3 thing in the morning. I'm leaving the autoconf
details to Max, since (honestly) autoconf scares the hell out of me.  :)

Right now I'm trying to get a Shorten (.shn) decoder implemented for
SDL_sound. Sam is giving me write access to SDL_mixer in the near future,
which is darned good motivation to get SDL_sound prepared.

SDL_sound is actually in good shape, feature-wise. The things that are
lacking are on the near horizon (such as MIDI support, etc). What should
really become a priority for us is making sure the library is portable to
various platforms. Max's work on the build system is going to be 9/10ths
of that battle (and I can't thank him enough for doing such a thankless
job!)...the other sliver of work will be cleaning out portability
assumptions, and, harder, finding a means to try this. I don't have a
Windows or BeOS or Solaris box handy, and I don't have a recent compiler
for MacOS classic...however, I have built SDL_sound on PowerPC Linux, and
it DOES seem to be byte-order clean, which is good news.

In short, Max will handle the initial ugliness, and then we need to find
systems (or volunteers with systems) to get SDL_sound working on their
exotic platforms. After those minor patches are in place, whoever is brave
can help me tackle the SDL_mixer work.

There are other things that can be done with SDL_sound, too. Besides the
fact that there are other decoders to be written, no API is worth jack
without applications using it. I'd like to see a XMMS input plugin as a
proof of concept for this (and I see an API extension needed there...the
ability to seek in a sound file if possible). XMMS certainly has input
plugins for everything that SDL_sound currently does, but like I said,
proof of concept. Another thing that might be interesting would be a sound
converter; you decode something through SDL_sound, and then this program
can spit the sound out in another format...hmm...sounds like sox. At any
rate, there's other applications for SDL_sound, although SDL_mixer is the
real beneficiary here.

We have tons to do still, but I think we're doing well, and (by my
calculation) we're actually a little ahead of schedule at the moment.  :)

--ryan.




From torbjorn.e.andersson at tietoenator.com  Mon Oct  1 06:24:58 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Mon, 01 Oct 2001 12:24:58 +0200
Subject: MIDI support (was: Autoconf working yet?)
References: <Pine.LNX.4.33.0110010459030.25209-100000@gemini.verizon.net>
Message-ID: <3BB8447A.1030401@tietoenator.com>

Ryan C. Gordon wrote:

 > Actually? Yes, but not specific to Timidity.
 >
 > If we're going to fork off and read from a pipe, we might as well make
 > it generic enough to read from any process that's willing to send
 > waveform data over stdio...sox comes to mind here.

[snip]

 > These are not impossible questions, but they will need answers.

Mmmm... Ok, I'll keep working on the TiMidity-specific version because 
that's something I can easily test, and then we can either scrap it or 
cannibalize it for ideas later.

My main problem at the moment is that I don't know how to teach it to 
recognize valid MIDI data before passing it to TiMidity. I'm not sure 
how to handle that. I could look at stderr, but not everything that gets 
written to stderr is an error...

Torbj?rn Andersson



From max at quendi.de  Mon Oct  1 06:42:23 2001
From: max at quendi.de (Max Horn)
Date: Mon, 1 Oct 2001 12:42:23 +0200
Subject: MIDI support (was: Autoconf working yet?)
In-Reply-To: <3BB8447A.1030401@tietoenator.com>
References: <Pine.LNX.4.33.0110010459030.25209-100000@gemini.verizon.net>
 <3BB8447A.1030401@tietoenator.com>
Message-ID: <p05101001b7ddf8d140b6@[217.225.194.211]>

At 12:24 Uhr +0200 01.10.2001, Torbj?rn Andersson wrote:
>Ryan C. Gordon wrote:
>
>>  Actually? Yes, but not specific to Timidity.
>>
>>  If we're going to fork off and read from a pipe, we might as well make
>>  it generic enough to read from any process that's willing to send
>>  waveform data over stdio...sox comes to mind here.
>
>[snip]
>
>>  These are not impossible questions, but they will need answers.
>
>Mmmm... Ok, I'll keep working on the TiMidity-specific version 
>because that's something I can easily test, and then we can either 
>scrap it or cannibalize it for ideas later.
>
>My main problem at the moment is that I don't know how to teach it 
>to recognize valid MIDI data before passing it to TiMidity. I'm not 
>sure how to handle that. I could look at stderr, but not everything 
>that gets written to stderr is an error...


You might want to take a look at exult (hosted at sourceforge); we 
have midi driver there for various systems, including a timidity 
driver that does forking, and a seperate "fork" midi driver that is 
rather generel. There are also two different MIDI native driver, a 
BeOS dirver, one that uses libkmidi, and my MacOQ/QuickTime driver.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From max at quendi.de  Mon Oct  1 07:14:20 2001
From: max at quendi.de (Max Horn)
Date: Mon, 1 Oct 2001 13:14:20 +0200
Subject: Small memory-leak in MOD decoder
In-Reply-To: <Pine.LNX.4.33.0110010505500.25209-100000@gemini.verizon.net>
References: <Pine.LNX.4.33.0110010505500.25209-100000@gemini.verizon.net>
Message-ID: <p05101002b7ddf9395923@[217.225.194.211]>

At 5:20 Uhr -0400 01.10.2001, Ryan C. Gordon wrote:
>  > It looks like I've put a small memory-leak in the MOD decoder. In
>>  MOD_close() I only call Player_Free(m->module), I never call free(m).
>
>It's fixed in CVS now.
>
>>  Ryan, I assume you've been busy elsewhere lately (working for money
>>  again, eh? ;-), but could you please make that change when you get the time?
>
>Working for free at this moment.  :)  I just made the change.
>
>>  (Ideally I'd also like to see the libtool and "test for MP3-ness"
>>  patches discussed in the past few days applied. I can't even build
>>  SDL_sound unless I use rev 1.1 of acinclude.m4 instead of 1.2, which
>>  makes it look as if we're in much worse shape than we really are.)
>
>I'll look at the MP3 thing in the morning. I'm leaving the autoconf
>details to Max, since (honestly) autoconf scares the hell out of me.  :)

If somebody could tell me what we are talking about here, sure, I 
will look at it :) I read the mails about the MP3-ness chaeck, but 
how is this related to libtool ??!? what libtool patch?!?

You mean CVS rev 1.1 vs 1.2 of acinclude.m4, and 1.2 is not working - 
well, it contains libtool.m4. But one could argue whether that is a 
good idea, since we require libtool anyway... I think it is better to 
add a comment regarding this to the readme, and get rid of libtool.m4 
in acinclude - this way both users of 1.3.x and 1.4.x can be happy.


>
>Right now I'm trying to get a Shorten (.shn) decoder implemented for
>SDL_sound. Sam is giving me write access to SDL_mixer in the near future,
>which is darned good motivation to get SDL_sound prepared.
>
>SDL_sound is actually in good shape, feature-wise. The things that are
>lacking are on the near horizon (such as MIDI support, etc). What should
>really become a priority for us is making sure the library is portable to
>various platforms. Max's work on the build system is going to be 9/10ths
>of that battle (and I can't thank him enough for doing such a thankless
>job!)...

Thanks :)

>the other sliver of work will be cleaning out portability
>assumptions, and, harder, finding a means to try this. I don't have a
>Windows or BeOS or Solaris box handy, and I don't have a recent compiler
>for MacOS classic...however, I have built SDL_sound on PowerPC Linux, and
>it DOES seem to be byte-order clean, which is good news.

I could test on classic MacOS eventually, but that will require a 
seperate build system anyway (no autotools etc.)

Anyway, so far I have troubles playing something. MP3's don't work at 
all. WAVE, you told me, has no compression support yet, which is a 
serious problem to me; but OK, I converte an MacOS AIFF (resource 
fork based) to WAVE uncompressed, 22,5 kHz, 16 bit stereo - it 
sounded as if it was played at doubele speed -> no good.

"playsound" (which can be built by issuing "make check", just for the 
records), crashes when pointed to an invallid file (e.g. an empty 
file, or the "bootstrap file from CVS).

MP3 ain't work for me, either, which I found somewhat suprising... hm.



>In short, Max will handle the initial ugliness, and then we need to find
>systems (or volunteers with systems) to get SDL_sound working on their
>exotic platforms. After those minor patches are in place, whoever is brave
>can help me tackle the SDL_mixer work.

Yeah.


>
>There are other things that can be done with SDL_sound, too. Besides the
>fact that there are other decoders to be written, no API is worth jack
>without applications using it. I'd like to see a XMMS input plugin as a
>proof of concept for this (and I see an API extension needed there...the
>ability to seek in a sound file if possible). XMMS certainly has input
>plugins for everything that SDL_sound currently does, but like I said,
>proof of concept. Another thing that might be interesting would be a sound
>converter; you decode something through SDL_sound, and then this program
>can spit the sound out in another format...hmm...sounds like sox. At any
>rate, there's other applications for SDL_sound, although SDL_mixer is the
>real beneficiary here.
>
>We have tons to do still, but I think we're doing well, and (by my
>calculation) we're actually a little ahead of schedule at the moment.  :)



Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From torbjorn.e.andersson at tietoenator.com  Mon Oct  1 07:57:04 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Mon, 01 Oct 2001 13:57:04 +0200
Subject: Small memory-leak in MOD decoder
References: <Pine.LNX.4.33.0110010505500.25209-100000@gemini.verizon.net> <p05101002b7ddf9395923@[217.225.194.211]>
Message-ID: <3BB85A10.4000005@tietoenator.com>

Max Horn wrote:

 > If somebody could tell me what we are talking about here, sure, I will
 > look at it :) I read the mails about the MP3-ness chaeck, but how is
 > this related to libtool ??!? what libtool patch?!?

You're right, they're not related. I was just lumping them together as 
two items that have been discussed but not yet committed to CVS. :-)

 > You mean CVS rev 1.1 vs 1.2 of acinclude.m4, and 1.2 is not working -
 > well, it contains libtool.m4. But one could argue whether that is a
 > good idea, since we require libtool anyway... I think it is better to
 > add a comment regarding this to the readme, and get rid of libtool.m4
 > in acinclude - this way both users of 1.3.x and 1.4.x can be happy.

Or the bootstrap script could be made to construct the appropriate 
acinclude.m4 depending on what "libtool --version" says, I guess. Might 
be overkill though.

Torbj?rn Andersson



From max at quendi.de  Mon Oct  1 09:13:50 2001
From: max at quendi.de (Max Horn)
Date: Mon, 1 Oct 2001 15:13:50 +0200
Subject: Small memory-leak in MOD decoder
In-Reply-To: <3BB85A10.4000005@tietoenator.com>
References: <Pine.LNX.4.33.0110010505500.25209-100000@gemini.verizon.net>
 <p05101002b7ddf9395923@[217.225.194.211]>
 <3BB85A10.4000005@tietoenator.com>
Message-ID: <p05101000b7de1bcf48bd@[217.225.194.211]>

At 13:57 Uhr +0200 01.10.2001, Torbj?rn Andersson wrote:
>Max Horn wrote:
>
>>  If somebody could tell me what we are talking about here, sure, I will
>>  look at it :) I read the mails about the MP3-ness chaeck, but how is
>>  this related to libtool ??!? what libtool patch?!?
>
>You're right, they're not related. I was just lumping them together 
>as two items that have been discussed but not yet committed to CVS. 
>:-)
>
>>  You mean CVS rev 1.1 vs 1.2 of acinclude.m4, and 1.2 is not working -
>>  well, it contains libtool.m4. But one could argue whether that is a
>>  good idea, since we require libtool anyway... I think it is better to
>>  add a comment regarding this to the readme, and get rid of libtool.m4
>>  in acinclude - this way both users of 1.3.x and 1.4.x can be happy.
>
>Or the bootstrap script could be made to construct the appropriate 
>acinclude.m4 depending on what "libtool --version" says, I guess. 
>Might be overkill though.

It would be - because that is exactly what "aclocal" does :)

aclocal scans the configure.in file for all required macros; then it 
looks through acinclude.m4 to satisfy these requirments; finally, it 
searches $prefix/share/aclocal/ for .m4 files that define those 
macros. The resulting set of macros is put into the file aclocal.m4, 
which then is used by the other auto-tools to resolve the macros.

The idea behind having an acinclude.m4 at all is that if somebody has 
OGG not installed at all, he is also missing the vorbis.m4; but then 
the autotools could not handle the vorbis macros. Solution: put those 
into acinclude.m4. Problem: if a new version of the macros is 
substantially changed, you get problems.

This happend for libtool :/

But since libtool is required (whereas ogg is not), we can safely 
leave out our copy of libtool.m4


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From torbjorn.e.andersson at tietoenator.com  Mon Oct  1 12:29:12 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Mon, 01 Oct 2001 18:29:12 +0200
Subject: Small memory-leak in MOD decoder
References: <Pine.LNX.4.33.0110010505500.25209-100000@gemini.verizon.net> <3BB8962A.20702@tietoenator.com>
Message-ID: <3BB899D8.6010002@tietoenator.com>

Ooops, I accidentally sent the mail directly to Ryan instead of to the 
mailing list. Let's try this again...

Ryan C. Gordon wrote:

 > SDL_sound is actually in good shape, feature-wise. The things that are
 > lacking are on the near horizon (such as MIDI support, etc).

[long-term plans snipped for brevity]

At some point we're probably going to need a better frequency converter 
than what SDL currently provides. You said once that it would be 
preferable to have this in SDL rather in SDL_sound, though. I wonder if 
it can be added without breaking backwards compatibility, and what the 
plans for sound are in SDL 1.3...

 > We have tons to do still, but I think we're doing well, and (by my
 > calculation) we're actually a little ahead of schedule at the moment.
 > :)

We have a schedule? Neat! :-)

Torbj?rn Andersson



From max at quendi.de  Mon Oct  1 12:56:00 2001
From: max at quendi.de (Max Horn)
Date: Mon, 1 Oct 2001 18:56:00 +0200
Subject: Small memory-leak in MOD decoder
In-Reply-To: <3BB899D8.6010002@tietoenator.com>
References: <Pine.LNX.4.33.0110010505500.25209-100000@gemini.verizon.net>
 <3BB8962A.20702@tietoenator.com> <3BB899D8.6010002@tietoenator.com>
Message-ID: <p05101005b7de505c99d1@[217.225.193.230]>

At 18:29 Uhr +0200 01.10.2001, Torbj?rn Andersson wrote:
>Ooops, I accidentally sent the mail directly to Ryan instead of to 
>the mailing list. Let's try this again...
>
>Ryan C. Gordon wrote:
>
>>  SDL_sound is actually in good shape, feature-wise. The things that are
>>  lacking are on the near horizon (such as MIDI support, etc).
>
>[long-term plans snipped for brevity]
>
>At some point we're probably going to need a better frequency 
>converter than what SDL currently provides. You said once that it 
>would be preferable to have this in SDL rather in SDL_sound, though. 
>I wonder if it can be added without breaking backwards 
>compatibility, and what the plans for sound are in SDL 1.3...

Actually, *SDL* should get a better frequency converter :) If you 
would write one, a lot of people would be grateful. The current one 
is.... not very good :)


>
>>  We have tons to do still, but I think we're doing well, and (by my
>>  calculation) we're actually a little ahead of schedule at the moment.
>>  :)
>
>We have a schedule? Neat! :-)

Woo-hhoo! Do we have managment, too? And a CEO etc.? :)


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From icculus at clutteredmind.org  Mon Oct  1 13:36:12 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 1 Oct 2001 13:36:12 -0400 (EDT)
Subject: Small memory-leak in MOD decoder
In-Reply-To: <p05101005b7de505c99d1@[217.225.193.230]>
Message-ID: <Pine.LNX.4.33.0110011335410.26012-100000@gemini.verizon.net>


> Woo-hhoo! Do we have managment, too? And a CEO etc.? :)

We're going IPO next week...didn't you get the memo?

--ryan.




From max at quendi.de  Mon Oct  1 13:45:12 2001
From: max at quendi.de (Max Horn)
Date: Mon, 1 Oct 2001 19:45:12 +0200
Subject: Small memory-leak in MOD decoder
In-Reply-To: <Pine.LNX.4.33.0110011335410.26012-100000@gemini.verizon.net>
References: <Pine.LNX.4.33.0110011335410.26012-100000@gemini.verizon.net>
Message-ID: <p05101008b7de5c065599@[217.225.193.230]>

At 13:36 Uhr -0400 01.10.2001, Ryan C. Gordon wrote:
>  > Woo-hhoo! Do we have managment, too? And a CEO etc.? :)
>
>We're going IPO next week...didn't you get the memo?
>

Damn, I *never* get those memos! Something is wrong here, we should 
restructure maybe...


Hmm... I hope we will not do major layoffs in the near future.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From torbjorn.e.andersson at tietoenator.com  Tue Oct  2 13:19:00 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Tue, 02 Oct 2001 19:19:00 +0200
Subject: Another tiny thing about the MOD decoder
Message-ID: <3BB9F704.80409@tietoenator.com>

I noticed that the comment at the beginning of mod.c still refers to 
"the mikmod subdirectory". Since we won't be including SDL_mixer's 
subset of MikMod after all, that part of the comment can safely be 
removed, or at least reworded.

Torbj?rn Andersson



From icculus at clutteredmind.org  Tue Oct  2 13:23:41 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 2 Oct 2001 13:23:41 -0400 (EDT)
Subject: Another tiny thing about the MOD decoder
In-Reply-To: <3BB9F704.80409@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0110021323200.26567-100000@gamehenge.icculus.org>


> I noticed that the comment at the beginning of mod.c still refers to
> "the mikmod subdirectory". Since we won't be including SDL_mixer's
> subset of MikMod after all, that part of the comment can safely be
> removed, or at least reworded.

Fixed in CVS.

--ryan.





From icculus at clutteredmind.org  Tue Oct  2 13:56:13 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 2 Oct 2001 13:56:13 -0400 (EDT)
Subject: Other updates:
Message-ID: <Pine.LNX.4.33L2.0110021355100.27431-100000@gamehenge.icculus.org>


(Better late than never...) I've committed the MP3-ness patch.

Also, I've fixed the crash on "playsound ./bootstrap", etc.

It's in CVS.

--ryan.



From icculus at clutteredmind.org  Tue Oct  2 23:41:59 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 2 Oct 2001 23:41:59 -0400 (EDT)
Subject: Some build stuff...
Message-ID: <Pine.LNX.4.33L2.0110022336110.30755-100000@gamehenge.icculus.org>


Can we get some options in SDL_sound's build system for something like
--enable-debug (or --disable-optimizations) so we can toggle a few things:

  Defining DEBUG and DEBUG_CHATTER for debug builds, and NDEBUG (disables
  assertions) for optimized builds. Optimized builds could probably do
  without the -g option too, but I guess individuals can strip the
  binaries themselves if they are concerned.

  The gcc -O2 flag only used without debugging enabled, since it makes
  stepping in gdb a pain in the arse.

  -Werror if at all possible. I just had a segfault that I would have
  caught at compile time (passed an integer where a pointer should be)
  that I could have caught without a debugger if the warning hadn't
  scrolled off my screen.

Thanks!
--ryan.




From torbjorn.e.andersson at tietoenator.com  Wed Oct  3 02:48:06 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Wed, 03 Oct 2001 08:48:06 +0200
Subject: Prototype "pipe data through external process" decoder
Message-ID: <3BBAB4A6.6040101@tietoenator.com>

Here is the decoder for piping MIDI files through an external TiMidity 
process that I spoke of the other day. As Ryan said then it should be 
rewritten into something more generic, but since I'm out of ideas for 
how to improve it I might as well submit as proof-of-concept now.

Even as a MIDI decoder it leaves some things to be desired, but 
considering how little I know of interprocess communication I'm 
pleasantly surprised I got it to work even this well. (I knew that UNIX 
programming book would come in handy some day...)

Torbj?rn Andersson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: midi.c.gz
Type: application/x-gzip
Size: 2832 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20011003/3338ba47/attachment.gz>

From max at quendi.de  Wed Oct  3 07:39:30 2001
From: max at quendi.de (Max Horn)
Date: Wed, 3 Oct 2001 13:39:30 +0200
Subject: Some build stuff...
In-Reply-To: 
 <Pine.LNX.4.33L2.0110022336110.30755-100000@gamehenge.icculus.org>
References: 
 <Pine.LNX.4.33L2.0110022336110.30755-100000@gamehenge.icculus.org>
Message-ID: <p05101001b7e0a8c8ccbc@[217.225.193.39]>

At 23:41 Uhr -0400 02.10.2001, Ryan C. Gordon wrote:
>Can we get some options in SDL_sound's build system for something like
>--enable-debug (or --disable-optimizations) so we can toggle a few things:
>
>   Defining DEBUG and DEBUG_CHATTER for debug builds, and NDEBUG (disables
>   assertions) for optimized builds. Optimized builds could probably do
>   without the -g option too, but I guess individuals can strip the
>   binaries themselves if they are concerned.

Actually, "make install" should perform the stripping automatically, 
IIRC, with automake/libtool.


>
>   The gcc -O2 flag only used without debugging enabled, since it makes
>   stepping in gdb a pain in the arse.
>
>   -Werror if at all possible. I just had a segfault that I would have
>   caught at compile time (passed an integer where a pointer should be)
>   that I could have caught without a debugger if the warning hadn't
>   scrolled off my screen.


So, I sum this up like this:

* add -Werror (always)
* add a switch --enable-debug, which if given:
   * #define DEBUG 1
   * #undef NDEBUG
   * turn off all optimizations (i.e. -O0)
  else, if this flag is not given, or if --disable-debug is give, then
   * #undef DEBUG
   * #define NDEBUG 1
   * no change to optimization (this will default to -O2 then)


If this is right, I will implement it later today.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From icculus at clutteredmind.org  Wed Oct  3 11:28:47 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 3 Oct 2001 11:28:47 -0400 (EDT)
Subject: Some build stuff...
In-Reply-To: <p05101001b7e0a8c8ccbc@[217.225.193.39]>
Message-ID: <Pine.LNX.4.33.0110031127360.5007-100000@gemini.verizon.net>


> So, I sum this up like this:
>  [...]
> If this is right, I will implement it later today.

That's right...

I should have the shn decoder done today, too, so I can stop wasting my
life on that.  Then I need to juggle SDL_sound and Serious Sam.  :)

--ryan.




From max at quendi.de  Wed Oct  3 11:41:54 2001
From: max at quendi.de (Max Horn)
Date: Wed, 3 Oct 2001 17:41:54 +0200
Subject: Some build stuff...
In-Reply-To: <Pine.LNX.4.33.0110031127360.5007-100000@gemini.verizon.net>
References: <Pine.LNX.4.33.0110031127360.5007-100000@gemini.verizon.net>
Message-ID: <p05101003b7e0e1ed7c41@[217.225.195.27]>

At 11:28 Uhr -0400 03.10.2001, Ryan C. Gordon wrote:
>  > So, I sum this up like this:
>>   [...]
>>  If this is right, I will implement it later today.
>
>That's right...

I already add stuff to CVS; and I also changed the build system to 
use a (generated) config.h file, the compile command lines got quite 
long with all those -DFOOBARBAZ arguments :)

Note that we should check the flags like HAVE_STDLIB_H etc. before 
#including these files. I have not yet attepted to make this switch.


>
>I should have the shn decoder done today, too, so I can stop wasting my
>life on that.  Then I need to juggle SDL_sound and Serious Sam.  :)

:)

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From icculus at clutteredmind.org  Wed Oct  3 14:28:32 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 3 Oct 2001 14:28:32 -0400 (EDT)
Subject: Updates to SDL_sound.
Message-ID: <Pine.LNX.4.33L2.0110031418060.2134-100000@gamehenge.icculus.org>


After hours of tracking down a bogus pointer, we've now got a Shorten
(.SHN) decoder in place, so you can listen to all those bootlegged Phish
and Grateful Dead shows on the 'net.  :)

Max: I changed the decoders to include config.h if needed, since config.h
now handles defining SOUND_SUPPORTS_*, which means the decoders won't
compile unless this header is included; it's a catch 22, y'know...

Let me know if I screwed it up.

--ryan.






From max at quendi.de  Wed Oct  3 14:38:06 2001
From: max at quendi.de (Max Horn)
Date: Wed, 3 Oct 2001 20:38:06 +0200
Subject: Updates to SDL_sound.
In-Reply-To: 
 <Pine.LNX.4.33L2.0110031418060.2134-100000@gamehenge.icculus.org>
References: 
 <Pine.LNX.4.33L2.0110031418060.2134-100000@gamehenge.icculus.org>
Message-ID: <p05101008b7e10b583143@[217.225.195.27]>

At 14:28 Uhr -0400 03.10.2001, Ryan C. Gordon wrote:
>After hours of tracking down a bogus pointer, we've now got a Shorten
>(.SHN) decoder in place, so you can listen to all those bootlegged Phish
>and Grateful Dead shows on the 'net.  :)
>
>Max: I changed the decoders to include config.h if needed, since config.h
>now handles defining SOUND_SUPPORTS_*, which means the decoders won't
>compile unless this header is included; it's a catch 22, y'know...

Erhm, the decoders already #included config.h (unless I forgot to 
commit this) via SDL_sound_internal.h


>Let me know if I screwed it up.

Will check it out :)

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From icculus at clutteredmind.org  Wed Oct  3 15:01:20 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 3 Oct 2001 15:01:20 -0400 (EDT)
Subject: Updates to SDL_sound.
In-Reply-To: <p05101008b7e10b583143@[217.225.195.27]>
Message-ID: <Pine.LNX.4.33L2.0110031500130.2134-100000@gamehenge.icculus.org>

> Erhm, the decoders already #included config.h (unless I forgot to
> commit this) via SDL_sound_internal.h

They do, but the #include SDL_sound_internal.h line is inside the #ifdef
SOUND_SUPPORTS_* check, so the files get discarded before they get to the
SDL_sound_internal.h inclusion.

--ryan.





From max at quendi.de  Wed Oct  3 15:04:51 2001
From: max at quendi.de (Max Horn)
Date: Wed, 3 Oct 2001 21:04:51 +0200
Subject: Updates to SDL_sound.
In-Reply-To: 
 <Pine.LNX.4.33L2.0110031500130.2134-100000@gamehenge.icculus.org>
References: 
 <Pine.LNX.4.33L2.0110031500130.2134-100000@gamehenge.icculus.org>
Message-ID: <p0510100ab7e111bdb0e5@[217.225.195.27]>

At 15:01 Uhr -0400 03.10.2001, Ryan C. Gordon wrote:
>  > Erhm, the decoders already #included config.h (unless I forgot to
>>  commit this) via SDL_sound_internal.h
>
>They do, but the #include SDL_sound_internal.h line is inside the #ifdef
>SOUND_SUPPORTS_* check, so the files get discarded before they get to the
>SDL_sound_internal.h inclusion.

I see... but then why not just move the #include SDL_sound_internal.h 
out of that check?


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From icculus at clutteredmind.org  Wed Oct  3 15:31:50 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 3 Oct 2001 15:31:50 -0400 (EDT)
Subject: Updates to SDL_sound.
In-Reply-To: <p0510100ab7e111bdb0e5@[217.225.195.27]>
Message-ID: <Pine.LNX.4.33L2.0110031528440.6560-100000@gamehenge.icculus.org>


> I see... but then why not just move the #include SDL_sound_internal.h
> out of that check?

I did, initially, but I figured that for simplicity in a file that may
become an empty stub (if SOUND_SUPPORTS_* is not defined), then it would
be best to put as little header spam as possible in there.
SDL_sound_internal.h needs SDL_sound.h to work correctly, and now there's
all sorts of stuff getting declared...I just assumed it's safer to include
the config.h directly, and only include SDL_sound*.h if needed.

But, of course, I'm going to go with your judgement on this; the current
state of CVS (which is easily reversable/changable) was mostly intended to
get things building here.

--ryan.





From max at quendi.de  Wed Oct  3 15:35:28 2001
From: max at quendi.de (Max Horn)
Date: Wed, 3 Oct 2001 21:35:28 +0200
Subject: Updates to SDL_sound.
In-Reply-To: 
 <Pine.LNX.4.33L2.0110031528440.6560-100000@gamehenge.icculus.org>
References: 
 <Pine.LNX.4.33L2.0110031528440.6560-100000@gamehenge.icculus.org>
Message-ID: <p0510100bb7e118e25d95@[217.225.195.27]>

At 15:31 Uhr -0400 03.10.2001, Ryan C. Gordon wrote:
>  > I see... but then why not just move the #include SDL_sound_internal.h
>>  out of that check?
>
>I did, initially, but I figured that for simplicity in a file that may
>become an empty stub (if SOUND_SUPPORTS_* is not defined), then it would
>be best to put as little header spam as possible in there.
>SDL_sound_internal.h needs SDL_sound.h to work correctly, and now there's
>all sorts of stuff getting declared...I just assumed it's safer to include
>the config.h directly, and only include SDL_sound*.h if needed.
>
>But, of course, I'm going to go with your judgement on this; the current
>state of CVS (which is easily reversable/changable) was mostly intended to
>get things building here.

I am happy with the current state, no problem. Just make sure nobody 
forgets to #include config.h if appropriate :)


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From icculus at clutteredmind.org  Wed Oct  3 16:18:11 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 3 Oct 2001 16:18:11 -0400 (EDT)
Subject: ...the midi decoder...
Message-ID: <Pine.LNX.4.33L2.0110031617490.7047-100000@gamehenge.icculus.org>


...is now in CVS.

--ryan.





From max at quendi.de  Wed Oct  3 19:19:34 2001
From: max at quendi.de (Max Horn)
Date: Thu, 4 Oct 2001 01:19:34 +0200
Subject: WAVE playback bad
Message-ID: <p05101001b7e1498f40f1@[217.225.195.27]>

I have a wave file that is not playing properly for me using 
SDL_sounds's playsound. It sounds as if it was played at double speed 
or so (i.e. shorter than with other players, and higher pitch).


You can download it from http://dev.quendi.de/Arabian.wav


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From icculus at clutteredmind.org  Wed Oct  3 21:09:21 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 3 Oct 2001 21:09:21 -0400 (EDT)
Subject: WAVE playback bad
In-Reply-To: <p05101001b7e1498f40f1@[217.225.195.27]>
Message-ID: <Pine.LNX.4.33L2.0110032059320.9685-100000@gamehenge.icculus.org>


> I have a wave file that is not playing properly for me using
> SDL_sounds's playsound. It sounds as if it was played at double speed
> or so (i.e. shorter than with other players, and higher pitch).

Hhm. The problem is twofold.

First, playsound forces a sample rate of 44100. Second, this particular
WAVE file plays at a sample rate of 22255, which isn't a multiple of
44100, so SDL refuses to do the conversion.

Which is annoying.

The solution in this case is for playsound to not force the sample rate to
an arbitrary number, but instead create the Sound_Sample object first, and
then call SDL_OpenAudio() with those numbers. SDL_OpenAudio is recalled
for each file listed on the command line. (This is in CVS.)

Note this only helps if the sound device can actually DO a frequency of
22255, otherwise, SDL will try to convert with...uh, the same problems.

We REALLY need to fix the damned audio converter.

--ryan.





From torbjorn.e.andersson at tietoenator.com  Thu Oct  4 02:48:48 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Thu, 04 Oct 2001 08:48:48 +0200
Subject: Updates to SDL_sound
Message-ID: <3BBC0650.7020304@tietoenator.com>

I see you've fixed most - perhaps all - of my build problems while I 
were sleeping. Thanks! :-)

A few questions/observations though:

At the moment, aiff.c includes SDL_endian.h. That's no longer necessary, 
is it?

Slight inconsistency: shn.c and voc.c use #if (defined 
SOUND_SUPPORTS_...). The other decoders use #ifdef SHOULD_SUPPORTS_...

Should we include <config.h> or "config.h"? I know I have a few config.h 
files lurking in subdirectories of /usr/include and /usr/local/include 
on my system, so "config.h" sounds a bit safer to me...

If I understand the last playsound.c changes, it now lets the decoder 
decide the audio format. Won't that break the decoders which can't or 
won't get the sample rate from their input, e.g. RAW, MOD, MIDI, ...?

Speaking of playsound.c, for some reason that one wasn't being compiled 
when I tried it yesterday. If I changed its Makefile.am to use 
bin_PROGRAMS instead of check_PROGRAMS it seemed to work, but is that 
the right thing to do? I recently installed automake 1.5, so perhaps 
that broke something...

Torbj?rn Andersson



From max at quendi.de  Thu Oct  4 03:46:07 2001
From: max at quendi.de (Max Horn)
Date: Thu, 4 Oct 2001 09:46:07 +0200
Subject: WAVE playback bad
In-Reply-To: 
 <Pine.LNX.4.33L2.0110032059320.9685-100000@gamehenge.icculus.org>
References: 
 <Pine.LNX.4.33L2.0110032059320.9685-100000@gamehenge.icculus.org>
Message-ID: <p05101000b7e1c3ffa103@[217.225.194.115]>

At 21:09 Uhr -0400 03.10.2001, Ryan C. Gordon wrote:
>  > I have a wave file that is not playing properly for me using
>>  SDL_sounds's playsound. It sounds as if it was played at double speed
>>  or so (i.e. shorter than with other players, and higher pitch).
>
>Hhm. The problem is twofold.
>
>First, playsound forces a sample rate of 44100. Second, this particular
>WAVE file plays at a sample rate of 22255, which isn't a multiple of
>44100, so SDL refuses to do the conversion.
>
>Which is annoying.
>
>The solution in this case is for playsound to not force the sample rate to
>an arbitrary number, but instead create the Sound_Sample object first, and
>then call SDL_OpenAudio() with those numbers. SDL_OpenAudio is recalled
>for each file listed on the command line. (This is in CVS.)
>
>Note this only helps if the sound device can actually DO a frequency of
>22255, otherwise, SDL will try to convert with...uh, the same problems.
>
>We REALLY need to fix the damned audio converter.

In the case we rolled our own (crude) converter. If we do this, and 
do it right, we could then distribute it back to Sam for inclusion in 
future SDL version (though probably not 1.2.3, I can imagine it would 
break backward compatibility with some apps...)


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From max at quendi.de  Thu Oct  4 03:50:25 2001
From: max at quendi.de (Max Horn)
Date: Thu, 4 Oct 2001 09:50:25 +0200
Subject: Updates to SDL_sound
In-Reply-To: <3BBC0650.7020304@tietoenator.com>
References: <3BBC0650.7020304@tietoenator.com>
Message-ID: <p05101001b7e1c45ab62f@[217.225.194.115]>

At 8:48 Uhr +0200 04.10.2001, Torbj?rn Andersson wrote:
>I see you've fixed most - perhaps all - of my build problems while I 
>were sleeping. Thanks! :-)
>
>A few questions/observations though:
>
>At the moment, aiff.c includes SDL_endian.h. That's no longer 
>necessary, is it?
>
>Slight inconsistency: shn.c and voc.c use #if (defined 
>SOUND_SUPPORTS_...). The other decoders use #ifdef 
>SHOULD_SUPPORTS_...
>
>Should we include <config.h> or "config.h"? I know I have a few 
>config.h files lurking in subdirectories of /usr/include and 
>/usr/local/include on my system, so "config.h" sounds a bit safer to 
>me...

Well, <> is what the Autobook suggests; it won't make any difference 
for the decoders, though - they won't find config.h with "" in the 
user path anyway, since userpath means: same directory as source file 
or below; but config.h is one dir *up*. But our CPPFLAGS start with 
-I$(top_srcdir), guranteeing that our config.h is found immediatly.


Installing autoheader generated config.h files is a serious bug, but 
sadly, many apps do it :/ In fact, good that you remind me, I am not 
100% sure we don't (I didn't explicitly tell it to, of course, but 
checking that would be a good idea anyway).


>If I understand the last playsound.c changes, it now lets the 
>decoder decide the audio format. Won't that break the decoders which 
>can't or won't get the sample rate from their input, e.g. RAW, MOD, 
>MIDI, ...?
>
>Speaking of playsound.c, for some reason that one wasn't being 
>compiled when I tried it yesterday. If I changed its Makefile.am to 
>use bin_PROGRAMS instead of check_PROGRAMS it seemed to work, but is 
>that the right thing to do? I recently installed automake 1.5, so 
>perhaps that broke something...

Well, automake sadly has some serious limitation because it uses 
recursive make (like many bigger packages), which means that 
dependencies can't be resolved right.... you must make sure that the 
test app is built *after* the library. Try a make clean; make with 
your change, if it works, then it should be fine.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From torbjorn.e.andersson at tietoenator.com  Thu Oct  4 06:09:07 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Thu, 04 Oct 2001 12:09:07 +0200
Subject: WAVE playback bad
References: <Pine.LNX.4.33L2.0110032059320.9685-100000@gamehenge.icculus.org> <p05101000b7e1c3ffa103@[217.225.194.115]>
Message-ID: <3BBC3542.8000407@tietoenator.com>

I replied to sender instead of to mailing list again... >sigh<

Max Horn wrote:

 > In the case we rolled our own (crude) converter. If we do this, and do
 > it right, we could then distribute it back to Sam for inclusion in
 > future SDL version (though probably not 1.2.3, I can imagine it would
 > break backward compatibility with some apps...)

This may be old news, but SDL already has a SDL_RateSLOW() in 
SDL_audiocvt.c, in addition to SDL_RateMUL2() and SDL_RateDIV2(). 
Unfortunately it's never used. According to the comment:

         /* The problem with this is that if the input buffer is
            say 1K, and the conversion rate is say 1.1, then the
            output buffer is 1.1K, which may not be an acceptable
            buffer size for the audio driver (not a power of 2)
         */
         /* For now, punt and hope the rate distortion isn't great.
         */

So I guess either the audio drivers would have to be rewritten to handle 
arbitrary length buffers, or the sound converter would have to be 
rewritten so that instead of telling it how much input data you have, 
you tell it how much output data you want. I don't know which would be 
preferable.

(I'll leave this question for someone who actually knows how SDL works. 
I'm just faking it. ;-)

Torbj?rn Andersson



From icculus at clutteredmind.org  Thu Oct  4 15:12:51 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Thu, 4 Oct 2001 15:12:51 -0400 (EDT)
Subject: WAVE playback bad
In-Reply-To: <3BBC3542.8000407@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0110041506000.21292-100000@gamehenge.icculus.org>


> I replied to sender instead of to mailing list again... >sigh<

(I seriously need to get better mailing list software here...)

> This may be old news, but SDL already has a SDL_RateSLOW() in
> SDL_audiocvt.c, in addition to SDL_RateMUL2() and SDL_RateDIV2().
> Unfortunately it's never used. According to the comment:

Even RateSLOW() isn't particularly good, but it IS better than nothing.
Due to the nature of SDL_sound, we can probably make use of it better than
SDL itself can, since we're less concerned about powers of two.

To fix this in SDL, the data that is farmed from the audio callback needs
to be buffered if there's a conversion needed, due to the programmer
forcing the audio device into an emulated mode.

Psudeo code:

function get_data_for_audio_device()
{
  if (extrabuffer isn't empty)
  {
     move_what_you_can_to_audio_device(extrabuffer);
     if (extrabuffer still isn't empty)
        return;
  }

  audio_callback(buffer);  // get more data from application.
  if (need_conversion)
     do_conversion(buffer);

  move_what_you_can_to_audio_device(buffer);
  move_extra_sample_points_to_extra_buffer(buffer, extrabuffer);
}


...this adds overhead, but fixes the problem. note that "Move what you can
to the audio device" can still be all the data, if the audio device
doesn't require buffers to be multiples of two in size.

--ryan.





From icculus at clutteredmind.org  Thu Oct  4 15:19:59 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Thu, 4 Oct 2001 15:19:59 -0400 (EDT)
Subject: Sample properties in playsound...
Message-ID: <Pine.LNX.4.33L2.0110041518170.21292-100000@gamehenge.icculus.org>


...would it be better to have --rate, --channels, and --format options on
the playsound command line for sound formats that require you to specify
these properties? In the absence of those command line arguments,
playsound can set the "desired" field to NULL.

Yes? No?

--ryan.




From icculus at clutteredmind.org  Thu Oct  4 15:28:45 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Thu, 4 Oct 2001 15:28:45 -0400 (EDT)
Subject: Updates to SDL_sound
In-Reply-To: <3BBC0650.7020304@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0110041527210.383-100000@gemini.verizon.net>


> At the moment, aiff.c includes SDL_endian.h. That's no longer necessary,
> is it?

Sam seems to think that SDL_endian.h should NOT be included in SDL.h,
which doesn't make any sense to me, but oh well.

> Slight inconsistency: shn.c and voc.c use #if (defined
> SOUND_SUPPORTS_...). The other decoders use #ifdef SHOULD_SUPPORTS_...

I'll fix it.

> If I understand the last playsound.c changes, it now lets the decoder
> decide the audio format. Won't that break the decoders which can't or
> won't get the sample rate from their input, e.g. RAW, MOD, MIDI, ...?

(See last post.)

--ryan.





From torbjorn.e.andersson at tietoenator.com  Fri Oct  5 02:28:57 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 05 Oct 2001 08:28:57 +0200
Subject: Updates to SDL_sound
References: <3BBC0650.7020304@tietoenator.com> <p05101001b7e1c45ab62f@[217.225.194.115]>
Message-ID: <3BBD5329.8000900@tietoenator.com>

Max Horn wrote:

 > Try a make clean; make with your change, if it works, then it should
 > be fine.

I thought I had tried that, but when I tried it again it turned out to 
not work after all. >sigh<

I plead incompetence.

Torbj?rn Andersson



From torbjorn.e.andersson at tietoenator.com  Fri Oct  5 03:10:13 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 05 Oct 2001 09:10:13 +0200
Subject: Sample properties in playsound...
References: <Pine.LNX.4.33L2.0110041518170.21292-100000@gamehenge.icculus.org>
Message-ID: <3BBD5CD5.4050905@tietoenator.com>

Ryan C. Gordon wrote:

 > ...would it be better to have --rate, --channels, and --format options
 > on the playsound command line for sound formats that require you to
 > specify these properties? In the absence of those command line
 > arguments, playsound can set the "desired" field to NULL.

That should work for playsound. By "format" you mean 8/16-bit 
signed/unsigned big-/little-endian, right? Might be useful with an 
option to explicitly tell it what kind of input - RAW, MP3, etc. - to 
expect, regardless of what the filename says, but that would probably 
need changes to Sound_NewSampleFromFile()...

What should the decoders do if the "desired" field is NULL? Some of them 
can pick the appropriate format from their input, so they should be ok. 
Others can pick any sensible format they like but have used the desired 
format so far just to be nice, so they should also be ok.

What about decoders such as RAW? Should they fail, or should they use 
sensible defaults?

Torbj?rn Andersson



From torbjorn.e.andersson at tietoenator.com  Fri Oct  5 03:14:41 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 05 Oct 2001 09:14:41 +0200
Subject: Updates to SDL_sound
References: <Pine.LNX.4.33.0110041527210.383-100000@gemini.verizon.net>
Message-ID: <3BBD5DE1.1010809@tietoenator.com>

Ryan C. Gordon wrote:

 > Sam seems to think that SDL_endian.h should NOT be included in SDL.h,
 > which doesn't make any sense to me, but oh well.

Actually, what I meant was that aiff.c will get SDL_endian.h through 
SDL_sound.h, but perhaps that was always the case. I can't remember now 
why I explicitly included SDL_endian.h into aiff.c. I'd like to think 
there was some terribly good reason, but... :-)

Torbj?rn Andersson




From icculus at clutteredmind.org  Fri Oct  5 10:03:23 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 5 Oct 2001 10:03:23 -0400 (EDT)
Subject: Sample properties in playsound...
In-Reply-To: <3BBD5CD5.4050905@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0110050946210.31939-100000@gamehenge.icculus.org>


> That should work for playsound. By "format" you mean 8/16-bit
> signed/unsigned big-/little-endian, right? Might be useful with an

Yep.

> option to explicitly tell it what kind of input - RAW, MP3, etc. - to
> expect, regardless of what the filename says, but that would probably
> need changes to Sound_NewSampleFromFile()...

NewSampleFromFile() is just a convenience function; if you need to specify
something different ("mysound.bin" is really an MP3 file, for example),
then you should do:

  SDL_RWops *rw = SDL_RWFromFile("mysound.bin", "rb");
  Sound_Sample *sample = Sound_NewSample(rw, "MP3", desired, bufsize);

That being said, we DO need to extend Sound_AudioInfo to allow the listing
of multiple extensions, since things like MikMod handle 18 million
formats, and a MIDI decoder should be able to expect both ".mid" and
".midi" files, etc.

> What should the decoders do if the "desired" field is NULL? Some of them
> can pick the appropriate format from their input, so they should be ok.
> Others can pick any sensible format they like but have used the desired
> format so far just to be nice, so they should also be ok.
> What about decoders such as RAW? Should they fail, or should they use
> sensible defaults?

My thought is that with decoders like RAW, if no desired format is
specified, than the decoder's open() method fails; we can pick a sensible
default, but if that sensible default is wrong, you get a lot of jarring
noise; I'd rather have the decoder politely refuse.

--ryan.





From icculus at clutteredmind.org  Fri Oct  5 10:05:19 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 5 Oct 2001 10:05:19 -0400 (EDT)
Subject: Updates to SDL_sound
In-Reply-To: <3BBD5DE1.1010809@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0110051004550.31939-100000@gamehenge.icculus.org>


> Actually, what I meant was that aiff.c will get SDL_endian.h through
> SDL_sound.h, but perhaps that was always the case. I can't remember now
> why I explicitly included SDL_endian.h into aiff.c. I'd like to think
> there was some terribly good reason, but... :-)

Oh, ok.  :)

It's now changed in CVS.

--ryan.




From torbjorn.e.andersson at tietoenator.com  Fri Oct  5 10:34:32 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 05 Oct 2001 16:34:32 +0200
Subject: Sample properties in playsound...
References: <Pine.LNX.4.33L2.0110050946210.31939-100000@gamehenge.icculus.org>
Message-ID: <3BBDC4F8.3060702@tietoenator.com>

Ryan C. Gordon wrote

 > NewSampleFromFile() is just a convenience function; if you need to
 > specify something different ("mysound.bin" is really an MP3 file, for
 > example), then you should do:
 >
 >   SDL_RWops *rw = SDL_RWFromFile("mysound.bin", "rb");
 >   Sound_Sample *sample = Sound_NewSample(rw, "MP3", desired, bufsize);

Yes, that makes sense. What I was thinking was that maybe it would make 
sense to have something like

    $ playsound --ext MP3 foobar.gif

just for testing purposes. Then again, maybe not...

 > My thought is that with decoders like RAW, if no desired format is
 > specified, than the decoder's open() method fails; we can pick a
 > sensible default, but if that sensible default is wrong, you get a lot
 > of jarring noise; I'd rather have the decoder politely refuse.

Ok, so only the MOD and MIDI decoders need fixing to handle the NULL 
case? Does the included - untested - patch look sensible?

Torbj?rn Andersson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: null.diff.gz
Type: application/x-gzip
Size: 640 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20011005/0c370a44/attachment.gz>

From icculus at clutteredmind.org  Fri Oct  5 12:26:59 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 5 Oct 2001 12:26:59 -0400 (EDT)
Subject: Sample properties in playsound...
In-Reply-To: <3BBDC4F8.3060702@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0110051223210.350-100000@gemini.verizon.net>


> Yes, that makes sense. What I was thinking was that maybe it would make
> sense to have something like
>
>     $ playsound --ext MP3 foobar.gif
>
> just for testing purposes. Then again, maybe not...

We probably _should_, but I'm lazy.  :)

> Ok, so only the MOD and MIDI decoders need fixing to handle the NULL
> case? Does the included - untested - patch look sensible?

Yes, with one problem that's only partially related:

  In MikMod, is md_mixfreq a global variable?

That's going to cause problems if two separate MODs with different sample
rates are decoded simulataneously. Perhaps we should force MikMod to
always use 44100 or 22050 or whatever the first rate requested was for
every sample?

(Or we should patch Mikmod to not use global variables...what the hell
were they thinking?!)

--ryan.




From torbjorn.e.andersson at tietoenator.com  Fri Oct  5 13:17:06 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 05 Oct 2001 19:17:06 +0200
Subject: Sample properties in playsound...
References: <Pine.LNX.4.33.0110051223210.350-100000@gemini.verizon.net>
Message-ID: <3BBDEB12.6080305@tietoenator.com>

Ryan C. Gordon wronte:

 > Yes, with one problem that's only partially related:
 >
 >   In MikMod, is md_mixfreq a global variable?

D'oh!

Yes, it's a global variable defined in mplayer.c as

    MIKMODAPI UWORD md_mixfreq = 44100;

 > Perhaps we should force MikMod to always use 44100 or 22050 or
 > whatever the first rate requested was for every sample?

Yes. Or just not set it at all, letting MikMod decide the sensible default.

(I guess we could also save the desired frequency as part of the mod_t 
structure and change md_mixfreq as needed, but I don't know if that's a 
safe thing to do so I'd say let's not.)

 > (Or we should patch Mikmod to not use global variables...what the hell
 > were they thinking?!)

Such a change would probably break a lot of existing programs so I 
wouldn't count on getting that patch accepted.

Torbj?rn Andersson



From torbjorn.e.andersson at tietoenator.com  Fri Oct  5 13:20:46 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 05 Oct 2001 19:20:46 +0200
Subject: TiMidity... again
Message-ID: <3BBDEBEE.2040905@tietoenator.com>

I've been meaning to take a closer look at the TiMidity source code, 
trying to understand how it works. Considering that it's no longer 
maintained, and that it doesn't seem to be immediately useful in its 
current shape (I could be wrong about this), what approach do you think 
we should take with it? Minimal changes to get it to work as a part of 
SDL_sound, or an all-out "hey let's turn this into a standalone MIDI 
decoder library!" rewrite?

Mind you, I'm not making any promises about my ability to make either 
approach work. :-)

Torbj?rn Andersson



From icculus at clutteredmind.org  Fri Oct  5 13:56:50 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 5 Oct 2001 13:56:50 -0400 (EDT)
Subject: TiMidity... again
In-Reply-To: <3BBDEBEE.2040905@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0110051354330.397-100000@gemini.verizon.net>

> we should take with it? Minimal changes to get it to work as a part of
> SDL_sound, or an all-out "hey let's turn this into a standalone MIDI
> decoder library!" rewrite?

Let's take the middle ground; for now, let's embed it into the SDL_sound
source (like SDL_mixer does), but perhaps with the option to move it out
to a separate library later?

--ryan.





From tsm at accesscomm.ca  Sat Oct  6 20:01:43 2001
From: tsm at accesscomm.ca (Corona688)
Date: Sat, 06 Oct 2001 18:01:43 -0600
Subject: Changes for Win32 port
Message-ID: <3BBF9B67.220BA10B@accesscomm.ca>

I am attempting to port SDL_sound to Win32, and so far it hasn't been
incredibly difficult.  I've started with a plain Win32 static library.

aiff.c, raw.c, voc.c and wav.c all compiled without complaint.

In ogg.c, there was one instance of int64_t that needed to be changed to
ogg_int64_t, it now compiles fine.

In shn.c, I regrettably needed to remove almost every darn inline.
Also, I had to change
    memcpy(internal->buffer + bw, shn->backBuffer, i);
into
    memcpy((char *)internal->buffer + bw, shn->backBuffer, i);
because it complained that "void * is of unknown size". It now compiles
fine.

I haven't done mp3.c, midi.c, and mod.c because I don't have the
required libraries yet, but I'm working on that...

When I compiled and used playsound.exe with SDL_sound.lib,
ogg_static.lib, vorbis_static.lib, and vorbisfile_static.lib linked in,
it worked fine with wav's, ogg's, and aif's.  It plays .VOCs, but sounds
odd; I'm uncertain as to which is the problem, the code or the .voc.
Lastly, I don't have a .shn handy to test it with so I just don't know.



From icculus at clutteredmind.org  Sat Oct  6 20:39:18 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sat, 6 Oct 2001 20:39:18 -0400 (EDT)
Subject: Changes for Win32 port
In-Reply-To: <3BBF9B67.220BA10B@accesscomm.ca>
Message-ID: <Pine.LNX.4.33.0110062029080.8800-100000@gemini.verizon.net>


> When I compiled and used playsound.exe with SDL_sound.lib,
> ogg_static.lib, vorbis_static.lib, and vorbisfile_static.lib linked in,
> it worked fine with wav's, ogg's, and aif's.  It plays .VOCs, but sounds
> odd; I'm uncertain as to which is the problem, the code or the .voc.
> Lastly, I don't have a .shn handy to test it with so I just don't know.

Please email me the questionable .VOC file, and I'll take a look. The VOC
code isn't very heavily tested.

Here's a .SHN known to work on my system:

http://icculus.org/SDL_sound/downloads/example_sounds/grateful-dead-02281969-intro.shn

 (It's about 700k worth of data.)

There's some silence at the beginning, followed by some guy saying
"without any further ado: The Grateful Dead".

The SHN code is even less tested than the VOC code.  :)

If y'all could point me to some good example soundfiles in different
formats, I'll put them in the example_sounds directory on the website. I'm
looking for small, legally redistributable files.

--ryan.




From icculus at clutteredmind.org  Sat Oct  6 21:28:50 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sat, 6 Oct 2001 21:28:50 -0400 (EDT)
Subject: Changes for Win32 port
In-Reply-To: <3BBF9B67.220BA10B@accesscomm.ca>
Message-ID: <Pine.LNX.4.33L2.0110062109390.17961-100000@gamehenge.icculus.org>

> In shn.c, I regrettably needed to remove almost every darn inline.
> Also, I had to change
>     memcpy(internal->buffer + bw, shn->backBuffer, i);
> into
>     memcpy((char *)internal->buffer + bw, shn->backBuffer, i);
> because it complained that "void * is of unknown size". It now compiles
> fine.

What sort of error are you getting from the inline keyword? It might
just be that the syntax is different (__inline__ or something) for Visual
C++, and I'd rather keep it in there in some form if at all possible.

> When I compiled and used playsound.exe with SDL_sound.lib,
> ogg_static.lib, vorbis_static.lib, and vorbisfile_static.lib linked in,
> it worked fine with wav's, ogg's, and aif's.  It plays .VOCs, but sounds
> odd; I'm uncertain as to which is the problem, the code or the .voc.
> Lastly, I don't have a .shn handy to test it with so I just don't know.

The .VOC seems to play here under SOX and playsound. At least, it sounds
like the same engine under each.  :)

I'm betting (since the .VOC is playing at a frequency of 12048 Hz) that
you're getting bitten by SDL's sample rate conversion problem, which it's
been almost 24 hours since I've said, "we really need to fix that damned
thing."  :)

I'm making the change to ogg.c in CVS. Can you please send me the Visual C
project files when you feel they are ready?

--ryan.




From tsm at accesscomm.ca  Sat Oct  6 22:52:57 2001
From: tsm at accesscomm.ca (Corona688)
Date: Sat, 06 Oct 2001 20:52:57 -0600
Subject: Changes for Win32 port
References: <Pine.LNX.4.33L2.0110062109390.17961-100000@gamehenge.icculus.org>
Message-ID: <3BBFC389.B75F914D@accesscomm.ca>

"Ryan C. Gordon" wrote:

> What sort of error are you getting from the inline keyword? It might
> just be that the syntax is different (__inline__ or something) for Visual
> C++, and I'd rather keep it in there in some form if at all possible.

The syntax for MSVC is definitely just inline.  I'm wondering now, though, if
it's the combination of static and inline that did it.  What the heck IS a
static inline, anyway?

> The .VOC seems to play here under SOX and playsound. At least, it sounds
> like the same engine under each.  :)

It wasn't just the wrong samplerate, it sounded like it was divided into four
distinct chunks rather than a normal fade-off.

> I'm betting (since the .VOC is playing at a frequency of 12048 Hz) that
> you're getting bitten by SDL's sample rate conversion problem, which it's
> been almost 24 hours since I've said, "we really need to fix that damned
> thing."  :)
>
> I'm making the change to ogg.c in CVS. Can you please send me the Visual C
> project files when you feel they are ready?
>
> --ryan.

Well, the project files are somewhat weird, and I can't gurantee that
everyone'll be able to compile it the same way.  I happen to have
ogg_static.lib etc available, but others might not.

As for MikMod, I've been unable to successfully compile it;  the MikMod guys
deigned to use makefiles for Win32 rather than an ordinary .dsw, and since my
install of nmake has issues I had to try compiling it cold turkey...  MSVC
gracefully forgot to export tons of stuff, and now I'm hunting for Win32
MikMod binaries.



From icculus at clutteredmind.org  Sun Oct  7 00:41:25 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 7 Oct 2001 00:41:25 -0400 (EDT)
Subject: Changes for Win32 port
In-Reply-To: <3BBFC389.B75F914D@accesscomm.ca>
Message-ID: <Pine.LNX.4.33.0110070036400.13491-100000@gemini.verizon.net>


> The syntax for MSVC is definitely just inline.  I'm wondering now, though, if
> it's the combination of static and inline that did it.  What the heck IS a
> static inline, anyway?

A module-scope symbol that can be inlined.  (*shrug*)

It should be doable; in fact, I can't imagine how inlining can be
guaranteed when the function isn't static.

This needs to be examined more closely, I think.

> It wasn't just the wrong samplerate, it sounded like it was divided into four
> distinct chunks rather than a normal fade-off.

...I won't rule out that the voc decoder is just broken on win32.

> Well, the project files are somewhat weird, and I can't gurantee that
> everyone'll be able to compile it the same way.  I happen to have
> ogg_static.lib etc available, but others might not.

When you zip up the project files, include any headers or libraries
someone might need; if they need less, they can always make changes
locally.

--ryan.





From tsm at accesscomm.ca  Sun Oct  7 18:42:01 2001
From: tsm at accesscomm.ca (Corona688)
Date: Sun, 07 Oct 2001 16:42:01 -0600
Subject: smpeg works under Win32, but MikMod doesn't
Message-ID: <3BC0DA39.BF37B3AF@accesscomm.ca>

I can compile and use the MikMod from SDL_mixer with it, but when I try
and play a .mod with playsound.exe it says

Couldn't open audio device!
  reason: [DirectSound CreateSoundBuffer: Invalid parameter].

smpeg works absolutely fine, tho



From icculus at clutteredmind.org  Sun Oct  7 18:47:41 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 7 Oct 2001 18:47:41 -0400 (EDT)
Subject: smpeg works under Win32, but MikMod doesn't
In-Reply-To: <3BC0DA39.BF37B3AF@accesscomm.ca>
Message-ID: <Pine.LNX.4.33.0110071846300.504-100000@gemini.verizon.net>


> Couldn't open audio device!
>   reason: [DirectSound CreateSoundBuffer: Invalid parameter].

Can you rebuild the project with the following symbols defined:
  DEBUG
  DEBUG_CHATTER

This will spit more information out to stdout, so we can determine what's
specifically wrong.

> smpeg works absolutely fine, tho

Cool!

--ryan.




From tsm at accesscomm.ca  Sun Oct  7 19:29:13 2001
From: tsm at accesscomm.ca (Corona688)
Date: Sun, 07 Oct 2001 17:29:13 -0600
Subject: smpeg works under Win32, but MikMod doesn't
References: <Pine.LNX.4.33.0110071846300.504-100000@gemini.verizon.net>
Message-ID: <3BC0E549.F1A976A4@accesscomm.ca>

"Ryan C. Gordon" wrote:

> > Couldn't open audio device!
> >   reason: [DirectSound CreateSoundBuffer: Invalid parameter].
>
> Can you rebuild the project with the following symbols defined:
>   DEBUG
>   DEBUG_CHATTER
>
> This will spit more information out to stdout, so we can determine what's
> specifically wrong.
>
> --ryan.

Done and done.  and I mean, done.

O:\code\SDL_sound\test\visualc>playsound mod7.mod
MOD: Accepting data stream
New sample DESIRED format: S16LSB format, 0 rate, 2 channels.
New sample ACTUAL format: S16LSB format, 0 rate, 2 channels.
On-the-fly conversion: DISABLED.
Couldn't open audio device!
  reason: [DirectSound CreateSoundBuffer: Invalid parameter].

Apparently, it's trying to create an output buffer with a samplerate of zero,
which won't work for obvious reasons.  I'm not sure where this is happening,
however.



From tsm at accesscomm.ca  Sun Oct  7 21:07:47 2001
From: tsm at accesscomm.ca (Corona688)
Date: Sun, 07 Oct 2001 19:07:47 -0600
Subject: MikMod working under Win32
Message-ID: <3BC0FC63.70F677A9@accesscomm.ca>

I put a clause in mod.c that makes it assume a 44Khz samplerate if the
requested samplerate is zero.
I replaced
md_mixfreq = sample->desired.rate;
with

if(sample->desired.rate==0)
     md_mixfreq=44100;
else
     md_mixfreq = sample->desired.rate;

and now MikMod works. =)  I'm happy.



From icculus at clutteredmind.org  Sun Oct  7 23:41:47 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 7 Oct 2001 23:41:47 -0400 (EDT)
Subject: MikMod working under Win32
In-Reply-To: <3BC0FC63.70F677A9@accesscomm.ca>
Message-ID: <Pine.LNX.4.33.0110072340050.3201-100000@gemini.verizon.net>


> and now MikMod works. =)  I'm happy.

I just placed a fix based on this into CVS. Thanks!

--ryan.





From tsm at accesscomm.ca  Mon Oct  8 14:30:29 2001
From: tsm at accesscomm.ca (Corona688)
Date: Mon, 08 Oct 2001 12:30:29 -0600
Subject: I cannot convert midi.c
Message-ID: <3BC1F0C5.E8432DB3@accesscomm.ca>

It is using the obnoxious UNIX call fork( ), which has no sensible Win32
equivalent.  It is possible to do a total reimplimentation using
CreateProcess, but that's far beyond my humble abilities.  So, my
current Win32 port contains everything BUT Timidity.  I'll try and
submit it soon.



From icculus at clutteredmind.org  Mon Oct  8 14:33:15 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 8 Oct 2001 14:33:15 -0400 (EDT)
Subject: I cannot convert midi.c
In-Reply-To: <3BC1F0C5.E8432DB3@accesscomm.ca>
Message-ID: <Pine.LNX.4.33L2.0110081432510.6145-100000@gamehenge.icculus.org>


> It is using the obnoxious UNIX call fork( ), which has no sensible Win32
> equivalent.  It is possible to do a total reimplimentation using
> CreateProcess, but that's far beyond my humble abilities.  So, my
> current Win32 port contains everything BUT Timidity.  I'll try and
> submit it soon.

I wouldn't bother porting the current MIDI code...it's in there as an
experiment.

--ryan.





From icculus at clutteredmind.org  Mon Oct  8 15:16:49 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 8 Oct 2001 15:16:49 -0400 (EDT)
Subject: Updated WAV decoder.
Message-ID: <Pine.LNX.4.33L2.0110081514330.6145-100000@gamehenge.icculus.org>


I've restructured the WAV decoder to allow for various formats, which will
allow for handling compressed WAVE types.

It's in CVS, but it may be broken; I don't have a soundcard available at
the moment to try it.  :)

I've put the start of an ADPCM compression handler in place, but not the
actual decompression code, so it should error out on the first read.
Hopefully uncompressed WAVs should still work.

--ryan.





From icculus at clutteredmind.org  Tue Oct  9 20:48:01 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 9 Oct 2001 20:48:01 -0400 (EDT)
Subject: fyi...
Message-ID: <Pine.LNX.4.33L2.0110092045220.26458-100000@gamehenge.icculus.org>


...the win32 port appears to be fully functional; grab from CVS and unzip
this archive into the root of the source tree:

   http://icculus.org/SDL_sound/downloads/SDL_sound_win32.zip

...the zipfile has some auxillary libraries and Visual C project files.

Thanks to Tyler Montbriand for all the ugly porting work!

--ryan.




From icculus at clutteredmind.org  Tue Oct  9 20:50:21 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 9 Oct 2001 20:50:21 -0400 (EDT)
Subject: "make package"?
Message-ID: <Pine.LNX.4.33L2.0110092048040.26458-100000@gamehenge.icculus.org>


Max:

Can you put together something like the "make package" target from the old
SDL_sound Makefile?

  (for reference:

http://cvs.icculus.org/horde/chora/co.php/Attic/Makefile?sa=1&rt=SDL_sound&r=1.11

)

I'd like to put out a new tarball and announce on Freshmeat, but I want to
make sure that the correct files for configuration, etc are included.

--ryan.





From torbjorn.e.andersson at tietoenator.com  Wed Oct 10 02:41:22 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Wed, 10 Oct 2001 08:41:22 +0200
Subject: "make package"?
References: <Pine.LNX.4.33L2.0110092048040.26458-100000@gamehenge.icculus.org>
Message-ID: <3BC3ED92.7060302@tietoenator.com>

Ryan C. Gordon wrote:

 > I'd like to put out a new tarball and announce on Freshmeat, but I
 > want to make sure that the correct files for configuration, etc are
 > included.

Before you do, could you please apply the patch discussed recently to 
make the experimental MIDI decoder handle the case where there is no 
desired audio format? I haven't actually checked, but I assume it isn't 
working at all right now.

(I've started removing unnecessary stuff from SDL_mixer's TiMidity tree 
to see if it can be made into a proper MIDI decoder, but it's still far 
too early to say I've made any progress with it.)

Torbj?rn Andersson



From max at quendi.de  Wed Oct 10 04:14:31 2001
From: max at quendi.de (Max Horn)
Date: Wed, 10 Oct 2001 10:14:31 +0200
Subject: "make package"?
In-Reply-To: 
 <Pine.LNX.4.33L2.0110092048040.26458-100000@gamehenge.icculus.org>
References: 
 <Pine.LNX.4.33L2.0110092048040.26458-100000@gamehenge.icculus.org>
Message-ID: <p05101002b7e9acf8e776@[217.225.194.21]>

At 20:50 Uhr -0400 09.10.2001, Ryan C. Gordon wrote:
>Max:
>
>Can you put together something like the "make package" target from the old
>SDL_sound Makefile?
>
>   (for reference:
>
>http://cvs.icculus.org/horde/chora/co.php/Attic/Makefile?sa=1&rt=SDL_sound&r=1.11
>
>)
>
>I'd like to put out a new tarball and announce on Freshmeat, but I want to
>make sure that the correct files for configuration, etc are included.

This shouldn't be a problem, as automake automatically creates a 
"make dist" target that will do all of this for us.

Of course we need to tell it what files we want to include, i.e. it 
will include the source and some standard file (README, COPYING etc.) 
automatically, but for others I have to tell it via EXTRA_DIST -> no 
big deal.


So, to build a tar ball, just go into the SDL_sound dir, and type:

   make dist

That's all.



By the way, may I request that the ChangeLog format is changed? You 
don't have to adopte the FSF style, but at least new things should be 
at the top. This way, when I open that file I see immediatly what is 
new, and don't have to scroll down.

Also, the LICENSE file should be called COPYING to conform to the 
"standard" for (L)GPL projects.




Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From icculus at clutteredmind.org  Wed Oct 10 14:18:32 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 10 Oct 2001 14:18:32 -0400 (EDT)
Subject: "make package"?
In-Reply-To: <3BC3ED92.7060302@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0110101416110.3714-100000@gamehenge.icculus.org>


> Before you do, could you please apply the patch discussed recently to
> make the experimental MIDI decoder handle the case where there is no
> desired audio format? I haven't actually checked, but I assume it isn't
> working at all right now.

There was a patch?

I don't remember there being a patch...I thought it was just discussed.
Maybe I'm confused.

> (I've started removing unnecessary stuff from SDL_mixer's TiMidity tree
> to see if it can be made into a proper MIDI decoder, but it's still far
> too early to say I've made any progress with it.)

(*sigh*) It's probably the best way to handle it, I'm afraid.

--ryan.





From icculus at clutteredmind.org  Wed Oct 10 14:24:16 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 10 Oct 2001 14:24:16 -0400 (EDT)
Subject: "make package"?
In-Reply-To: <p05101002b7e9acf8e776@[217.225.194.21]>
Message-ID: <Pine.LNX.4.33L2.0110101422280.3714-100000@gamehenge.icculus.org>


>    make dist
>
> That's all.

Ah, ok.

> By the way, may I request that the ChangeLog format is changed? You
> don't have to adopte the FSF style, but at least new things should be
> at the top. This way, when I open that file I see immediatly what is
> new, and don't have to scroll down.

(*grumble*)  Ok, but not right now. Too lazy to reformat it.  :)

> Also, the LICENSE file should be called COPYING to conform to the
> "standard" for (L)GPL projects.

(*more grumbling*) Yeah, yeah...ok.  :)

--ryan.





From torbjorn.e.andersson at tietoenator.com  Thu Oct 11 02:30:05 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Thu, 11 Oct 2001 08:30:05 +0200
Subject: "make package"?
References: <Pine.LNX.4.33L2.0110101416110.3714-100000@gamehenge.icculus.org>
Message-ID: <3BC53C6D.40700@tietoenator.com>

Ryan C. Gordon wrote:

 > There was a patch?
 >
 > I don't remember there being a patch...I thought it was just
 > discussed. Maybe I'm confused.

Well, it wasn't tested but it should work. (Famous last words.) It was 
in the "Sample properties in playsound..." thread. You looked at it and 
pointed out my error in the MOD part of the patch. :-)

For TiMidity, the idea was to replace

     /* TiMidity does all the conversions we need. */
memcpy(&sample->actual, &sample->desired, sizeof (Sound_AudioInfo));

with something like

     /*
      * TiMidity does all the conversions we need. Use the desired format
      * when available, otherwise pick a sensible default.
      */
if (sample->desired.format == 0)
{
     sample->actual.channels = 2;
     sample->actual.rate = 44100;
     sample->actual.format = AUDIO_S16SYS;
} /* if */
else
     memcpy(&sample->actual, &sample->desired, sizeof (Sound_AudioInfo));

Torbj?rn Andersson



From torbjorn.e.andersson at tietoenator.com  Fri Oct 12 02:33:01 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 12 Oct 2001 08:33:01 +0200
Subject: Telling playsound what format to use
Message-ID: <3BC68E9D.6000008@tietoenator.com>

This is an attempt to add options to playsound to set sample rate, 
format and channels. I'm not sure if it's working correctly. I mean, I 
can use it to force bad frequency conversions so obviously it's doing 
something right. However, some of the conversions I tried led to choppy 
sound (too small buffer, perhaps?), complete silence or awful noise. In 
some cases it sounded as if only part of the audio had been converted.

I don't have any specific examples yet, but I did most of the testing 
with the MP3 decoder.

Torbj?rn Andersson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: playsound.diff.gz
Type: application/x-gzip
Size: 1454 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20011012/d2121a15/attachment.gz>

From icculus at clutteredmind.org  Fri Oct 12 13:03:34 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 12 Oct 2001 13:03:34 -0400 (EDT)
Subject: Telling playsound what format to use
In-Reply-To: <3BC68E9D.6000008@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0110121302200.26246-100000@gamehenge.icculus.org>


> This is an attempt to add options to playsound to set sample rate,
> format and channels. I'm not sure if it's working correctly. I mean, I
> can use it to force bad frequency conversions so obviously it's doing
> something right. However, some of the conversions I tried led to choppy
> sound (too small buffer, perhaps?), complete silence or awful noise. In
> some cases it sounded as if only part of the audio had been converted.

We'll have to look at the conversion stuff more closely, because, if I
haven't said it recently, we really need to rewrite the converter.  :)

I've committed the changes to CVS.  Thanks!

--ryan.




From torbjorn.e.andersson at tietoenator.com  Fri Oct 12 13:18:52 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 12 Oct 2001 19:18:52 +0200
Subject: Telling playsound what format to use
References: <Pine.LNX.4.33L2.0110121302200.26246-100000@gamehenge.icculus.org>
Message-ID: <3BC725FC.70309@tietoenator.com>

Ryan C. Gordon wrote:

 > We'll have to look at the conversion stuff more closely, because, if I
 > haven't said it recently, we really need to rewrite the converter.  :)

I still can't see any way of doing that in SDL without breaking 
backwards compatibility in some way, so I've been meaning to put a 
modified version of it in SDL sound and see how that works. Perhaps we 
can pass it off as a "potentially useful testbed for SDL 1.3" sort of thing.

Does anyone who hasn't been sworn to secrecy know what the plans for 
audio - or anything else for that matter - in SDL 1.3 are?

 > I've committed the changes to CVS.  Thanks!

Oops, the bit where I set sdl_desired.samples = 4096 * 2 was still in 
the patch I submitted? That was just an experiment and not really my 
intention.

(Unless, of course, it turns out to be a good idea. In that case, I 
meant to do it. Really. ;-)

Torbj?rn Andersson



From icculus at clutteredmind.org  Fri Oct 12 13:30:55 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 12 Oct 2001 13:30:55 -0400 (EDT)
Subject: Telling playsound what format to use
In-Reply-To: <3BC725FC.70309@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0110121329070.26246-100000@gamehenge.icculus.org>


> I still can't see any way of doing that in SDL without breaking
> backwards compatibility in some way, so I've been meaning to put a
> modified version of it in SDL sound and see how that works. Perhaps we
> can pass it off as a "potentially useful testbed for SDL 1.3" sort of thing.

My thoughts exactly. SDL_mixer will have a new implementation of
SDL_MixAudio, too. This seems to be the best way to do it.

> Does anyone who hasn't been sworn to secrecy know what the plans for
> audio - or anything else for that matter - in SDL 1.3 are?

We haven't discussed audio at all yet. Mostly we're hashing out video
subsystem details at the moment, and the build system.

> (Unless, of course, it turns out to be a good idea. In that case, I
> meant to do it. Really. ;-)

Hah.

--ryan.





From torbjorn.e.andersson at tietoenator.com  Fri Oct 12 13:55:00 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 12 Oct 2001 19:55:00 +0200
Subject: Telling playsound what format to use
References: <Pine.LNX.4.33L2.0110121329070.26246-100000@gamehenge.icculus.org>
Message-ID: <3BC72E74.9000904@tietoenator.com>

Ryan C. Gordon wrote:

 > My thoughts exactly. SDL_mixer will have a new implementation of
 > SDL_MixAudio, too. This seems to be the best way to do it.

Aha? Out of curiosity, what are the issues with SDL_MixAudio?

Torbj?rn Andersson





From icculus at clutteredmind.org  Fri Oct 12 14:22:35 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 12 Oct 2001 14:22:35 -0400
Subject: Telling playsound what format to use
In-Reply-To: <3BC72E74.9000904@tietoenator.com>
References: <Pine.LNX.4.33L2.0110121329070.26246-100000@gamehenge.icculus.org> <3BC72E74.9000904@tietoenator.com>
Message-ID: <1002910955.3bc734ebb56bf@mail.icculus.org>

> Aha? Out of curiosity, what are the issues with SDL_MixAudio?

It clamps everytime you mix two samples, which is fine if you're only mixing 
two, but for something like SDL_mixer, we'll need to clamp after an abitrary 
number of samples. I'm thinking there should be something like

  SDL_MixNSamples(Uint8 **samples, int numsamples, Uint *dst, Uint32 len, int 
volume);


And SDL_MixAudio() becomes:

  void SDL_MixAudio(Uint8 *dst, Uint8 *src, Uint32 len, int volume)
  {
     Uint8 *samples[2] = { dst, src };
     SDL_MixAudio(samples, 2, dst, len, volume);
  }

--ryan.




From tsm at accesscomm.ca  Fri Oct 12 22:02:51 2001
From: tsm at accesscomm.ca (Corona688)
Date: Fri, 12 Oct 2001 20:02:51 -0600
Subject: Idea for using decoders' special features
Message-ID: <3BC7A0CB.4041AC8C@accesscomm.ca>

Some of these decoders, MikMOD in particular, have extra features that
are pretty difficult to take advantage of unless we want to make
function calls with 3 dozen variables or huge weird structures that
contain everything imaginable.  Just the same, it'd be a shame if we
couldn't use them.

What I'd like to be able to do, is assign the responsibility for
interpreting these special features up to the decoders, while still
having the ability to set them explicitly if we want to.  Could we add a
const char * parameter to Sound_NewSampleFromFile() etc. and pass it
commandline-like strings?  Like:

sample = Sound_NewSampleFromFile("someawful.mod", NULL, 4096 *
4,"-e:7");

if we wanted to set MikMOD's echo level to seven.  And if we just want
the default, we can give it NULL.  Thoughts?



From icculus at clutteredmind.org  Sat Oct 13 01:17:46 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sat, 13 Oct 2001 01:17:46 -0400 (EDT)
Subject: Idea for using decoders' special features
In-Reply-To: <3BC7A0CB.4041AC8C@accesscomm.ca>
Message-ID: <Pine.LNX.4.33.0110130116410.7878-100000@gemini.verizon.net>


> sample = Sound_NewSampleFromFile("someawful.mod", NULL, 4096 *
> 4,"-e:7");

Let me think about it, because it CAN be handy in some situations, but
honestly, not many. Others, please comment.

--ryan.




From torbjorn.e.andersson at tietoenator.com  Sun Oct 14 09:40:42 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Sun, 14 Oct 2001 15:40:42 +0200
Subject: Transplanting SDL_audiocvt.c to SDL_sound
Message-ID: <3BC995DA.9070005@tietoenator.com>

This is a first attempt at transplanting the audio converter from SDL
to SDL_sound. I've reformatted the code and made some slight
restructuring, but the only important change is that I've enabled the
slow rate conversion filter.

I didn't even dare to touch the file header.

I thought I would have to change SDL_sound to handle arbitrary buffer
lengths, but it looks like playsound already does. Neat.

One known issue is that the MP3 decoder gets very unhappy if I force a
conversion between signed and unsigned data. I have no idea why. I
can't reproduce the problem with any of the other converters I tried.

The choppy sound when converting from 16- to 8-bit sound that I
mentioned the other day turned out to be an error in SDL_sound.c. When
a conversion was needed, Sound_Decode() would do

     retval *= internal->sdlcvt.len_mult;

which didn't work if the converted audio buffer was shorter than the
original. I've changed this to

     retval = internal->sdlcvt.len_cvt;

which I hope is the Right Thing to do.

I'm a bit nervous about the len_mult and rate_incr parts of
Sound_AudioCVT, but perhaps they're ok. Anyway I don't understand
SDL_sound.c well enough to get rid of them.

TODO

* We really should make sure the filters[] array doesn't overflow.
   I've increased it's size from 10 to 20, but it still makes me
   nervous.

* As Ryan said, even the slow frequency converter leaves a lot to be
   desired. Perhaps we could borrow some from SoX?

* One thing which might be useful would be a way to tell
   Sound_BuildAudioCVT() if the conversion should be optimized for
   sound quality or computation speed.

The patch also includes the fix mentioned earlier to make the
experimental MIDI decoder pick a sensible default format when there's
no desired one. No sense in having an experimental decoder if people
can't experiment with it. :-)

Torbj?rn Andersson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audiocvt.diff.gz
Type: application/x-gzip
Size: 5253 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20011014/245771e7/attachment.gz>

From icculus at clutteredmind.org  Mon Oct 15 03:07:57 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 15 Oct 2001 03:07:57 -0400 (EDT)
Subject: Transplanting SDL_audiocvt.c to SDL_sound
In-Reply-To: <3BC995DA.9070005@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0110150254190.24064-100000@gemini.verizon.net>


> This is a first attempt at transplanting the audio converter from SDL
> to SDL_sound. I've reformatted the code and made some slight
> restructuring, but the only important change is that I've enabled the
> slow rate conversion filter.

It looks good, but I'd like to make an official release before we add the
audio conversion stuff to CVS, so I'll make that release tomorrow...I
_will_ put the midi part of the patch in there before the release, though.

Once I make this release, here's my thoughts on a roadmap for the NEXT
release after that. Some of these are easier than others...
 - Change the API (Ahhhhh!) to allow a decoder to register multiple file
   extensions. This is just some simple reworking.
 - Put a --credits option into playsound that lists SDL_sound contributors
   (you know who you are).
 - ADPCM compression support in wav.c (this covers most compressed .WAV
   files in existance).
 - Make aiff.c capable of handling multiple compression schemes (mostly,
   this involves updating it to match wav.c's changes, I think).
 - Fix mp3.c so it can handle decoding more than one MP3 in a row.
 - Start working on the audio conversion routines.
 - Manpages. I want manpages.
 - Officially declare this ported to MacOS X, if Max feels its ready.

That should be enough to move from 0.1.3 to 0.1.4.  :)

--ryan.




From icculus at clutteredmind.org  Mon Oct 15 17:29:54 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 15 Oct 2001 17:29:54 -0400 (EDT)
Subject: version 0.1.3 ...
Message-ID: <Pine.LNX.4.33L2.0110151727560.9116-100000@gamehenge.icculus.org>


...is on freshmeat.

The audio conversion routines are in CVS. I'm going to attack that ADPCM
decoder for wav.c now.

--ryan.





From max at quendi.de  Mon Oct 15 17:31:01 2001
From: max at quendi.de (Max Horn)
Date: Mon, 15 Oct 2001 23:31:01 +0200
Subject: Transplanting SDL_audiocvt.c to SDL_sound
In-Reply-To: <Pine.LNX.4.33.0110150254190.24064-100000@gemini.verizon.net>
References: <Pine.LNX.4.33.0110150254190.24064-100000@gemini.verizon.net>
Message-ID: <p05101004b7f10607695e@[217.225.196.34]>

At 3:07 Uhr -0400 15.10.2001, Ryan C. Gordon wrote:
>  > This is a first attempt at transplanting the audio converter from SDL
>>  to SDL_sound. I've reformatted the code and made some slight
>>  restructuring, but the only important change is that I've enabled the
>>  slow rate conversion filter.
>
>It looks good, but I'd like to make an official release before we add the
>audio conversion stuff to CVS, so I'll make that release tomorrow...I
>_will_ put the midi part of the patch in there before the release, though.
>
>Once I make this release, here's my thoughts on a roadmap for the NEXT
>release after that. Some of these are easier than others...
>  - Change the API (Ahhhhh!) to allow a decoder to register multiple file
>    extensions. This is just some simple reworking.
>  - Put a --credits option into playsound that lists SDL_sound contributors
>    (you know who you are).
>  - ADPCM compression support in wav.c (this covers most compressed .WAV
>    files in existance).
>  - Make aiff.c capable of handling multiple compression schemes (mostly,
>    this involves updating it to match wav.c's changes, I think).
>  - Fix mp3.c so it can handle decoding more than one MP3 in a row.
>  - Start working on the audio conversion routines.
>  - Manpages. I want manpages.
>  - Officially declare this ported to MacOS X, if Max feels its ready.

I guess we could, but I should first test current CVS...


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890


From torbjorn.e.andersson at tietoenator.com  Tue Oct 16 09:06:16 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Tue, 16 Oct 2001 15:06:16 +0200
Subject: Transplanting SDL_audiocvt.c to SDL_sound
References: <Pine.LNX.4.33.0110150254190.24064-100000@gemini.verizon.net>
Message-ID: <3BCC30C8.5070205@tietoenator.com>

Ryan C. Gordon wrote:

 >  - Fix mp3.c so it can handle decoding more than one MP3 in a row.

Hmm... Never noticed this problem. How do you mean, and how do you 
trigger it? (I tried "playsound first.mp3 second.mp3" without problems.)

Torbj?rn Andersson



From icculus at clutteredmind.org  Tue Oct 16 10:44:19 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 16 Oct 2001 10:44:19 -0400 (EDT)
Subject: Transplanting SDL_audiocvt.c to SDL_sound
In-Reply-To: <3BCC30C8.5070205@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0110161043340.17770-100000@gamehenge.icculus.org>


>  >  - Fix mp3.c so it can handle decoding more than one MP3 in a row.
>
> Hmm... Never noticed this problem. How do you mean, and how do you
> trigger it? (I tried "playsound first.mp3 second.mp3" without problems.)

Hhm...gave me trouble; I'll try to reproduce it later today when I'm at my
own computer.

--ryan.




From icculus at clutteredmind.org  Tue Oct 16 14:34:39 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 16 Oct 2001 14:34:39 -0400 (EDT)
Subject: Transplanting SDL_audiocvt.c to SDL_sound
In-Reply-To: <Pine.LNX.4.33L2.0110161043340.17770-100000@gamehenge.icculus.org>
Message-ID: <Pine.LNX.4.33.0110161428230.7089-100000@gemini.verizon.net>

> Hhm...gave me trouble; I'll try to reproduce it later today when I'm at
> my own computer.

(...and reproduce it I did...)

I tried it with a couple of other MP3s, and it seems to work (that is,
something like "playsound /mp3/albumname/*.mp3" plays through the
directory fine), but here are some that don't:

  http://icculus.org/SDL_sound/downloads/example_sounds/psychoex_01.mp3
  http://icculus.org/SDL_sound/downloads/example_sounds/psychoex_02.mp3

Immediate clue, with DEBUG_CHATTER enabled, is that these files appear to
SMPEG as MPEG-2 layer 3 files (most .mp3 files I tried looked like MPEG-1
to SMPEG). Both play fine by themselves, but not when played together on
the same run of playsound ("playsound psychoex*.mp3").

Not sure the ramifications of this; it might very well be a bug in SMPEG.

Disclaimer, by the way: those MP3s are from the www.psychoexgirlfriend.com
website, and while they don't contain explicit material, they aren't
exactly in good taste, either. You've been warned.  :)

--ryan.




From torbjorn.e.andersson at tietoenator.com  Wed Oct 17 02:37:41 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Wed, 17 Oct 2001 08:37:41 +0200
Subject: playsound bug
Message-ID: <3BCD2735.7050009@tietoenator.com>

There appears to be a bug in playsound's overflow handling in the 
callback function. As long as overflowBytes > 0 it will keep copying the 
same piece of the overflow buffer into the stream.

It can't be very common that the overflow handler comes into play, or 
we'd have noticed it long ago. My test case was the 8-bit mono WAV file 
"cuckoo.wav" from MindRover. Sound_Decode() got a 16KB buffer, so the 
audio callback played the first 4KB right away, and then the next 4KB 
three times until the overflow buffer was drained.

I think the included patch fixes it. Probably won't have any effect on 
the MP3 problem though.

Torbj?rn Andersson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: playsound.diff.gz
Type: application/x-gzip
Size: 457 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20011017/65ccc65d/attachment.gz>

From icculus at clutteredmind.org  Wed Oct 17 04:01:36 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 17 Oct 2001 04:01:36 -0400 (EDT)
Subject: playsound bug
In-Reply-To: <3BCD2735.7050009@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0110170401170.26148-100000@gemini.verizon.net>


> I think the included patch fixes it. Probably won't have any effect on
> the MP3 problem though.

Cool; it's in CVS.

--ryan.




From tsm at accesscomm.ca  Wed Oct 17 18:28:32 2001
From: tsm at accesscomm.ca (Corona688)
Date: Wed, 17 Oct 2001 16:28:32 -0600
Subject: playsound bug
References: <3BCD2735.7050009@tietoenator.com>
Message-ID: <3BCE0610.5BA37826@accesscomm.ca>



Torbj?rn Andersson wrote:

> There appears to be a bug in playsound's overflow handling in the
> callback function. As long as overflowBytes > 0 it will keep copying the
> same piece of the overflow buffer into the stream.
>
> It can't be very common that the overflow handler comes into play, or
> we'd have noticed it long ago. My test case was the 8-bit mono WAV file
> "cuckoo.wav" from MindRover. Sound_Decode() got a 16KB buffer, so the
> audio callback played the first 4KB right away, and then the next 4KB
> three times until the overflow buffer was drained.
>
> I think the included patch fixes it. Probably won't have any effect on
> the MP3 problem though.
>
> Torbj?rn Andersson
>
>   ------------------------------------------------------------------------
>                         Name: playsound.diff.gz
>    playsound.diff.gz    Type: application/x-gzip
>                     Encoding: base64

Brilliant!  This sounds like exactly the same problem I had with the VOC
decoder.



From icculus at clutteredmind.org  Wed Oct 17 19:34:42 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 17 Oct 2001 19:34:42 -0400 (EDT)
Subject: playsound bug
In-Reply-To: <3BCE0610.5BA37826@accesscomm.ca>
Message-ID: <Pine.LNX.4.33L2.0110171933040.31240-100000@gamehenge.icculus.org>


> My test case was the 8-bit mono WAV file "cuckoo.wav" from MindRover.

Btw, that's the exact file I originally used for testing the WAV decoder.
Of course, that was before the overflow buffer was introduced, but oh
well.

Small world.

--ryan.




From torbjorn.e.andersson at tietoenator.com  Tue Oct 23 02:28:26 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Tue, 23 Oct 2001 08:28:26 +0200
Subject: playsound bug
References: <Pine.LNX.4.33L2.0110171933040.31240-100000@gamehenge.icculus.org>
Message-ID: <3BD50E0A.4020901@tietoenator.com>

(Sorry about the belated answer. I was away for a few days, and the 
Internet connection at the office was away for even longer. :-)

Ryan C. Gordon wrote:

 > Btw, that's the exact file I originally used for testing the WAV
 > decoder. Of course, that was before the overflow buffer was
 > introduced, but oh well.
 >
 > Small world.

Heh. That is quite a coincidence.

By the way, it looks as if the playsound patch does fix the MP3 decoder 
problem after all. My only guess is that the overflow buffer wasn't 
(still isn't?) completely drained at the end of the sound, before the 
next sound starts playing. None of the example MP3:s would overflow 
enough to trigger the bug, but when taken together...

Which makes me wonder: Is there anything to prevent the overflow buffer 
from overflowing?

Torbj?rn Andersson



From icculus at clutteredmind.org  Tue Oct 23 08:20:23 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 23 Oct 2001 08:20:23 -0400 (EDT)
Subject: playsound bug
In-Reply-To: <3BD50E0A.4020901@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0110230815420.9411-100000@gemini.verizon.net>


> Which makes me wonder: Is there anything to prevent the overflow buffer
> from overflowing?

static Uint8 overflow[16384]; /* this is a hack. */

Nope.   :)

Actually, is there a good reason to use the overflow buffer at all?
Wouldn't it be better just to keep track of how much more of
sample->buffer needs to be written and memcpy() from there directly?

--ryan.




From torbjorn.e.andersson at tietoenator.com  Tue Oct 23 10:25:26 2001
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Tue, 23 Oct 2001 16:25:26 +0200
Subject: playsound bug
References: <Pine.LNX.4.33.0110230815420.9411-100000@gemini.verizon.net>
Message-ID: <3BD57DD6.8050809@tietoenator.com>

Ryan C. Gordon wrote:

 > Actually, is there a good reason to use the overflow buffer at all?
 > Wouldn't it be better just to keep track of how much more of
 > sample->buffer needs to be written and memcpy() from there directly?

I never even thought of that, but it sounds reasonable. Come to think of 
it, it may even be necessary for the SDL_mixer rewrite you've been 
talking about.

So we'd need either a pointer or an Uint32 to keep track of how much of 
the buffer has been used. Should that be in the Sound_Sample or in the 
Sound_Sample_Internal struct?

Torbj?rn Andersson



From icculus at clutteredmind.org  Tue Oct 23 14:24:08 2001
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 23 Oct 2001 14:24:08 -0400 (EDT)
Subject: the overflow buffer hack...
Message-ID: <Pine.LNX.4.33.0110231423390.10349-100000@gemini.verizon.net>


...has been removed from playsound.c, in CVS.

--ryan.




