From icculus at clutteredmind.org  Thu Apr  4 08:42:36 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Thu, 4 Apr 2002 08:42:36 -0500 (EST)
Subject: SDL_Sound (improvements?) (fwd)
Message-ID: <Pine.LNX.4.33L2.0204040841500.5786-101000@gamehenge.icculus.org>


I haven't looked at the code at all, yet, but here's something that was
sent to me.

--ryan.


---------- Forwarded message ----------
Date: 30 Mar 2002 20:40:59 +0100
From: Matej Knopp <knopp at users.sourceforge.net>
To: Ryan C. Gordon <icculus at clutteredmind.org>
Subject: SDL_Sound (improvements?)


Hi.

Some time ago I wrote you about a bug in SDL_Sound 0.1.4 (As far as I
remember) and asked you whether you were planning to add support for
custom loaders. Your answer was negative and I needed some layer
similiar to SDL_Sound with support for custom loaders and slightly
different design (mostly concerning the difference between streamed and
not streamed samples). This has lead me to writing it on my own (I know
that the code duplicating is not a good thing to do). It wasn't meant to
be another library I just wanted to make it a part of my wrapper (SEL).
The problem is that I've no time to finish the release. The code has
been lying on my hdd for some time without doing any good so I decided
to bother you a bit sending you the code (LGPL) to look whether it
(perhaps) does contain something usefull for SDL_Sound.

Last release of SDL_Sound I've seen was ~ 0.1.5 so some notes below may
be inacurrate.

The design of Sound Interface (SI) differs from SDL_Sound a bit. It has
support for adding user loaders and changing the priority of loaders, so
you can for example give the ModPlug loader higher prority than the
MikMod loader and automatically play all the modules with ModPlug. Also
there is a difference between streamable sounds (music) and "one shot"
samples. SI also support parameters for loaders, so for instance you can
set the audio format for the raw files (see loader-raw.c) or maybe the
flags for modules. (The loader for modules does not exist yet and
probably it will never exist, because of the lack of time)

Now what the files contain:

gem-list.[ch] - The double linked list similiar to the one from GLib.
              - Perhaps the copyright of glib should be added?
loader-raw.c  - The RAW file loader.
loader-wav.c  - The WAVE file loader. Supports _both_ MS ADPCM and
                IMA_ADPMC. It's in fact your wave loader cleaned,
                extended and optimized. AFAIK in SDL_Sound 0.1.5 you
                were loading the MS ADPCM wavs byte by byte and that
                was slower than playing MP3's on some computers.
                This loader buffers the MS ADPCM blocks.
si-audiocvt.c - Fixed SDL Audio Converter. I've contacted Sam Lantinga
                describing him the bug in SDL Audio C. concerning
                the incorrect order of conversions and bug in 16 bit
                mono -> stereo conversion...
si-config.h   - The config file that duplicates some SDL features when
                SDL is not used (The SI is supposed to work even without
                SDL) It also contains a primitive memory tracking
                facilities. (To assure that there are no leaks in SI :)
si.h          - The main public header.
si-internal.h - The public header for creating user loaders.
si-main.c     - The SI core implementation.


That should be all. Maybe you will find something usefull in SI for
SDL_Sound.

bye.

-Matej Knopp


P.S. The speed of ADPCM decoding:
I've tested the ADPCM decoding and compared it Microsoft MediaPlayer and
the (innacurate) results are that on DURON 850 SI is faster than
Mplayer, but on Pentium 233 MMX the Mplayer is almost twice (5% compared
to 8% - 9% of the cpu usage) that fast than SI. Do you know about any
other possible optimizations ?  (Except rewriting it in assembly :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sound.tar.gz
Type: application/x-gzip
Size: 18552 bytes
Desc: 
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020404/efb625d3/attachment.gz>

From torbjorn.e.andersson at tietoenator.com  Thu Apr  4 09:05:35 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn_Andersson?=)
Date: Thu, 04 Apr 2002 16:05:35 +0200
Subject: [sdlsound] SDL_Sound (improvements?) (fwd)
References: <Pine.LNX.4.33L2.0204040841500.5786-101000@gamehenge.icculus.org>
Message-ID: <3CAC5DAF.3030705@tietoenator.com>

Ryan C. Gordon wrote:

 > I haven't looked at the code at all, yet,

Me neither, but...

Matej Knopp wrote:

 > The design of Sound Interface (SI) differs from SDL_Sound a bit. It
 > has support for adding user loaders and changing the priority of
 > loaders, so you can for example give the ModPlug loader higher prority
 > than the MikMod loader and automatically play all the modules with
 > ModPlug.

That's an idea I've been toying with, so far without any attempt of 
actually implementing it. I tentatively decided that it wouldn't be all 
that useful as long as SDL_sound still requires all the external 
libraries the compiled loaders depend on (e.g. both libmikmod and 
libmodplug).

I guess it would be possible, on some platforms at least, to have the 
loader dlopen() the required libraries as needed. But I've never 
actually tried that so I don't know how big a can of worms that would 
open up.

Torbj?rn Andersson



From torbjorn.e.andersson at tietoenator.com  Mon Apr  8 02:36:28 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn_Andersson?=)
Date: Mon, 08 Apr 2002 08:36:28 +0200
Subject: playsound crash (PhysicsFS-related)
Message-ID: <3CB13A6C.9030906@tietoenator.com>

I noticed that if SDL_sound is compiled with PhysicsFS support, 
playsound will crash after playing a file, at least if it isn't part of 
an archive file.

This is because PHYSFS_deinit() is being called without a corresponding 
call to PHYSFS_init(). I think the actual crash happens because 
PhysicsFS's findErrorForCurrentThread() tries to grab the errorLock 
mutex, which hasn't been created at this stage.

I used yesterday's CVS snapshots of both SDL_sound and PhysicsFS.

Torbj?rn



From icculus at clutteredmind.org  Mon Apr  8 09:36:43 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 8 Apr 2002 09:36:43 -0400 (EDT)
Subject: [sdlsound] playsound crash (PhysicsFS-related)
In-Reply-To: <3CB13A6C.9030906@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0204080935450.5999-100000@gamehenge.icculus.org>


> This is because PHYSFS_deinit() is being called without a corresponding
> call to PHYSFS_init(). I think the actual crash happens because
> PhysicsFS's findErrorForCurrentThread() tries to grab the errorLock
> mutex, which hasn't been created at this stage.

This is due to cruddy behaviour in both physfs and playsound. I've fixed
both in CVS, now.

Thanks,
--ryan.




From marvin at cyclops.webvision.ch  Tue Apr 16 09:40:41 2002
From: marvin at cyclops.webvision.ch (Andreas Umbach)
Date: Tue, 16 Apr 2002 15:40:41 +0200
Subject: [sdlsound] Cross-compiling?
Message-ID: <20020416154041.A18074@cyclops.webvision.ch>

> > Has anybody attempted to cross-compile SDL_sound and some of it's support
> > libs yet?
> 
> I just made a very quick attempt. Read below.
>
> .....
>
> Running cross-make.sh, I got a clean build, but it refused to link without
> a win32 version of SDL installed (which I didn't have).
> 
> In short, with the right libraries available, this probably works, and the
> base library and built-in decoders seem to build.

I tried this, and at first configure refused to build shared libraries.
After adding AC_LIBTOOL_WIN32_DLL to configure.in I get the following:

/bin/sh ./libtool --mode=link i386-mingw32msvc-gcc  -g -O0 -Werror -I/usr/local/cross-tools/i386-mingw32msvc/include -I/usr/local/cross-tools/i386-mingw32msvc/include/SDL -Dmain=SDL_main  -o libSDL_sound.la -rpath /usr/local/cross-tools/i386-mingw32msvc/lib -release 0.1          -version-info 5:0:0 SDL_sound.lo extra_rwops.lo audio_convert.lo decoders/libdecoders.la                decoders/timidity/libtimidity.la decoders/mpglib/libmpglib.la -L/usr/local/cross-tools/i386-mingw32msvc/lib -lmingw32 -lSDLmain -lSDL -mwindows
./libtool: test: =: unary operator expected
./libtool: test: !=: unary operator expected
./libtool: test: !=: unary operator expected
./libtool: test: =: unary operator expected
./libtool: test: !=: unary operator expected
./libtool: test: !=: unary operator expected
libtool: link: warning: undefined symbols not allowed in i386-pc-mingw32msvc shared libraries

And after that, cross-make.sh complete, but no shared libraries are built.

Any idea how to get this to work?

- Andreas


From icculus at clutteredmind.org  Wed Apr 17 01:41:39 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 17 Apr 2002 01:41:39 -0400 (EDT)
Subject: Sound_seek()?
Message-ID: <Pine.LNX.4.33L2.0204170138200.12824-100000@gamehenge.icculus.org>


(Partially in reference to the Mikmod talk on SDL's mailing list...)

...should we add a Sound_seek() function? My thought is that decoders can
optimize this is possible, and if not, the library can attempt to decode
and throw away to a given point if seeking forward, or try rewind()ing
followed by decoding to a given point if seeking back.

Is this worth it?

--ryan.





From icculus at clutteredmind.org  Wed Apr 17 01:47:09 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 17 Apr 2002 01:47:09 -0400 (EDT)
Subject: [sdlsound] Cross-compiling?
In-Reply-To: <20020416154041.A18074@cyclops.webvision.ch>
Message-ID: <Pine.LNX.4.33L2.0204170141510.12824-100000@gamehenge.icculus.org>


> I tried this, and at first configure refused to build shared libraries.
> After adding AC_LIBTOOL_WIN32_DLL to configure.in I get the following:
>
> /bin/sh ./libtool --mode=link i386-mingw32msvc-gcc  -g -O0 -Werror -I/usr/local/cross-tools/i386-mingw32msvc/include -I/usr/local/cross-tools/i386-mingw32msvc/include/SDL -Dmain=SDL_main  -o libSDL_sound.la -rpath /usr/local/cross-tools/i386-mingw32msvc/lib -release 0.1          -version-info 5:0:0 SDL_sound.lo extra_rwops.lo audio_convert.lo decoders/libdecoders.la                decoders/timidity/libtimidity.la decoders/mpglib/libmpglib.la -L/usr/local/cross-tools/i386-mingw32msvc/lib -lmingw32 -lSDLmain -lSDL -mwindows
> ./libtool: test: =: unary operator expected
> ./libtool: test: !=: unary operator expected
> ./libtool: test: !=: unary operator expected
> ./libtool: test: =: unary operator expected
> ./libtool: test: !=: unary operator expected
> ./libtool: test: !=: unary operator expected
> libtool: link: warning: undefined symbols not allowed in i386-pc-mingw32msvc shared libraries
>
> And after that, cross-make.sh complete, but no shared libraries are built.
>
> Any idea how to get this to work?

The unary operator stuff always happens, cross compile or not.

I'm googling around. Perhaps remove the -fPIC compiler option?

More likely:
  http://mail.gnu.org/pipermail/libtool/2000-July/001770.html

Add -no-undefined to the libtool command line.

--ryan.





From icculus at clutteredmind.org  Wed Apr 17 01:54:45 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 17 Apr 2002 01:54:45 -0400 (EDT)
Subject: [sdlsound] Sound_seek()?
In-Reply-To: <Pine.LNX.4.33L2.0204170138200.12824-100000@gamehenge.icculus.org>
Message-ID: <Pine.LNX.4.33L2.0204170147511.12824-100000@gamehenge.icculus.org>


> ...should we add a Sound_seek() function? My thought is that decoders can
> optimize this is possible, and if not, the library can attempt to decode
> and throw away to a given point if seeking forward, or try rewind()ing
> followed by decoding to a given point if seeking back.

To clarify my own post:

  Unlike Sound_rewind(), there is more involved in seeking than just
having a RWops that can seek, and thus, some decoders may find it
hard/impossible to seek accurately or at all, but (assuming Sound_Rewind()
works) we can always fake it by decoding from the stream and just
throwing the decoded contents away until we get to the byte position
we want...this can be a potentially huge performance cost, and I'm
inclined to have such drivers report a failure to the application, which
should fully expect such a possibility.

It is also possible that we can put some of those bits we're using for
Sound_Sample->flags to use. Once the user calls Sound_NewSample(), they
could check a hypothetical flag:

  (returnedSample->flags & SOUND_SAMPLEFLAG_CANSEEK)

Or something.

Again, let me know if this is completely retarded.

--ryan.





From torbjorn.e.andersson at tietoenator.com  Wed Apr 17 02:49:07 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn_Andersson?=)
Date: Wed, 17 Apr 2002 08:49:07 +0200
Subject: [sdlsound] Sound_seek()?
References: <Pine.LNX.4.33L2.0204170147511.12824-100000@gamehenge.icculus.org>
Message-ID: <3CBD1AE3.4060609@tietoenator.com>

 > Unlike Sound_rewind(), there is more involved in seeking than just
 > having a RWops that can seek, and thus, some decoders may find it
 > hard/impossible to seek accurately or at all, but (assuming
 > Sound_Rewind() works) we can always fake it by decoding from the
 > stream and just throwing the decoded contents away until we get to the
 > byte position we want...this can be a potentially huge performance
 > cost, and I'm inclined to have such drivers report a failure to the
 > application, which should fully expect such a possibility.

Sounds reasonable. I could take a look at the decoders I'm responsible 
for and see if it looks easy to add.

A few random questions:

Should Sound_seek() only allow absolute positioning, or should it be 
analogous to fseek()'s SEEK_SET / SEEK_CUR / SEEK_END? (SEEK_END would 
probably be pretty useless, right?)

Should the seek position be a sample count or a time?

Should there be a Sound_tell()?

Torbj?rn
-- 
TietoEnator Resource Management AB
Persona
Torbj?rn Andersson
http://www.rm.tietoenator.com/



From torbjorn.e.andersson at tietoenator.com  Thu Apr 18 02:23:33 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn_Andersson?=)
Date: Thu, 18 Apr 2002 08:23:33 +0200
Subject: [sdlsound] Sound_seek()?
References: <Pine.LNX.4.33L2.0204170147511.12824-100000@gamehenge.icculus.org>
Message-ID: <3CBE6665.3000008@tietoenator.com>

I've looked through - briefly - the decoders I feel responsible for, and 
this is what I found:

ModPlug
=======

There is a ModPlug_Seek() function which should work, though the 
documentation warns that it's not always accurate and some mods will be 
missing instruments for a short time after a seek.

The seek argument is time, in milliseconds.

MikMod
======

There is a Player_SetPosition() function, but I'm uncertain what the 
argument to it really means. It is what SDL_mixer uses to implement 
Mix_SetMusicPosition() though.

AIFF
====

I'll just assume this will be handled the same way as the WAV decoder, 
so I'll worry about that later. :-)

FLAC
====

FLAC 1.0.1 added a "seekable stream decoder" in addition to the already 
present stream and file decoders. This sounds like it should be possible 
to use, but I'd have to do some experimenting to tell.

The seek argument to FLAC__seekable_stream_decoder_set_absolute() is, 
apparently, a sample count.

MIDI (TiMidity)
===============

There is a skip_to() function which ought to work, but - again - I'd 
have to experiment to say for certain.

The seek argument appears to be a time value.

Torbj?rn
-- 
TietoEnator Resource Management AB
Persona
Torbj?rn Andersson
http://www.rm.tietoenator.com/



From icculus at clutteredmind.org  Sun Apr 21 13:29:27 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 21 Apr 2002 13:29:27 -0400 (EDT)
Subject: [sdlsound] Sound_seek()?
In-Reply-To: <3CBE6665.3000008@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0204211259230.21369-100000@gamehenge.icculus.org>


> I've looked through - briefly - the decoders I feel responsible for, and
> this is what I found:

I think adding a Sound_Seek() call is reasonable, then.

I'll probably specify the new position in milliseconds (since it's easy
enough to convert to an absolute byte position from there if need be). I
don't want to mess with SEEK_SET, SEEK_CUR and SEEK_END; I'd say just
specify in milliseconds from start of audio stream.

My decoder list:
  - WAV (and AIFF): I think ADPCM actually compresses to an exact
    ratio, so we can just skip X bytes in the stream and continue
    decoding without trouble. Other compression schemes may be more
    problematic, but I'm willing to flag them as unseekable. Regular WAV
    and AIFF is just a direct seek to byte position.
  - OGG: ov_raw_seek(). No problem.
  - SMPEG: This can be done with a mixture of SMPEG_rewind() and SMPEG_skip().
  - VOC: VOCs are always uncompressed, so it wouldn't be hard to do this one.
  - RAW: Well, duh.
  - MPGLIB: I'll see what exactly SMPEG does internally, but mpglib
    doesn't have this functionality. It might be a matter of manually
    locating the correct MP3 frame, and continuing to feed MPGLIB from
    there, since it shouldn't really care. For now, I'll flag this one as
    unseekable.
  - SHN: Some SHNs keep a seek table at the end of the file, some don't.
    Some SHNs will be seekable, then.

Other thoughts:
  - FLAC: if the library version in use doesn't have
    FLAC__seekable_stream_decoder_set_absolute, which we can determine
    with autoconf, flag the Sample as unseekable.
  - AU: Same deal as WAV. 8-bit muLaw compresses in a 1-to-2 ratio, so we
    can seek to an exact byte position and keep decoding as if nothing
    happened.

Generally I don't see any of these as show-stoppers. Sound_Seek() is most
useful for either looping audio with an arbitrary start point (almost
certainly for a game, in which case, the developer can dictate the file
format), or something like a XMMS plugin, where disabling seek control
and/or reporting an error to the user is acceptable.

I'll add the API and fill in stubs for the decoders later on.

--ryan.




From icculus at clutteredmind.org  Sun Apr 21 14:48:09 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 21 Apr 2002 14:48:09 -0400 (EDT)
Subject: Sound_Seek() framework in place.
Message-ID: <Pine.LNX.4.33L2.0204211440300.22897-100000@gamehenge.icculus.org>


Ah, what the heck...I put the seek framework in place, so we just need to
fill in drivers now.

The only one that implements the seek at the moment is raw.c. Things worth
noting:

- decoders that can seek should set SOUND_SAMPLEFLAG_CANSEEK flag when
creating a new sample. This can be set on a per-sample basis (i.e. - I can
seek in this SHN, since it has a seek table, but not this one, since it
doesn't...)
- decoders should try to retain a sane state if seek method fails (i.e. -
next decode should continue as if nothing happened, if at all
possible...don't set SOUND_SAMPLEFLAG_ERROR unless something catastrophic
happened).
- There's a convenience function: __Sound_convertMsToBytePos() to convert
milliseconds to an absolute byte position based on a Sound_AudioInfo
structure.  raw.c uses this.
- All of this is completely untested.  :) I've just done a quick compile
and that's all.

I'll be filling in decoder-specific seek implementations sooner or later,
(starting with my own decoders) but others are welcome to tackle these
first.

--ryan.





From torbjorn.e.andersson at tietoenator.com  Tue Apr 23 02:25:08 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn_Andersson?=)
Date: Tue, 23 Apr 2002 08:25:08 +0200
Subject: [sdlsound] Sound_Seek() framework in place.
References: <Pine.LNX.4.33L2.0204211440300.22897-100000@gamehenge.icculus.org>
Message-ID: <3CC4FE44.8050308@tietoenator.com>

Ryan C. Gordon wrote:

 > I'll be filling in decoder-specific seek implementations sooner or
 > later, (starting with my own decoders) but others are welcome to
 > tackle these first.

I think I have the ModPlug and Timidity decoders working now, in which 
case they're utterly trivial. I'll submit a patch when the FLAC decoder 
(slightly less trivial) works. I'm not sure what to do about the MikMod 
decoder though. Does anyone here understand what Player_SetPosition() is 
supposed to do?

Torbj?rn
-- 
TietoEnator Resource Management AB
Persona
Torbj?rn Andersson
http://www.rm.tietoenator.com/



From torbjorn.e.andersson at tietoenator.com  Wed Apr 24 03:33:35 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn_Andersson?=)
Date: Wed, 24 Apr 2002 09:33:35 +0200
Subject: [sdlsound] Sound_Seek() framework in place.
References: <Pine.LNX.4.33L2.0204211440300.22897-100000@gamehenge.icculus.org>
Message-ID: <3CC65FCF.2030701@tietoenator.com>

I've split up my changes into what I hope are manageable chunks.

bugfix.diff fixes a logical error in SDL_sound.c. (When trying to clear 
individual sample flags it would actually clear them all.)

flac.diff implements seeking for the FLAC decoder. Annoyingly, libFLAC 
needs to know the total length of the undecoded stream, and the only way 
I can think of to find that out is to do an SDL_RWseek(rw, 0, SEEK_END) 
and see where that puts me, clearing the CANSEEK flag if it fails. I'm 
not entirely happy about this. The autoconf stuff would probably benefit 
if someone who knows what he's doing would take a look at it, as well.

midi.diff and modplug.diff implements seeking for the TiMidity and 
ModPlug decoders respectively.

mikmod.diff completely fails to implement seeking for the MikMod 
decoder, but is still important because the unpatched version _thinks_ 
it can seek.

playsound.diff adds a --skip option, which is what I used for testing 
this stuff so perhaps it'll be useful to others as well.

Torbj?rn
-- 
TietoEnator Resource Management AB
Persona
Torbj?rn Andersson
http://www.rm.tietoenator.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugfix.diff.gz
Type: application/x-gzip
Size: 470 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020424/87779692/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flac.diff.gz
Type: application/x-gzip
Size: 4056 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020424/87779692/attachment-0001.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: midi.diff.gz
Type: application/x-gzip
Size: 743 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020424/87779692/attachment-0002.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mikmod.diff.gz
Type: application/x-gzip
Size: 560 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020424/87779692/attachment-0003.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modplug.diff.gz
Type: application/x-gzip
Size: 534 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020424/87779692/attachment-0004.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: playsound.diff.gz
Type: application/x-gzip
Size: 913 bytes
Desc: not available
URL: <http://icculus.org/pipermail/sdlsound/attachments/20020424/87779692/attachment-0005.gz>

From icculus at clutteredmind.org  Wed Apr 24 03:42:11 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 24 Apr 2002 03:42:11 -0400 (EDT)
Subject: [sdlsound] Sound_Seek() framework in place.
In-Reply-To: <3CC65FCF.2030701@tietoenator.com>
Message-ID: <Pine.LNX.4.33.0204240334310.2433-100000@gemini.verizon.net>


> playsound.diff adds a --skip option, which is what I used for testing
> this stuff so perhaps it'll be useful to others as well.

I'm actually ripping up playsound to make the command line stuff more
powerful (so arguments like --rate work on a per-file basis, --loop takes
a number for the amount of times to loop, etc). One of the things I've
implemented is a --seek, like this:

   playsound --seek "0:15;8:22;2:30" myfile.wav

...which would seek 15 seconds into myfile.wav, play it for 8 minutes and
22 seconds, and then seek to the 2 minute, 30 second mark and play until
the end of the file.

You can get really fancy and put a --loop in there, too. If this keeps up,
playsound is going to become sentient take over the world.

The rest of the patches I'll look at in the morning, and I'll make sure I
haven't broken everything horribly before committing them.

As always, thanks for taking care of this.

--ryan.




From icculus at clutteredmind.org  Wed Apr 24 16:44:25 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 24 Apr 2002 16:44:25 -0400 (EDT)
Subject: The seek patches...
Message-ID: <Pine.LNX.4.33.0204241643140.20801-100000@gemini.verizon.net>


...are in CVS. I'm rather pleased with how this is turning out.

Btw, Torbjorn, do you want CVS write access? You submit patches more
frequently than I do.  :)

--ryan.





From torbjorn.e.andersson at tietoenator.com  Thu Apr 25 02:38:15 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn_Andersson?=)
Date: Thu, 25 Apr 2002 08:38:15 +0200
Subject: [sdlsound] The seek patches...
References: <Pine.LNX.4.33.0204241643140.20801-100000@gemini.verizon.net>
Message-ID: <3CC7A457.4030602@tietoenator.com>

Ryan C. Gordon wrote:

 > ...are in CVS. I'm rather pleased with how this is turning out.

Cool!

 > Btw, Torbjorn, do you want CVS write access? You submit patches more
 > frequently than I do.  :)

Nah, I feel much safer having the patches go through you first. I'd like 
to think there's a better chance that bad patches are weeded out that way.

By the way, in an earlier mail you wrote:

 > If this keeps up, playsound is going to become sentient take over the
 > world.

Until playsound can be used to read mail I wouldn't worry too much about 
this. ;-)

Torbj?rn
-- 
TietoEnator Resource Management AB
Persona
Torbj?rn Andersson
http://www.rm.tietoenator.com/



From icculus at clutteredmind.org  Thu Apr 25 02:48:33 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Thu, 25 Apr 2002 02:48:33 -0400 (EDT)
Subject: [sdlsound] The seek patches...
In-Reply-To: <3CC7A457.4030602@tietoenator.com>
Message-ID: <Pine.LNX.4.33L2.0204250247270.24627-100000@gamehenge.icculus.org>


> Until playsound can be used to read mail I wouldn't worry too much about
> this. ;-)

Hmm...theoretically we could have a decoder that reads text from a RWops
and generates speech audio...

No!  :)

--ryan.





From torbjorn.e.andersson at tietoenator.com  Thu Apr 25 02:56:41 2002
From: torbjorn.e.andersson at tietoenator.com (=?ISO-8859-1?Q?Torbj=F6rn_Andersson?=)
Date: Thu, 25 Apr 2002 08:56:41 +0200
Subject: [sdlsound] The seek patches...
References: <Pine.LNX.4.33.0204241643140.20801-100000@gemini.verizon.net>
Message-ID: <3CC7A8A9.6030903@tietoenator.com>

By the way, the latest CHANGELOG entry is a bit misleading. The MikMod 
decoder, alas, doesn't have seek capabilities. I'm not sure exactly what 
Player_SetPosition() does.

Torbj?rn
-- 
TietoEnator Resource Management AB
Persona
Torbj?rn Andersson
http://www.rm.tietoenator.com/



From icculus at clutteredmind.org  Sun Apr 28 22:54:23 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 28 Apr 2002 22:54:23 -0400 (EDT)
Subject: [SDL] SDL_sound mac updates
In-Reply-To: <EF2BAEDF-5B1A-11D6-9424-000502B99834@purdue.edu>
Message-ID: <Pine.LNX.4.33.0204282246530.5426-100000@gemini.verizon.net>


> 	I have added a quicktime decoder which can play back some quicktime
> formats (.mov) and also update the CodeWarrior and ProjectBuilder
> projects to use mpglib. There are a few small changes for mpglib. I
> originally wrote the quicktime decoder to play mp3 but I found it wasn't
> possible with this method. But it can play other formats so maybe it is
> useful to some people. I tested on Mac OS 9 and mpglib seems to work
> great!
>
> http://icdweb.cc.purdue.edu/~walisser/sdl/SDL_sound.tar.gz

Darrell:

  You kick massive butt!  Thanks!

--ryan.






From icculus at clutteredmind.org  Mon Apr 29 02:14:25 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 29 Apr 2002 02:14:25 -0400 (EDT)
Subject: Darrell's MacOS patches...
Message-ID: <Pine.LNX.4.33.0204290213290.15647-100000@gemini.verizon.net>


...are in CVS. I've also put the Project Builder tarball in CVS, so don't
be surprised if there's a one-time largish download.

I've cleaned up TODO and INSTALL, etc, too.

--ryan.




