--------------enig5543E52C86D9EA0D5654FB91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable vasudevram wrote: > Harold Hausman wrote: >> On 11/5/06, Phlip <phlipcpp / yahoo.com> wrote: >>> Ruboids: >>> >>> Suppose I wanted to play a WAV file each time any Rakefile tasks all >>> succeed, and play another one each time any task fails. >>> >> .. snip >> >>> - what's Ruby's dirt-simple but portable sound library? >>> >> For windows it definitely doesn't get any easier than win-32 sound: >> http://raa.ruby-lang.org/project/win32-sound/ >> >> idk about Linux unfortunately, >> -Harold > > Hi, > > For Linux, here are a couple of suggestions: > > 1. try 'cat'ing the WAV file to the sound device - maybe something likedev/audio. > 2. Write the file's contents to the device. > > Do either of the above, from your Ruby code, is what I mean. > Except they won't work. /dev/dsp and /dev/audio take only very specific file formats, neither of which is .WAW. I'm afraid multimedia handling is a nontrivial problem on any OS and generally a mess. Windows has builtin support for .WAW, Linux for raw PCM at 8kHz/8bit/mono (for dsp). Which means you're probably still dependent on some outside tool to transform your sound file into the desired format. And you might as well use mplayer (my criterium for choosing that one is that it's console-based, comes with a Win32 build, and is easy to bundle with an app, and Just Works) > A thought: it's not always necessary or worth it to try and make the > code portable across OS's - though a good idea in theory, sometimes theffort may not be worth it. If you have a quick and easy way to do it > non-portably (i.e. using different pieces of code for Windows and > Linux), nothing wrong with using that approach. Except that you have to do OS sniffing, sniffing for presence of support you require (windows native .wav handling, DirectSound, OSS, ALSA), and heavens forbid you want to support multiple source file formats. Generally the problem is that per se, the OS portability is the least of your concerns, it's getting a framework that will handle the sound format / output method issueswith minimal fuss. (To wit: if you're using a freeware / open-source video manipulation software, odds are it's a frontend to ffmpeg) If that framework is nonportable, you have to go on and code against two. But in this specific case, since you pretty much have to go on and get a preexisting sound playback solution anyway, you might as well find one that won't double your coding effort (even if it's hopefully a minimal one.) The issue here isn't expending effort to create a cross-platform solution, it's saving it by reusing a cross-platform solution. David Vallner --------------enig5543E52C86D9EA0D5654FB91 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) iD8DBQFFThFpy6MhrS8astoRAhNhAJ0U0bmnXRelA3SCq3X7nRC3SVoKIgCfQgn4 roBG96pZqlJ5CJuKswEFd1o 9X -----END PGP SIGNATURE----- --------------enig5543E52C86D9EA0D5654FB91--