I’ve updated the audio recording patch to also include an SDL_SaveWAV()
function that does just what you think it does. The API it the same as
SDL_LoadWAV(). I haven’t tested it very much at all. See:
http://torsion.org/witten/sdl/--
Dan Helfman
Jim Henson’s Creature Shop
Any chance of getting an audio plugin for direct to disk? ;)On Wed, Apr 17, 2002 at 06:36:59PM -0700, Dan Helfman wrote:
I’ve updated the audio recording patch to also include an SDL_SaveWAV()
function that does just what you think it does. The API it the same as
SDL_LoadWAV(). I haven’t tested it very much at all. See:
–
Joseph Carter Here we go again
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020418/7c2e0cc6/attachment.pgp
Sure! You don’t look busy. 
-JohnOn Thu, Apr 18, 2002 at 07:19:41PM -0700, Joseph Carter wrote:
On Wed, Apr 17, 2002 at 06:36:59PM -0700, Dan Helfman wrote:
I’ve updated the audio recording patch to also include an SDL_SaveWAV()
function that does just what you think it does. The API it the same as
SDL_LoadWAV(). I haven’t tested it very much at all. See:
http://torsion.org/witten/sdl/
Any chance of getting an audio plugin for direct to disk?
–
John R. Hall - KG4RUO - Stranded in the Sol System
Student, Georgia Tech; Author, Programming Linux Games
You aren’t looking very closely. 
BTW, for anyone who cares, here’s the SDL 1.2.4 apt lines:
deb http://warped.bluecherry.net/~knghtbrd debian/
deb-src http://warped.bluecherry.net/~knghtbrd debian/
Get 'em while they’re hot!On Fri, Apr 19, 2002 at 12:54:34AM -0400, John R. Hall wrote:
Any chance of getting an audio plugin for direct to disk?
Sure! You don’t look busy.
–
Joseph Carter Certified free software nut
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020418/002acd04/attachment.pgp
Um, you know that SDL already has that, contributed by Ryan, right?
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Wed, Apr 17, 2002 at 06:36:59PM -0700, Dan Helfman wrote:
I’ve updated the audio recording patch to also include an SDL_SaveWAV()
function that does just what you think it does. The API it the same as
SDL_LoadWAV(). I haven’t tested it very much at all. See:
Any chance of getting an audio plugin for direct to disk?
Isn’t that an “audio driver”…? That is, it wouldn’t be possible to open
the sound card for recording, and then directly use this for writing the
recorded audio to disk, right? (You’d need to be able to open multiple
devices, and you’d still have to implement sync between them in some
way…)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 19 April 2002 13:18, Sam Lantinga wrote:
On Wed, Apr 17, 2002 at 06:36:59PM -0700, Dan Helfman wrote:
I’ve updated the audio recording patch to also include an
SDL_SaveWAV() function that does just what you think it does. The
API it the same as SDL_LoadWAV(). I haven’t tested it very much at
all. See:Any chance of getting an audio plugin for direct to disk?
Um, you know that SDL already has that, contributed by Ryan, right?
I don’t see where that fits into SDL, actually… Even if you could open
two devices (one “real” for recording) and one for “output to disk”, it
wouldn’t work out-of-the-box, as the former would be driven by the sound
card, while the latter would be driven by a timer. That is, you wouldn’t
be able to pass buffers directly from one to the other without drifting
out of sync eventually.
This sort of recording would be an application thing, I believe…
I can hack an example if anyone really wants one. Want it threaded or
polled?
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 19 April 2002 04:19, Joseph Carter wrote:
On Wed, Apr 17, 2002 at 06:36:59PM -0700, Dan Helfman wrote:
I’ve updated the audio recording patch to also include an
SDL_SaveWAV() function that does just what you think it does. The API
it the same as SDL_LoadWAV(). I haven’t tested it very much at all.
See:Any chance of getting an audio plugin for direct to disk?
I didn’t know. Cool. I haven’t enabled anything interesting in our
Debian packages yet because of the pending woody release.
The packages are about to get a very significant rewrite from the ground
up using Doogie’s Build System (which is evil for the most part, but has
the advantage of handling multiple patches from upstream and from Debian
in a clean manner) and I’ll mention what I’m doing here on the list if
anyone is interested. I’ll also be maintaining libsdl-snapshot packages
(infrequently till I get broadband again though) so Debian should be able
to use the latest and greatest pre-release SDL in sid.On Fri, Apr 19, 2002 at 04:18:05AM -0700, Sam Lantinga wrote:
I’ve updated the audio recording patch to also include an SDL_SaveWAV()
function that does just what you think it does. The API it the same as
SDL_LoadWAV(). I haven’t tested it very much at all. See:Any chance of getting an audio plugin for direct to disk?
Um, you know that SDL already has that, contributed by Ryan, right?
–
Joseph Carter You want fries with that?
If we want something nice to get born in nine months, then sex has to
happen. We want to have the kind of sex that is acceptable and fun for both
people, not the kind where someone is getting screwed. Let’s get some cross
fertilization, but not someone getting screwed.
– Larry Wall
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020419/b586d15b/attachment.pgp
The packages are about to get a very significant rewrite from the ground
up using Doogie’s Build System (which is evil for the most part, but has
the advantage of handling multiple patches from upstream and from Debian
in a clean manner) and I’ll mention what I’m doing here on the list if
anyone is interested. I’ll also be maintaining libsdl-snapshot packages
(infrequently till I get broadband again though) so Debian should be able
to use the latest and greatest pre-release SDL in sid.
No, no, no. Please don’t distribute CVS SDL in a Linux distribution
(anywhere, really), unless there is some feature that is critical, in
which case bug me to make a release. SDL CVS code is UNSTABLE by its
very definition.
As for the whole ALSA thing, I suggest that you just not enable ALSA
support in SDL for the woody packages - the OSS emulation works just
fine. For example, there appears to be a bug in ALSA right now that
causes a crash (yes, crash bug, folks) when you open the audio device
in a rate that’s not natively supported.
If you absolutely must have the ALSA support in SDL, it is probably
safe to grab the current CVS, but that will not always be guaranteed.
Thanks,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
The packages are about to get a very significant rewrite from the ground
up using Doogie’s Build System (which is evil for the most part, but has
the advantage of handling multiple patches from upstream and from Debian
in a clean manner) and I’ll mention what I’m doing here on the list if
anyone is interested. I’ll also be maintaining libsdl-snapshot packages
(infrequently till I get broadband again though) so Debian should be able
to use the latest and greatest pre-release SDL in sid.No, no, no. Please don’t distribute CVS SDL in a Linux distribution
(anywhere, really), unless there is some feature that is critical, in
which case bug me to make a release. SDL CVS code is UNSTABLE by its
very definition.
So is Debian sid. The point is that sid will never be released, and the
packages in question will never leave sid. I’ll use them of course,
because I traditionally follow SDL CVS anyway (which is something I’ve
been trying to convince other developers to do as well since bugs are
found and fixed by people who are capible of doing one or both before the
user has to find what we missed the hard way…)
Speaking of CVS, the email I sent you made sense I hope?
As for the whole ALSA thing, I suggest that you just not enable ALSA
support in SDL for the woody packages - the OSS emulation works just
fine. For example, there appears to be a bug in ALSA right now that
causes a crash (yes, crash bug, folks) when you open the audio device
in a rate that’s not natively supported.If you absolutely must have the ALSA support in SDL, it is probably
safe to grab the current CVS, but that will not always be guaranteed.
I applied the 0.9 patch from CVS to the 1.2.4 packages for woody.
Removing ALSA support would annoy lots of people and 0.9 is the future of
ALSA, so it seems like the best solution to a messy problem for now.
I’d prefer not to apply such large patches to release versions like this,
especially with an impending release and a too-low amount of testing time.
Small patches I’m not worried about too much, but currently the Debian
diff is 76k gzipped and the SNR is far too low with all the regenerated
autocrap in there. DBS will make it easy to apply the small patches which
are needed to fix small bugs from CVS real easily, and will generally make
it easier to find out, should something break in the packages, which one
of us to blame for it. ;)On Fri, Apr 19, 2002 at 08:18:14AM -0700, Sam Lantinga wrote:
–
Joseph Carter Do not write in this space
I can think of lots of people who need USER=ID10T someplace!
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020419/44d16575/attachment.pgp
Any chance of getting an audio plugin for direct to disk?
Um, you know that SDL already has that, contributed by Ryan, right?
To use it:
export SDL_AUDIODRIVER=disk
export SDL_DISKAUDIOFILE=/where/i/want/the/output.raw
export SDL_DISKAUDIODELAY=150
The “150” is milliseconds between invoking the audio callback. 150 seems
to make applications feed the audio “device” at an acceptable rate.
Setting it to zero calls the callback over and over as fast as possible,
which works well if you just want an audio playback program (like
plaympeg) to dump decoded audio to disk as fast as possible.
I’ve only tried this on Linux (and it probably relies on threads, so MacOS
is out). I intended it for debugging purposes, and I’m not sure it’s
really best to use it intentionally in a real application.
The Unix configure script will include the disk writer by default (unless
you do a --disable-diskaudio), but SDL will never select the driver unless
you explicitly request it (with the SDL_AUDIODRIVER environment variable).
The source is in SDL12/src/audio/disk … enjoy.
–ryan.