From robert at simtrek.com  Tue Oct  1 12:56:20 2002
From: robert at simtrek.com (R Bresner)
Date: Wed, 02 Oct 2002 04:56:20 +1200
Subject: SDL_Sound Win32 sample ?
Message-ID: <3D99D3B4.3040000@simtrek.com>

Howdy all --

If this is the wrong mailing list for such query, let me
apologize in advance and ask if someone can point me in
the right direction.

I've written a very simple Win32 mp3 player using the Audio
functions of SDL and SDL_Sound, based off the playsound
sample program that came with SDL_Sound.

Now, I'm trying now to make it more Windows friendly. That is,
I'm trying to use a timer callback for reading data instead of
the, for example, sdl_desired.callback.
SDL_OpenAudio fails with a NULL callback, however, and WM_TIMER
callbacks don't quit fit the sdl_desired world.

I'm curious how SDL_Sound is integrated with a simple windows
app. Is there a sample Win32 app around somewhere I can have
a gander at, or some documentation for this kind of project?

Thanks a'plenty,

--
Rob
robert at simtrek.com



From icculus at clutteredmind.org  Tue Oct  1 22:16:25 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 1 Oct 2002 22:16:25 -0400 (EDT)
Subject: [sdlsound] SDL_Sound Win32 sample ?
In-Reply-To: <3D99D3B4.3040000@simtrek.com>
Message-ID: <Pine.LNX.4.33.0210012215580.12350-100000@gemini.verizon.net>


> Now, I'm trying now to make it more Windows friendly. That is,
> I'm trying to use a timer callback for reading data instead of
> the, for example, sdl_desired.callback.
> SDL_OpenAudio fails with a NULL callback, however, and WM_TIMER
> callbacks don't quit fit the sdl_desired world.

The callback is running in a separate thread; do you really need to use a
timer event?

--ryan.





From robert at simtrek.com  Wed Oct  2 07:36:11 2002
From: robert at simtrek.com (R Bresner)
Date: Wed, 02 Oct 2002 23:36:11 +1200
Subject: [sdlsound] SDL_Sound Win32 sample ?
References: <Pine.LNX.4.33.0210012215580.12350-100000@gemini.verizon.net>
Message-ID: <3D9ADA2B.6040600@simtrek.com>

Ryan C. Gordon wrote:
>>Now, I'm trying now to make it more Windows friendly. That is,
>>I'm trying to use a timer callback for reading data instead of
>>the, for example, sdl_desired.callback.
>>SDL_OpenAudio fails with a NULL callback, however, and WM_TIMER
>>callbacks don't quit fit the sdl_desired world.
> 
> 
> The callback is running in a separate thread; do you really need to use a
> timer event?
> 
> --ryan.
> 
> 
> 

Howdy --

Well, I'm not very sure which is the best/right way to do it.

I think I may have figured out a way to do what I meant
I want to do... versus what I managed to write in my first email.
I'm using the WM_TIMER to SDL_Decode() and update my GUI.
Then I'm filling the stream from my buffer in the callback.

There's a bit of skipping tho, that I can't account for.
I've got samples=8129, decode buf=32786, audio buf=16384.
And a callback that looks like this:

void mp3AudioCallback(void *userdata, Uint8 *stream, int len)
{
	int bw;
	static int pos = 0;
	static Uint8 *bpos = 0;

	if( bpos == 0 ) {
		bpos = decoded_buffer;
	}

	if( pos + len > nBufferSize )
		len = nBufferSize - pos;
	
	memcpy(stream, bpos, len );
	bpos += len;
	pos += len;
	if( len == 0 ) {
		// finished playing buffer.
		SDL_PauseAudio(1);
	}
}

void *decoded_buffer and Uint32 nBufferSize are currently a couple
global vars.

So. Am I going about this entirely wrong? What is causing
the skipping? Why is the sky blue? Why do birds sing?

How many surrealists does it take to change a light bulb?
Pink elephant.

Thanks,

--
Rob



From torbjorn.e.andersson at tietoenator.com  Thu Oct  3 02:15:36 2002
From: torbjorn.e.andersson at tietoenator.com (Andersson Torbjorn E)
Date: Thu, 3 Oct 2002 08:15:36 +0200 
Subject: [sdlsound] time to finish painting...
Message-ID: <5B8B5EE38245A84A87677CD39CE251835DD6AF@gabriel.enator.se>

Ryan C. Gordon wrote:

> 2) Someone tell me what the current state of altcvt is, and what needs to
> be done with it (and if it's worth holding up a 1.0 release for).

I haven't looked much at it, but I can tell you it's not working when I try
it with playsound. The frequency converter doesn't work at all, and even
some of the more trivial conversions are broken. (I know, I know. I should
provide examples here.)

I don't know if the problem is in the converter itself, or if it's just not
interacting properly with SDL_sound.

Torbj?rn

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


From icculus at clutteredmind.org  Fri Oct  4 12:38:14 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Fri, 4 Oct 2002 12:38:14 -0400 (EDT)
Subject: [sdlsound] SDL_Sound Win32 sample ?
In-Reply-To: <3D9ADA2B.6040600@simtrek.com>
Message-ID: <Pine.LNX.4.33.0210041236030.9046-100000@gemini.verizon.net>


> So. Am I going about this entirely wrong? What is causing
> the skipping? Why is the sky blue? Why do birds sing?

It appears to be okay at first glance...perhaps the WM_TIMER stuff isn't
decoding fast enough?

It _should_ be safe to just decode in the callback as needed, and it makes
the code more sane.

--ryan.





From icculus at clutteredmind.org  Sun Oct  6 01:17:29 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Sun, 6 Oct 2002 01:17:29 -0400 (EDT)
Subject: Release date: October 9th.
Message-ID: <Pine.LNX.4.33L2.0210060115510.4297-100000@gamehenge.icculus.org>


I will package up the official SDL_sound 1.0.0 on Wednesday, October 9th.
Any last minute patches should be sent to the list before then if you want
them in the 1.0.0 release.

--ryan.





From tsm at accesscomm.ca  Sun Oct  6 01:24:48 2002
From: tsm at accesscomm.ca (Corona688)
Date: Sat, 05 Oct 2002 23:24:48 -0600
Subject: [sdlsound] [OT] Release date: October 9th.
References: <Pine.LNX.4.33L2.0210060115510.4297-100000@gamehenge.icculus.org>
Message-ID: <3D9FC920.77C36799@accesscomm.ca>

"Ryan C. Gordon" wrote:

> I will package up the official SDL_sound 1.0.0 on Wednesday, October 9th.
> Any last minute patches should be sent to the list before then if you want
> them in the 1.0.0 release.
>
> --ryan.

Hot dog, that's my birthday!  What a nice present!  :)



From icculus at clutteredmind.org  Tue Oct  8 07:53:00 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 8 Oct 2002 07:53:00 -0400 (EDT)
Subject: ...one more day...
Message-ID: <Pine.LNX.4.33L2.0210080751340.18910-100000@gamehenge.icculus.org>


...until 1.0.  Patches have 1440 minutes in which they can still be
considered "last minute".  :)

--ryan.





From tsm at accesscomm.ca  Tue Oct  8 13:26:59 2002
From: tsm at accesscomm.ca (Corona688)
Date: Tue, 08 Oct 2002 11:26:59 -0600
Subject: WinCE update
References: <Pine.LNX.4.33L2.0210080751340.18910-100000@gamehenge.icculus.org>
Message-ID: <3DA31563.71E0766A@accesscomm.ca>

"Ryan C. Gordon" wrote:

> ...until 1.0.  Patches have 1440 minutes in which they can still be
> considered "last minute".  :)
>
> --ryan.

Latest CVS compiles and runs out-of-the-box.



From icculus at clutteredmind.org  Tue Oct  8 13:49:08 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 8 Oct 2002 13:49:08 -0400 (EDT)
Subject: [sdlsound] WinCE update
In-Reply-To: <3DA31563.71E0766A@accesscomm.ca>
Message-ID: <Pine.LNX.4.33L2.0210081348140.24189-100000@gamehenge.icculus.org>


> Latest CVS compiles and runs out-of-the-box.

Excellent!

--ryan.





From icculus at clutteredmind.org  Wed Oct  9 12:30:01 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 9 Oct 2002 12:30:01 -0400 (EDT)
Subject: SDL_sound 1.0.0 released!
Message-ID: <Pine.LNX.4.33.0210091228160.14612-100000@gemini.verizon.net>


SDL_sound 1.0.0 is now available.

The details, API reference, mailing list instructions, and downloads can
be found at:

     http://icculus.org/SDL_sound/


Thanks to everyone that made this possible. You know who you are.  :)

--ryan.




From yjchenx at hotmail.com  Mon Oct 21 11:55:57 2002
From: yjchenx at hotmail.com (Yen-Ju Chen)
Date: Mon, 21 Oct 2002 11:55:57 -0400
Subject: MusicBox-0.3.0 is released
Message-ID: <F116Qk5LK4KRewLX2wE0000882f@hotmail.com>

I'm pleased to release MusicBox-0.3.0.

What's MusicBox ?
-----------------

MusicBox is a music manager for GNUstep environment (www.gnustep.org).
It is inspired by Rhythmbox and iTune.
It uses SDL and SDL_sound as underneath audio and CD control.
A very brief introduction can be found in
http://www.people.virginia.edu/~yc2w/GNUstep/english/

What's new ?
------------

Cddb:
Change the header files (<Cddb/Cddb.h> rather than <Cddb/CddbProtocol.h>.
Use ISO-Latin1 rather than ASCII for cddb files

Mixer:
Change the header files (<Mixer/Mixer.h> rather than 
<Mixer/MixerProtocol.h>.

ShengGuang:
Install SDLSystem bundle into local domain rather than user domain.

MusicBox:
Support drag-and-drop on various places.
Install bundles into local domain rather than user domain.
A separated playlist window.
Better cddb access control.
Many minor improvement.

Download/CVS
------------
http://savannah.gnu.org/projects/musicbox

Have Fun

Yen-Ju





_________________________________________________________________
Choose an Internet access plan right for you -- try MSN! 
http://resourcecenter.msn.com/access/plans/default.asp



From tsm at accesscomm.ca  Tue Oct 22 00:25:50 2002
From: tsm at accesscomm.ca (Corona688)
Date: Mon, 21 Oct 2002 22:25:50 -0600
Subject: Problem with Playsound
Message-ID: <3DB4D34E.3A08B056@accesscomm.ca>

Playsound makes one major assumption when it opens an audio device -
that the format it requests is the device it gets.  Under the vast
majority of situations, this is true;  however, under Windows CE, it is
not.

WinCE demands an audio buffer size of precisely 11028 samples at 44Khz
16-bit stereo.  Why?  Beats the hell out of me.  This could easily be
the explanation of the mysterious clicking I thought was due to the
processor being unable to keep up with the decoder;  I could minimize
it, but I could never get rid of it entirely.



From icculus at clutteredmind.org  Tue Oct 22 03:36:19 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Tue, 22 Oct 2002 03:36:19 -0400 (EDT)
Subject: [sdlsound] Problem with Playsound
In-Reply-To: <3DB4D34E.3A08B056@accesscomm.ca>
Message-ID: <Pine.LNX.4.33.0210220325450.16732-100000@gemini.verizon.net>


> Playsound makes one major assumption when it opens an audio device -
> that the format it requests is the device it gets.  Under the vast
> majority of situations, this is true;  however, under Windows CE, it is
> not.

It isn't assuming. Playsound _needs_ to open the audio device with
parameters that match the audio file, and SDL translates on-the-fly if it
can't get that exact format from the audio device. This is compliant with
the SDL API documentation.

The option is to convert in playsound, or convert in SDL, but either way
it's going to be a CPU hit. My assumption is that SDL is more qualified to
accelerate this action on a given platform than playsound is.

> WinCE demands an audio buffer size of precisely 11028 samples at 44Khz
> 16-bit stereo.  Why?  Beats the hell out of me.  This could easily be
> the explanation of the mysterious clicking I thought was due to the
> processor being unable to keep up with the decoder;  I could minimize
> it, but I could never get rid of it entirely.

It's likely that a given audio format will be 16-bit/44KHz to begin
with...as for the fragment size, SDL will just keep running the callback
if we give it less than it needs each time.

While it isn't good to have to convert the data between formats, the real
CPU killer is the floating point needed for decoding MP3s and Oggs. i
thought that mpglib was integerized (since I heard somewhere that it works
well on the StrongARM chip), but it doesn't appear to be when looking at
the source.

xiph.org just released an integerized Vorbis decoder, called Tremor. I
haven't looked, but if it has the same API as the floating point
libraries, it might be worth trying it on WinCE for a significant speed
boost.

There is also a GPL'd MP3 integer decoder that has been discussed here
before (madplay? Something like that) ... that is still worth exploring,
if we can get a GPL exception of some sort.

--ryan.




From tsm at accesscomm.ca  Wed Oct 23 11:49:44 2002
From: tsm at accesscomm.ca (Corona688)
Date: Wed, 23 Oct 2002 09:49:44 -0600
Subject: [sdlsound] Problem with Playsound
References: <Pine.LNX.4.33.0210220325450.16732-100000@gemini.verizon.net>
Message-ID: <3DB6C518.51434693@accesscomm.ca>

"Ryan C. Gordon" wrote:

> It isn't assuming. Playsound _needs_ to open the audio device with
> parameters that match the audio file, and SDL translates on-the-fly if it
> can't get that exact format from the audio device. This is compliant with
> the SDL API documentation.

Ah, I see.  My bad.

> The option is to convert in playsound, or convert in SDL, but either way
> it's going to be a CPU hit. My assumption is that SDL is more qualified to
> accelerate this action on a given platform than playsound is.

Yup, my bad.  Sorry.  Just fishing for something to fix.

 Experimenting with LibModPlug in WinCE outside of SDL_sound has convinced me
that the mysterious clicking is NOT due to the CPU being unable to keep up...
I can run my program at 16-bit stereo 44KHz just fine AND get a good screen
refresh rate.

Meaning that unless I'm highly mistaken, the problem's in the SDL_sound code
itself.  Might be the same problem that bit us with LibModPlug - the
Armstrong's utter refusal to accept odd memory addresses for anything but byte
reads.  If it's an error of that kind it will compile without complaint, but
it'll truncate the last bit from the address when running, causing
who-knows-what havoc.

I haven't done much with the SDL_sound code itself - so portable in general
that I haven't had to touch it.  Do you know of any likely spots to check out
for this kind of memory access?


> xiph.org just released an integerized Vorbis decoder, called Tremor. I
> haven't looked, but if it has the same API as the floating point
> libraries, it might be worth trying it on WinCE for a significant speed
> boost.

Sweet!  :)

> There is also a GPL'd MP3 integer decoder that has been discussed here
> before (madplay? Something like that) ... that is still worth exploring,
> if we can get a GPL exception of some sort.
>
> --ryan.



From icculus at clutteredmind.org  Wed Oct 23 16:44:27 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 23 Oct 2002 16:44:27 -0400 (EDT)
Subject: [sdlsound] Problem with Playsound
In-Reply-To: <3DB6C518.51434693@accesscomm.ca>
Message-ID: <Pine.LNX.4.33.0210231642040.28215-100000@gemini.verizon.net>


> I haven't done much with the SDL_sound code itself - so portable in general
> that I haven't had to touch it.  Do you know of any likely spots to check out
> for this kind of memory access?


Little scary to be malloc()ing the whole file size:

        /*
         * ModPlug needs the entire stream in one big chunk. I don't like it,
         *  but I don't think there's any way around it.
         */

There's also a bunch of options for ModPlug, and we only set a handful.
Might be worth playing around with those.

Are there any profiling tools for CE?

--ryan.




From tsm at accesscomm.ca  Wed Oct 23 18:42:13 2002
From: tsm at accesscomm.ca (Corona688)
Date: Wed, 23 Oct 2002 16:42:13 -0600
Subject: [sdlsound] Problem with Playsound
References: <Pine.LNX.4.33.0210231642040.28215-100000@gemini.verizon.net>
Message-ID: <3DB725C4.CDDB7712@accesscomm.ca>

"Ryan C. Gordon" wrote:

> > I haven't done much with the SDL_sound code itself - so portable in general
> > that I haven't had to touch it.  Do you know of any likely spots to check out
> > for this kind of memory access?
>
> Little scary to be malloc()ing the whole file size:
>
>         /*
>          * ModPlug needs the entire stream in one big chunk. I don't like it,
>          *  but I don't think there's any way around it.
>          */

Ah, but the problem is not restricted to ModPlug;  Timidity exhibits it as well, as
does MikMod.

> Are there any profiling tools for CE?
>
> --ryan.

Not that I know of, tho it would help if I knew what a profiling tool is.
Aheheh... >.>  In general, tho, CE is a horrible platform to debug without an
emulator;  near-zero exception handling.



