From icculus at clutteredmind.org  Tue Jan  1 18:19:12 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 1 Jan 2002 18:19:12 -0500 (EST)
Subject: SDL_sound 0.1.5 milestone goals:
Message-ID: <Pine.LNX.4.33.0201011750320.5113-100000@gemini.verizon.net>


Happy New Year, everyone!

Here's the list of goals for 0.1.5. A lot of these are simple fixes that
have been collecting dust in the TODO file for too long...

- Add the new MIDI decoder that is waiting to be included.
- Add a Sound_Rewind() API. Discussion to follow.
- SMPEG only works after calling SDL_OpenAudio(), but I don't think this
  is a universal truth (i.e. - OpenAL uses it without outputting through
  SDL...) Figure out if this can be fixed.
- Change SMPEG's URL to point to lokigames.com.
- in Sound_NewSample*, if a decoder is selected by file extension and
  fails, it should not be tried again when going through the rest of the
  decoders. Or should we just opt to give up if the specified decoder
  fails?
- Shrink buffer in Sound_DecodeAll to fit exact size of sample after
  decoding.
- Port to BeOS. Getting BeOS up and running is probably harder than
  porting SDL_sound to it, I should think.
- Make Sound_SetError() and Sound_GetError() use their own buffers, so
  they don't piddle over SDL errors, and vice-versa.
- Rename the "test" directory to "playsound".
- Have the default "make" build playsound, and "make install" install it.
- Other bugfixes/enhancements as appropriate.
- Update the Visual C project files.

Anything else worth tackling at this stage? That should keep us pretty busy.

--ryan.




From icculus at clutteredmind.org  Fri Jan  4 01:52:01 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 4 Jan 2002 01:52:01 -0500 (EST)
Subject: MIDI decoder in SDL_sound CVS...
Message-ID: <Pine.LNX.4.33.0201040150120.32666-100000@gemini.verizon.net>


Thanks to Torbjorn, we've got MIDI decoding directly in SDL_sound, using a
heavily-modified version of the heavily-modified version of Timidity from
SDL_mixer.

Works well...thankya.

One thing less for that 0.1.5 release.  :)

--ryan.





From torbjorn.e.andersson at tietoenator.com  Sat Jan  5 11:31:11 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Sat, 05 Jan 2002 17:31:11 +0100
Subject: MIDI decoder in SDL_sound CVS...
References: <Pine.LNX.4.33.0201040150120.32666-100000@gemini.verizon.net>
Message-ID: <3C372A4F.50806@tietoenator.com>

Ryan C. Gordon wrote:

 > Works well...thankya.

In that case I guess the MIDI decoder can move from the "planned" to the 
"working" on the SDL_sound Web page. (And I just realized I forgot to 
patch the SDL_sound TODO file as well. Crud.) Anyway it's a relief to 
finally have it in CVS so that others can point and laugh at what I've 
missed. ;-)

Apart from bugfixes, my primary concern right now is that I'd like for 
it to support the extensions TiMidity++ has made to the config file 
format. Some of them are apparently used by the "Eawpatches" - see 
http://www.stardate.bc.ca/eawpatches/html/default.htm - but I'm not yet 
sure what they do.

Torbj?rn



From torbjorn.e.andersson at tietoenator.com  Mon Jan  7 04:49:52 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Mon, 07 Jan 2002 10:49:52 +0100
Subject: Recent change in SDL_mixer's MikMod decoder
Message-ID: <3C396F40.3060603@tietoenator.com>

I noticed that SDL_mixer recently changed its MikMod decoder to "stop 
implicit looping, fade out and other flags". Is this something we should 
apply to SDL_sound as well? On one hand it could be argued that if 
whoever created the song says it should loop, then it should. On the 
other hand this would not play well with Sound_DecodeAll().

Comments? For whatever it's worth, the XMMS MikMod plugin seems to do 
something similar.

Link to the SDL_mixer patch:

http://www.libsdl.org/cgi/cvsweb.cgi/SDL_mixer/music.c.diff?r1=1.33&r2=1.31

Torbj?rn



From icculus at clutteredmind.org  Mon Jan  7 09:51:35 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 7 Jan 2002 09:51:35 -0500 (EST)
Subject: Recent change in SDL_mixer's MikMod decoder
In-Reply-To: <3C396F40.3060603@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0201070950360.19377-100000@gamehenge.icculus.org>


> Comments? For whatever it's worth, the XMMS MikMod plugin seems to do
> something similar.

Probably not a bad idea.

I'm a little nervous about MikMod's inability to decode two samples at
once. Someone recommended ModPlug to me, but I haven't had a change to
look any closer than that, so this is semi-useless information.  :)

--ryan.





From torbjorn.e.andersson at tietoenator.com  Mon Jan  7 10:28:35 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Mon, 07 Jan 2002 16:28:35 +0100
Subject: Recent change in SDL_mixer's MikMod decoder
References: <Pine.LNX.4.33L2.0201070950360.19377-100000@gamehenge.icculus.org>
Message-ID: <3C39BEA3.2090707@tietoenator.com>

Ryan C. Gordon wrote:

 > I'm a little nervous about MikMod's inability to decode two samples at
 > once.

I was hoping that the SDL_sound decoder would be able to work around any 
such limitations since we only use MikMod to decode the audio, not to 
play it. But I haven't tried it so I don't know if it works. I guess we 
will be running into a few problems like that once the SDL_mixer rewrite 
gets underway...

 > Someone recommended ModPlug to me, but I haven't had a change to
 > look any closer than that, so this is semi-useless information.

I was going to cite licensing problems and lack of library, but it 
appears that this has changed recently. I just saw this on the ModPlug 
XMMS Plugin page at http://modplug-xmms.sourceforge.net/

    + ModPlug rendering engine moved into a separate library --
      libmodplug created.
    + License changed to public domain

So what are the plans for allowing SDL_sound to have more than one 
decoder for a particular type of sound? ;-)

Torbj?rn






From icculus at clutteredmind.org  Mon Jan  7 10:53:21 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 7 Jan 2002 10:53:21 -0500 (EST)
Subject: Recent change in SDL_mixer's MikMod decoder
In-Reply-To: <3C39BEA3.2090707@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0201071048310.28925-100000@gemini.verizon.net>


> So what are the plans for allowing SDL_sound to have more than one
> decoder for a particular type of sound? ;-)

The thought has crossed my mind before, since there's several quality MP3
decoders out there, and some people might prefer one decoder over another.

The question is how to enable that? Should it be a build-time option (you
pick your favorite MP3 decoder, and that gets compiled in), or should they
be choosable by environment option, or whatnot?

SDL_sound can't really pick a best MP3 decoder on the spot, so it'll have
to be a matter of elimination in some form or another...

--ryan.






From torbjorn.e.andersson at tietoenator.com  Tue Jan  8 02:39:54 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Tue, 08 Jan 2002 08:39:54 +0100
Subject: Recent change in SDL_mixer's MikMod decoder
References: <Pine.LNX.4.33.0201071048310.28925-100000@gemini.verizon.net>
Message-ID: <3C3AA24A.1050505@tietoenator.com>

Ryan C. Gordon wrote:

 > The question is how to enable that?

I guess the best way to get the discussion going is to make sure the 
situation can arise in the first place. ;-)

The included patch should:

* Make a few cleanups to the MikMod decoder
* Rename the MikMod decoder mikmod.c instead of mod.c
* Add a ModPlug decoder, modplug.c

The decoders use different prefixes for their functions, so both can be 
built at the same time, though only one of them will be used for a 
particular file type.

The ModPlug decoder is basically a quick hack done too late at night. It 
may be buggy. It certainly doesn't even try to verify that what it's 
trying to play really is a MOD file. In one test I made it tried to 
decode a FLAC file, with less than stellar results. It should probably 
be restricted to only play files with the extensions it knows about.

At the moment all the bells and whistles I could find in ModPlug are 
turned on. We'll need to find a good cost/quality tradeoff. Since I 
don't understand what most of these features are, and my computer 
speakers probably aren't good enough to tell the difference in sound 
quality anyway, I'll gladly leave that to someone else.

Torbj?rn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod.patch.gz
Type: application/x-gzip
Size: 5739 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020108/9d2d2a78/attachment.gz>

From marvin at cyclops.webvision.ch  Tue Jan  8 16:49:33 2002
From: marvin at cyclops.webvision.ch (Andreas Umbach)
Date: Tue, 8 Jan 2002 22:49:33 +0100
Subject: Recent change in SDL_mixer's MikMod decoder
In-Reply-To: <3C396F40.3060603@tietoenator.com>; from torbjorn.e.andersson@tietoenator.com on Mon, Jan 07, 2002 at 10:49:52AM +0100
References: <3C396F40.3060603@tietoenator.com>
Message-ID: <20020108224933.A10709@cyclops.webvision.ch>

On Mon, Jan 07, 2002 at 10:49:52AM +0100, Torbj?rn Andersson wrote:
> I noticed that SDL_mixer recently changed its MikMod decoder to "stop 
> implicit looping, fade out and other flags". Is this something we should 
> apply to SDL_sound as well? On one hand it could be argued that if 
> whoever created the song says it should loop, then it should. On the 
> other hand this would not play well with Sound_DecodeAll().
> 
> Comments? For whatever it's worth, the XMMS MikMod plugin seems to do 
> something similar.

Maybe we could try to get this into libmikmod itself, instead of 'working
around it'. The website looks maintained, and I mailed Miodrag a few times
about two years ago (when libmikmod was still at version 3.1.4), and
he seems very responsive. I'm quite confident he'd accept patches, and roll
out 3.1.10 if necessary.

- Andreas


From torbjorn.e.andersson at tietoenator.com  Wed Jan  9 02:47:58 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Wed, 09 Jan 2002 08:47:58 +0100
Subject: Recent change in SDL_mixer's MikMod decoder
References: <3C396F40.3060603@tietoenator.com> <20020108224933.A10709@cyclops.webvision.ch>
Message-ID: <3C3BF5AE.70401@tietoenator.com>

Andreas Umbach wrote:

 > Maybe we could try to get this into libmikmod itself, instead of
 > 'working around it'.

Since the wrap, loop, etc. variables are documented parameters that 
"control the module playback and can be modified at any time, unless 
otherwise specified", I don't see it as a problem with MikMod. It's just 
that the SDL_mixer developers aren't happy with some of their default 
values.

In fact it looks like some of the variables are set to what would have 
been their default values anyway, so I guess they just wanted to clarify 
those.

Torbj?rn



From torbjorn.e.andersson at tietoenator.com  Wed Jan  9 03:04:22 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Wed, 09 Jan 2002 09:04:22 +0100
Subject: Slight MikMod / ModPlug cleanup
Message-ID: <3C3BF986.7050302@tietoenator.com>

This should keep modplug.c from playing unknown file types, and removes 
some erronous extensions from the list of known ones. (Apparently the 
XMMS plugin handles compressed modules, but libmodplug doesn't.)

For both mikmod.c and modplug.c I've added comments - gleaned from the 
MikMod and ModPlug source - describing what the different file types 
are, and tried to make sure that all the loaders are accounted for. 
There are file types that MikMod handles but ModPlug doesn't, and types 
that ModPlug handles but MikMod doesn't, so perhaps both should be 
enabled by default.

I still don't know how to tell SDL_sound which one to choose in cases 
where a file could be handled by more than one. Perhaps something as 
simple as a configuration file listing all the decoders in the order 
which they should be probed. A default file could be generated at 
compile-time.

Torbj?rn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mikmod.patch.gz
Type: application/x-gzip
Size: 580 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020109/3a00f278/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modplug.patch.gz
Type: application/x-gzip
Size: 1385 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020109/3a00f278/attachment-0001.gz>

From icculus at clutteredmind.org  Wed Jan  9 08:39:01 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 9 Jan 2002 08:39:01 -0500 (EST)
Subject: Slight MikMod / ModPlug cleanup
In-Reply-To: <3C3BF986.7050302@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0201090836250.10978-100000@gemini.verizon.net>


> This should keep modplug.c from playing unknown file types, and removes
> some erronous extensions from the list of known ones. (Apparently the
> XMMS plugin handles compressed modules, but libmodplug doesn't.)

I'm going to look at (and likely, commit to CVS) this code later today.

--ryan.





From icculus at clutteredmind.org  Wed Jan  9 20:35:52 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 9 Jan 2002 20:35:52 -0500 (EST)
Subject: SDL_sound: The ModPlug patches and Sound_Rewind()...
Message-ID: <Pine.LNX.4.33.0201092015350.30634-100000@gemini.verizon.net>


The ModPlug patches are in CVS. Thank you very much.

Now, about this Sound_Rewind() thing, here're my thoughts.

Externally, it's simple:

 /**
  * Restart a sample at the start of its waveform data, as if newly
  *  created with Sound_NewSample(). If successful, the next call to
  *  Sound_Decode[All]() will give audio data from the earliest point
  *  in the stream.
  *
  * Beware that this function will fail if the SDL_RWops that feeds the
  *  decoder can not be rewound via it's seek method, but this can
  *  theoretically be avoided by wrapping it in some sort of buffering
  *  SDL_RWops.
  *
  * If this function fails, the state of the sample is undefined, but it
  *  is still safe to call Sound_FreeSample() to dispose of it.
  *
  *    @param sample The Sound_Sample to rewind.
  *   @return nonzero on success, zero on error. Specifics of the
  *           error can be gleaned from Sound_GetError().
  */
 int Sound_Rewind(Sound_Sample *sample)


Internally, we'd add a new method to Sound_DecoderFunctions called
rewind:

int (*rewind)(Sound_Sample *sample);

Which tells a given decoder to reset itself to the beginning of the
stream. Nonzero on success, zero on failure. If it fails, SDL_sound will
call the decoder's close() method followed by its open() method to attempt
to force a rewind, and failing that will report the problem to the calling
application.

The purpose of the new rewind() method in the decoder is to allow for
higher efficiency than an application could get by just recreating the
sample externally; not only do they not have to reopen the RWops,
reallocate buffers, and potentially pass the data through several
rejecting decoders, but certain decoders will not have to recreate their
existing state (search for metadata, etc) since they already know they
have a valid audio stream with a given set of characteristics.

That's my proposal. Thoughts, additions, flames, and donuts are welcome.

--ryan.




From torbjorn.e.andersson at tietoenator.com  Fri Jan 11 02:45:34 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Fri, 11 Jan 2002 08:45:34 +0100
Subject: SDL_sound: The ModPlug patches and Sound_Rewind()...
References: <Pine.LNX.4.33.0201092015350.30634-100000@gemini.verizon.net>
Message-ID: <3C3E981E.2010101@tietoenator.com>

Ryan C. Gordon wrote:

 > The ModPlug patches are in CVS. Thank you very much.

At the risk of sounding ungrateful, any chance the two cleanup patches 
("Slight MikMod / ModPlug cleanup") could be applied as well? The one 
for ModPlug is the more important of them as it tries to keep ModPlug 
from accepting unknown data, and corrects the list of known file types.

The one for MikMod adds some file types, e.g. UNI. (Uplink uses that 
type, for instance.)

 > Now, about this Sound_Rewind() thing, here're my thoughts.

Sounds good to me.

Torbj?rn



From icculus at clutteredmind.org  Fri Jan 11 06:08:08 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 11 Jan 2002 06:08:08 -0500 (EST)
Subject: SDL_sound: The ModPlug patches and Sound_Rewind()...
In-Reply-To: <3C3E981E.2010101@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0201110606550.24661-100000@gemini.verizon.net>


> At the risk of sounding ungrateful, any chance the two cleanup patches
> ("Slight MikMod / ModPlug cleanup") could be applied as well? The one
> for ModPlug is the more important of them as it tries to keep ModPlug
> from accepting unknown data, and corrects the list of known file types.

Doh...I thought you had resent the whole patch, so I applied the first one
thinking it was the second. It's fixed in CVS, now.

>  > Now, about this Sound_Rewind() thing, here're my thoughts.
>
> Sounds good to me.

I'll wait another day or two for responses, and then proceed.

--ryan.





From icculus at clutteredmind.org  Sun Jan 13 14:51:02 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 13 Jan 2002 14:51:02 -0500 (EST)
Subject: SDL_sound: .AU support...
Message-ID: <Pine.LNX.4.33.0201131449210.14386-100000@gemini.verizon.net>


Support for .AU sound files has been committed to CVS, thanks to a
contribution from Mattias Engdegard.

--ryan.





From icculus at clutteredmind.org  Thu Jan 17 15:59:28 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Thu, 17 Jan 2002 15:59:28 -0500 (EST)
Subject: Sound_Rewind()...
Message-ID: <Pine.LNX.4.33.0201171544260.29367-100000@gemini.verizon.net>


...is implemented. It follows my previous proposal with a few exceptions:
the API docs now explicitly state that there's only two reasons
Sound_Rewind() will fail (RWops can't seek, or SDL_sound isn't
initialized), and if the stream can't seek, SDL_sound won't explicitly try
to close and reopen the stream...we'll leave that for applications that
use non-seekable RWops to deal with as they see fit (buffer the data,
reopen themselves, etc).

Most of the decoders are just stubbed with assertion failures at the
moment. I'll be getting around to filling these in if no one else does so.
(Look for (formatname)_rewind at the end of each decoder's source.)

Ones I've written/tested:
 wav.c (both adpcm and uncompressed)
 aiff.c
 au.c
 raw.c
 skeleton.c  (heh)

Ones I haven't:
 mikmod.c
 ogg.c
 flac.c
 modplug.c
 voc.c
 midi.c
 mp3.c
 shn.c

There's a --loop flag in playsound now for testing this. Beware that the
audio callback got ANOTHER (less severe) rewrite to handle this, so be on
the lookout for bugs there, too.

--loop works with --predecode, too, and won't call Sound_Rewind() on
predecoded (Sound_DecodeAll()) samples.

...make sure to rebuild from scratch after pulling from CVS, since
internal structure sizes have changed.

Comments, suggestions, complaints go to the usual place.

--ryan.




From icculus at clutteredmind.org  Fri Jan 18 20:50:51 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 18 Jan 2002 20:50:51 -0500 (EST)
Subject: SDL_sound and BeOS:
Message-ID: <Pine.LNX.4.33L2.0201182048100.15905-100000@gamehenge.icculus.org>


Once I figured out how to get programs to build on BeOS in the first
place, SDL_sound built and ran without any code modifications.

For once, I actually have something good to say for autoconf/automake.  :)

--ryan.





From icculus at clutteredmind.org  Fri Jan 18 22:13:27 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 18 Jan 2002 22:13:27 -0500 (EST)
Subject: one more SDL_sound thing...
Message-ID: <Pine.LNX.4.33L2.0201182209040.15905-100000@gamehenge.icculus.org>


...I've moved the "test" directory to "playsound", and made playsound part
of the standard build/install.

You might want to do fresh CVS checkouts, to make sure I didn't completely
hose the autoconf/automake config.  :)


This leaves the following items for the 0.1.5 release:

- Implement rewind method in decoders missing it:
    * mikmod.c
    * ogg.c
    * flac.c
    * modplug.c
    * midi.c
    * mp3.c
    * shn.c
- SMPEG only works after calling SDL_OpenAudio(), but I don't think this
  is a universal truth (i.e. - OpenAL uses it without outputting through
  SDL...) Figure out if this can be fixed.
- in Sound_NewSample*, if a decoder is selected by file extension and
  fails, it should not be tried again when going through the rest of the
  decoders. Or should we just opt to give up if the specified decoder
  fails?
- Update the Visual C project files.

--ryan.





From max at quendi.de  Sat Jan 19 06:01:02 2002
From: max at quendi.de (Max Horn)
Date: Sat, 19 Jan 2002 12:01:02 +0100
Subject: README / INSTALL should list requirments
Message-ID: <p05101210b86f0222f385@[217.82.41.56]>

That is, requirments for bootstrap, so it should be in README or 
maybe README.CVS or so.

E.g. you can't run bootstrap w/o FLAC, as I have just found out. Now 
I have to find the URL for that. That's not hard I guess, but if all 
of this was listed in some sort of document, it would be a plus.


Cheers,

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

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


From torbjorn.e.andersson at tietoenator.com  Sat Jan 19 10:31:16 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Sat, 19 Jan 2002 16:31:16 +0100
Subject: one more SDL_sound thing...
References: <Pine.LNX.4.33L2.0201182209040.15905-100000@gamehenge.icculus.org>
Message-ID: <3C499144.9020204@tietoenator.com>

Ryan C. Gordon wrote:

 > - Implement rewind method in decoders missing it:
 >     * mikmod.c
 >     * ogg.c
 >     * flac.c
 >     * modplug.c
 >     * midi.c
 >     * mp3.c
 >     * shn.c

I don't have any shorten files to test with, but this patch ought to do 
it for the other ones.

Hopefully it will also fix a bug in the FLAC decoder which caused the 
last frame to be played twice. I never noticed it before because my 
original FLAC test file faded out to silence.

Torbj?rn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rewind.patch.gz
Type: application/x-gzip
Size: 1924 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020119/6338ed1a/attachment.gz>

From icculus at clutteredmind.org  Sat Jan 19 13:17:49 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sat, 19 Jan 2002 13:17:49 -0500 (EST)
Subject: README / INSTALL should list requirments
In-Reply-To: <p05101210b86f0222f385@[217.82.41.56]>
Message-ID: <Pine.LNX.4.33.0201191314540.23427-100000@gemini.verizon.net>


> E.g. you can't run bootstrap w/o FLAC, as I have just found out. Now
> I have to find the URL for that. That's not hard I guess, but if all
> of this was listed in some sort of document, it would be a plus.

I agree that these external libraries should be listed, but I'd also
rather make it so that FLAC isn't needed at all to run bootstrap. There is
a configure option to disable FLAC support, and otherwise, SDL_sound
isn't dependent upon it being there.

Is there something that should be added to acinclude.m4?

--ryan.




From icculus at clutteredmind.org  Sat Jan 19 13:18:38 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sat, 19 Jan 2002 13:18:38 -0500 (EST)
Subject: one more SDL_sound thing...
In-Reply-To: <3C499144.9020204@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0201191317560.23427-100000@gemini.verizon.net>


>  > - Implement rewind method in decoders missing it:
>  >     * mikmod.c
>  >     * ogg.c
>  >     * flac.c
>  >     * modplug.c
>  >     * midi.c
>  >     * mp3.c
>  >     * shn.c

Cool; added to CVS.

I'll take care of the Shorten decoder.

--ryan.





From torbjorn.e.andersson at tietoenator.com  Sat Jan 19 16:24:49 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Sat, 19 Jan 2002 22:24:49 +0100
Subject: Something MikMod this way comes...
Message-ID: <3C49E421.1030809@tietoenator.com>

It looks like the development of MikMod is picking up some speed. Three 
announcements on the www.mikmod.org Web page this month, and predicted 
release dates for 3.1.10 (Jan 28 2002) and 3.1.11 (March 2002).

Ryan, you've been mentioning problems with the MikMod decoder handling 
more than one module at a time. Is this related to the "ability to have 
several modules in memory (it doesn't work in all cases in the current 
version)" entry in the MikMod TODO, or are there other problems as well? 
This could be a good time to alert them to any problems we may find...

Torbj?rn



From icculus at clutteredmind.org  Sat Jan 19 16:36:04 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sat, 19 Jan 2002 16:36:04 -0500 (EST)
Subject: Something MikMod this way comes...
In-Reply-To: <3C49E421.1030809@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0201191622120.31002-100000@gemini.verizon.net>


> Ryan, you've been mentioning problems with the MikMod decoder handling
> more than one module at a time. Is this related to the "ability to have
> several modules in memory (it doesn't work in all cases in the current
> version)" entry in the MikMod TODO, or are there other problems as well?
> This could be a good time to alert them to any problems we may find...

My concern is the global variables that control MikMod's behaviour.

For example, md_mixfreq. If I've got two MODs playing at once that want
different sample rates, I've got to convert at least one of them, which is
a needless expense, since that variable could have just as easily been a
part of the MODULE structure. There are other variables that are more
problematic than this one, if I recall correctly.

I haven't looked closely at it recently, but I was under the impression
that this is a problem that will require API breakage in MikMod to
correct. I'd just as soon make ModPlug the default (or at least, list it
before MikMod so it picks up most of the MODs) and not worry about it.

Other stuff:
 - shn.c has a (very hacky) rewind method, which is good enough for now.
 - The need to call SDL_OpenAudio before using SMPEG to decode can't be
   avoided, since SMPEG relies on SDL_MixAudio(), and that function needs
   an audio device spec to mix to. The most ideal solutions are to either
   add a function to SMPEG to decode without mixing (since we're just
   "mixing" with a buffer of silence everytime, this would fix the
   problem AND cut down some overhead, too), or add an mpglib decoder to
   SDL_sound (which I'd like to do eventually, but I'm not tackling it
   right now). Realistically, it's not a problem, since I presume anyone
   using SDL_sound will be using SDL for audio output, too, but it bothers
   me anyhow.  :)

--ryan.





From icculus at clutteredmind.org  Sun Jan 20 16:06:25 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 20 Jan 2002 16:06:25 -0500 (EST)
Subject: README / INSTALL should list requirments
In-Reply-To: <p05101210b86f0222f385@[217.82.41.56]>
Message-ID: <Pine.LNX.4.33.0201201603420.14175-100000@gemini.verizon.net>


> E.g. you can't run bootstrap w/o FLAC, as I have just found out. Now
> I have to find the URL for that. That's not hard I guess, but if all
> of this was listed in some sort of document, it would be a plus.

I've added the information to the README (which is slowly becoming worth
reading  :)  ).

bootstrap ran fine without FLAC here when I just tried it...can you tell
me what specifically is causing problems and/or which part of bootstrap
is failing?

--ryan.




From torbjorn.e.andersson at tietoenator.com  Mon Jan 21 12:14:30 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn?= Andersson)
Date: Mon, 21 Jan 2002 18:14:30 +0100
Subject: README / INSTALL should list requirments
References: <Pine.LNX.4.33.0201201603420.14175-100000@gemini.verizon.net>
Message-ID: <3C4C4C76.2010002@tietoenator.com>

Ryan C. Gordon wrote:

 > bootstrap ran fine without FLAC here when I just tried it...can you
 > tell me what specifically is causing problems and/or which part of
 > bootstrap is failing?

I don't know what Max's problem with bootstrap is, but I know I always 
get a warning message about FLAC__stream_decoder_new. (I don't remember 
the exact wording, but I could look it up later if you want.)

It seems harmless enough though; I certainly don't have any problems 
building it afterwards, so I assumed it was autoconf stupidly assuming 
that anything that looks like AC_* has to be an unexpanded autoconf 
macro or some such.

Torbj?rn



From icculus at clutteredmind.org  Wed Jan 23 12:53:47 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 23 Jan 2002 12:53:47 -0500 (EST)
Subject: Looking for Visual C volunteers...
Message-ID: <Pine.LNX.4.33.0201231249150.16561-100000@gemini.verizon.net>


I'm looking for a kind soul to update SDL_sound's Visual C project files.

The project was ported to Visual C a revision or two ago, but I'd like to
get it updated to handle the new source tree layout, add the new decoders
to the project files, and maybe figure out the cleanest way to handle the
optional external library dependencies.

What I've got from the previous revision is available at:
   http://icculus.org/SDL_sound/downloads/SDL_sound_win32.zip

The project itself is at:
   http://icculus.org/SDL_sound/

Any volunteers?

Thanks,
--ryan.





From max at quendi.de  Wed Jan 23 14:31:34 2002
From: max at quendi.de (Max Horn)
Date: Wed, 23 Jan 2002 20:31:34 +0100
Subject: FLAC bootstrap problem (was: README / INSTALL should list
 requirments)
In-Reply-To: <3C4C4C76.2010002@tietoenator.com>
References: <Pine.LNX.4.33.0201201603420.14175-100000@gemini.verizon.net>
 <3C4C4C76.2010002@tietoenator.com>
Message-ID: <p05101205b874bf807217@[217.82.34.245]>

At 18:14 Uhr +0100 21.01.2002, Torbj?rn Andersson wrote:
>Ryan C. Gordon wrote:
>
>>  bootstrap ran fine without FLAC here when I just tried it...can you
>>  tell me what specifically is causing problems and/or which part of
>>  bootstrap is failing?
>
>I don't know what Max's problem with bootstrap is, but I know I 
>always get a warning message about FLAC__stream_decoder_new. (I 
>don't remember the exact wording, but I could look it up later if 
>you want.)

What I get is this:

autoconf: Undefined macros:
configure.in:159:  AC_CHECK_LIB(FLAC, FLAC__stream_decoder_new, 
have_flac_lib=yes)

Diagnosis: the "AC_" in FLAC__stream_decoder_new is seen by the 
autoconf parser, with then tries to find a matching macro (stupid, I 
know, which of course is not going to work. So if I change the 
offending line to

   AC_CHECK_LIB(FLAC, FLA__stream_decoder_new, have_flac_lib=yes)

autoconf stops to complain, but of course the check is not valid this way.



>It seems harmless enough though; I certainly don't have any problems 
>building it afterwards, so I assumed it was autoconf stupidly 
>assuming that anything that looks like AC_* has to be an unexpanded 
>autoconf macro or some such.

Exactly. Still, this should be fixed in the script. I'll look into it 
and fix it CVS if I can.


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

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


From max at quendi.de  Wed Jan 23 15:00:33 2002
From: max at quendi.de (Max Horn)
Date: Wed, 23 Jan 2002 21:00:33 +0100
Subject: Problems with timidity
Message-ID: <p05101206b874c3ba6fa9@[217.82.34.245]>

I get this when I try to compile current SDL_sound:

[...]

cc -DHAVE_CONFIG_H -I. -I../../../SDL_sound/decoders -I.. 
-I../../../SDL_sound -Itimidity -g -O2 -I/sw/include 
-I/sw/include/SDL -D_THREAD_SAFE 
-F/System/Library/Frameworks/Carbon.framework 
-F/System/Library/Frameworks/Cocoa.framework -I/sw/include 
-I/sw/include/smpeg -I/sw/include -I/sw/include/SDL -D_THREAD_SAFE 
-F/System/Library/Frameworks/Carbon.framework 
-F/System/Library/Frameworks/Cocoa.framework -I/sw/include 
-D_REENTRANT -c ../../../SDL_sound/decoders/midi.c 
-Wp,-MD,.deps/midi.TPlo  -fno-common -DPIC -o .libs/midi.lo
../../../SDL_sound/decoders/midi.c:47: header file 'timidity.h' not found
../../../SDL_sound/decoders/midi.c:94: undefined type, found `MidiSong'

[...a couple of dozen similiar errors].


The reason it doesn't find timidity.h is that I am not building 
inside my CVS dir, but inside a seperate build directory (that's very 
nice if you e.g. want multiple different builds with different 
paramaters).

So if you look at that build statments, it has "-Itimidity" which of 
course is not going to work in my case. You should never write 
something as what is in the current decoders/Makefile.am:

INCLUDES = -I$(top_srcdir) -Itimidity

This is bad.  Instead use:

INCLUDES = -I$(top_srcdir) -I$(top_srcdir)/decoders/timidity


I fixed this in CVS, but wanted to report it here anyway for future 
use :) Oh and for the CHANGELOG: we now have 2002, I fixed some 
entries accordingly.

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

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


From icculus at clutteredmind.org  Wed Jan 23 15:44:12 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 23 Jan 2002 15:44:12 -0500 (EST)
Subject: Problems with timidity
In-Reply-To: <p05101206b874c3ba6fa9@[217.82.34.245]>
Message-ID: <Pine.LNX.4.33L2.0201231543340.30838-100000@gamehenge.icculus.org>


> I fixed this in CVS, but wanted to report it here anyway for future
> use :) Oh and for the CHANGELOG: we now have 2002, I fixed some
> entries accordingly.

(I'll probably be writing 2001 until at least 2004.  :)  )

Thank you for the fixes, Max.

--ryan.





From tsm at accesscomm.ca  Sat Jan 26 15:28:27 2002
From: tsm at accesscomm.ca (Corona688)
Date: Sat, 26 Jan 2002 14:28:27 -0600
Subject: [SDL] Looking for Visual C volunteers...
References: <Pine.LNX.4.33.0201231249150.16561-100000@gemini.verizon.net>
Message-ID: <3C53116B.668FB65F@accesscomm.ca>

"Ryan C. Gordon" wrote:

> I'm looking for a kind soul to update SDL_sound's Visual C project files.
>
> The project was ported to Visual C a revision or two ago, but I'd like to
> get it updated to handle the new source tree layout, add the new decoders
> to the project files, and maybe figure out the cleanest way to handle the
> optional external library dependencies.
>
> What I've got from the previous revision is available at:
>    http://icculus.org/SDL_sound/downloads/SDL_sound_win32.zip
>
> The project itself is at:
>    http://icculus.org/SDL_sound/
>
> Any volunteers?
>
> Thanks,
> --ryan.
>
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl

I've been busy for awhile, guess I let it slide, sorry.  I'll try and update
the VisualC project.



From icculus at clutteredmind.org  Sat Jan 26 16:28:28 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sat, 26 Jan 2002 16:28:28 -0500 (EST)
Subject: [sdlsound] Re: [SDL] Looking for Visual C volunteers...
In-Reply-To: <3C53116B.668FB65F@accesscomm.ca>
Message-ID: <Pine.LNX.4.33L2.0201261617530.3562-100000@gamehenge.icculus.org>



> I've been busy for awhile, guess I let it slide, sorry.  I'll try and
> update the VisualC project.

Wait! Someone else said they were tackling it. His name is Martin Kalitis.

I'm CC'ing him, so y'all can decide what the current status is...

--ryan.




