www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Anyone interested in simpleaudio.d too?

reply Adam D. Ruppe <destructionator gmail.com> writes:
I just dug up my old wav.d and quickly added wav.play() support
to it for both Windows and Linux. Now, this is sucky D1 code,
but hey, it works, and it's short. If there's interest, I can
port to D2 and add some range support to it and see about fleshing
it out.

http://arsdnet.net/dcode/wav.d

Again, this is D1, so be sure to use an appropriate compiler. It's
dependency free (even on Linux - the only calls it makes are to the
kernel for open, write, close, and ioctl. It uses the OSS /dev/dsp
method.

BTW, yes, I know OSS is deprecated. Fuck that noise, ALSA is a piece
of shit and who the hell even knows what's going on anymore beyond it.
Seems like every time I turn around there's another half assed new
Linux audio stack. What the damn son.

OSS is technically superior and *infinitely* easier to use. If I
decide to post my MIDI code, you'll see what I mean - it uses ALSA
and takes like 100 lines to do the simplest thing. The Windows
version of midi, using the *low level* functions was about ten lines
long...

Besides OSS works on just about any unix, so it's more cross platform
too. So yeah, I'm sticking to it for any kind of simple audio module.)



The wav class is just a collection of data. Everything is stored
as a short[] and you simply add data. There's a few functions in
there for some simple sounds, then the bottom half of the file
has a main() function and some helpers to play a little melody. (If
you've played Final Fantasy 6, you might recognize it. Nothing fancy,
but more interesting to my ears than random noise.)


Then you can call wav.save("file.wav") to write it to disk or
wav.play() to put it out the speakers.

Note: turn your volume down before trying it. It worked for me but
it might be buggy.



Anyway, any interest in this little thing being fleshed out? It seems
to me that simple audio is something a lot of libraries neglect, and
it really isn't hard to add.

I figure it will offer the same style of stuff I've been talking
about for images - some generic sound related algorithms and a
few ranges off the files, converted to lazy style to mesh with the
rest of the lib. I'm open to ideas and suggestions for what would be
useful.
Apr 11 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Oh, I forgot to mention. Right now it is wav.play() but if I
actually flesh it out, playing will move to a free function that
takes an input range of the waveform data, just like how
simpledisplay now works.

Naturally, the wav class will still exist and will expose suitable
ranges, so playing will still be a one-liner.
Apr 11 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 06:30, schrieb Adam D. Ruppe:
 I just dug up my old wav.d and quickly added wav.play() support
 to it for both Windows and Linux. Now, this is sucky D1 code,
 but hey, it works, and it's short. If there's interest, I can
 port to D2 and add some range support to it and see about fleshing
 it out.
 
 http://arsdnet.net/dcode/wav.d
 
 Again, this is D1, so be sure to use an appropriate compiler. It's
 dependency free (even on Linux - the only calls it makes are to the
 kernel for open, write, close, and ioctl. It uses the OSS /dev/dsp
 method.
 
 BTW, yes, I know OSS is deprecated. Fuck that noise, ALSA is a piece
 of shit and who the hell even knows what's going on anymore beyond it.
 Seems like every time I turn around there's another half assed new
 Linux audio stack. What the damn son.
 
 OSS is technically superior and *infinitely* easier to use. If I
 decide to post my MIDI code, you'll see what I mean - it uses ALSA
 and takes like 100 lines to do the simplest thing. The Windows
 version of midi, using the *low level* functions was about ten lines
 long...
 
 Besides OSS works on just about any unix, so it's more cross platform
 too. So yeah, I'm sticking to it for any kind of simple audio module.)
 
 

Hmm I think for output (both for video and audio) it may really be smarter to use SDL, because it supports more platforms and supports them properly (i.e. many different audio systems, well tested support for them, ...). Especially if SDL1.3 really is released under zlib-license and maybe could be shipped with Phobos. Cheers, - Daniel
Apr 11 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-12 00:46:18 -0400, Daniel Gibson <metalcaedes gmail.com> said:

 Especially if SDL1.3 really is released under zlib-license and maybe
 could be shipped with Phobos.

Any reference for that? The website says LGPL or commercial license. <http://www.libsdl.org/license.php> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 12:55, schrieb Michel Fortin:
 On 2011-04-12 00:46:18 -0400, Daniel Gibson <metalcaedes gmail.com> said:
 
 Especially if SDL1.3 really is released under zlib-license and maybe
 could be shipped with Phobos.

Any reference for that? The website says LGPL or commercial license. <http://www.libsdl.org/license.php>

Yeah, http://slouken.blogspot.com/2011/04/exploring-galaxy.html?showComment=1302234229839#c4323023909103671526 (slouken is Sam Lantinga, the main developer of SDL) Cheers, - Daniel
Apr 12 2011
parent Mike Parker <aldacron gmail.com> writes:
On 4/12/2011 7:57 PM, Daniel Gibson wrote:
 Am 12.04.2011 12:55, schrieb Michel Fortin:
 On 2011-04-12 00:46:18 -0400, Daniel Gibson<metalcaedes gmail.com>  said:

 Especially if SDL1.3 really is released under zlib-license and maybe
 could be shipped with Phobos.

Any reference for that? The website says LGPL or commercial license. <http://www.libsdl.org/license.php>

Yeah, http://slouken.blogspot.com/2011/04/exploring-galaxy.html?showComment=1302234229839#c4323023909103671526 (slouken is Sam Lantinga, the main developer of SDL)

Also see, http://forums.libsdl.org/viewtopic.php?t=7148 The new licensing has been applied in the latest snapshot. http://www.libsdl.org/tmp/SDL-1.3.zip FWIW, I'll be adding a binding to Derelict 2 as soon as time allows.
Apr 12 2011
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Daniel Gibson wrote:
 Especially if SDL1.3 really is released under zlib-license and maybe
 could be shipped with Phobos.

SDL 1.3 looks quite nice, but it's going to be several months until it's stable release. It won't be difficult to add an SDL implementation to my same interface down the line. The platform specific code for display and sound combined, per platform, is ~300 straight-forward lines so far. Most the work is OS implementation independent.
Apr 12 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 06:30 AM, Adam D. Ruppe wrote:
 I just dug up my old wav.d and quickly added wav.play() support
 to it for both Windows and Linux. Now, this is sucky D1 code,
 but hey, it works, and it's short. If there's interest, I can
 port to D2 and add some range support to it and see about fleshing
 it out.

 http://arsdnet.net/dcode/wav.d

 Again, this is D1, so be sure to use an appropriate compiler. It's
 dependency free (even on Linux - the only calls it makes are to the
 kernel for open, write, close, and ioctl. It uses the OSS /dev/dsp
 method.

 BTW, yes, I know OSS is deprecated. Fuck that noise, ALSA is a piece
 of shit and who the hell even knows what's going on anymore beyond it.
 Seems like every time I turn around there's another half assed new
 Linux audio stack. What the damn son.

 OSS is technically superior and *infinitely* easier to use. If I
 decide to post my MIDI code, you'll see what I mean - it uses ALSA
 and takes like 100 lines to do the simplest thing. The Windows
 version of midi, using the *low level* functions was about ten lines
 long...

 Besides OSS works on just about any unix, so it's more cross platform
 too. So yeah, I'm sticking to it for any kind of simple audio module.)

An excellent article on the topic: http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html (many other articles by the author are very good) Also, OSS has been free software again for 4 years already. And yes, ALSA is plain shift both for the developper & the user; and its propaganda is bullshit. Use OSS! and let it be known this is the only right choice available for efficient, simple, and portable sound apps... Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 13:10, schrieb spir:
 On 04/12/2011 06:30 AM, Adam D. Ruppe wrote:
 I just dug up my old wav.d and quickly added wav.play() support
 to it for both Windows and Linux. Now, this is sucky D1 code,
 but hey, it works, and it's short. If there's interest, I can
 port to D2 and add some range support to it and see about fleshing
 it out.

 http://arsdnet.net/dcode/wav.d

 Again, this is D1, so be sure to use an appropriate compiler. It's
 dependency free (even on Linux - the only calls it makes are to the
 kernel for open, write, close, and ioctl. It uses the OSS /dev/dsp
 method.

 BTW, yes, I know OSS is deprecated. Fuck that noise, ALSA is a piece
 of shit and who the hell even knows what's going on anymore beyond it.
 Seems like every time I turn around there's another half assed new
 Linux audio stack. What the damn son.

 OSS is technically superior and *infinitely* easier to use. If I
 decide to post my MIDI code, you'll see what I mean - it uses ALSA
 and takes like 100 lines to do the simplest thing. The Windows
 version of midi, using the *low level* functions was about ten lines
 long...

 Besides OSS works on just about any unix, so it's more cross platform
 too. So yeah, I'm sticking to it for any kind of simple audio module.)

An excellent article on the topic: http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html (many other articles by the author are very good) Also, OSS has been free software again for 4 years already. And yes, ALSA is plain shift both for the developper & the user; and its propaganda is bullshit. Use OSS! and let it be known this is the only right choice available for efficient, simple, and portable sound apps... Denis

ALSA is the de facto standard on Linux. It used to use an old version of OSS that didn't support surround sound etc (and better OSS versions were commercial back then). So ALSA was developed.. years later the OSS developer realized that he wouldn't make any money with it anymore and opensourced OSS. Should Linux switch back now and dismiss all work that has gone into ALSA? Also you shouldn't write directly against OSS or ALSA but use SDL or OpenAL or libao or ... instead. Cheers, - Daniel
Apr 12 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-12 07:18:39 -0400, Daniel Gibson <metalcaedes gmail.com> said:

 Also you shouldn't write directly against OSS or ALSA but use SDL or
 OpenAL or libao or ... instead.

The problem with intermediary libraries is that they require work on the programmer side to work. I think there is value in being able to write a simple program just by importing std.simpleaudio and having it work instantly without having to install any library or play with linker flags (which will be handled by pragma(lib) if you let DMD handle the linker). And it's also easier to distribute your app if it doesn't depend on dynamic libraries not installed by default on the system. I'm not saying those libraries are not useful, only that they come with some complications. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 13:44, schrieb Michel Fortin:
 On 2011-04-12 07:18:39 -0400, Daniel Gibson <metalcaedes gmail.com> said:
 
 Also you shouldn't write directly against OSS or ALSA but use SDL or
 OpenAL or libao or ... instead.

The problem with intermediary libraries is that they require work on the programmer side to work. I think there is value in being able to write a simple program just by importing std.simpleaudio and having it work instantly without having to install any library or play with linker flags (which will be handled by pragma(lib) if you let DMD handle the linker). And it's also easier to distribute your app if it doesn't depend on dynamic libraries not installed by default on the system. I'm not saying those libraries are not useful, only that they come with some complications.

Err.. I didn't say "don't use std.simpleaudio" but "don't use OSS/ALSA directly but some platform independent abstraction" - which could as well be your std.simpleaudio :)
Apr 12 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-12 07:47:48 -0400, Daniel Gibson <metalcaedes gmail.com> said:

 Am 12.04.2011 13:44, schrieb Michel Fortin:
 On 2011-04-12 07:18:39 -0400, Daniel Gibson <metalcaedes gmail.com> said:
 
 Also you shouldn't write directly against OSS or ALSA but use SDL or
 OpenAL or libao or ... instead.

The problem with intermediary libraries is that they require work on the programmer side to work. I think there is value in being able to write a simple program just by importing std.simpleaudio and having it work instantly without having to install any library or play with linker flags (which will be handled by pragma(lib) if you let DMD handle the linker). And it's also easier to distribute your app if it doesn't depend on dynamic libraries not installed by default on the system. I'm not saying those libraries are not useful, only that they come with some complications.

Err.. I didn't say "don't use std.simpleaudio" but "don't use OSS/ALSA directly but some platform independent abstraction" - which could as well be your std.simpleaudio :)

I misunderstood then. I thought you were saying that std.simpleaudio should be implemented using one of these platform abstractions. Actually it could, but I think it'll diminish its value. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 12 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 14:40, schrieb Michel Fortin:
 On 2011-04-12 07:47:48 -0400, Daniel Gibson <metalcaedes gmail.com> said:
 
 Am 12.04.2011 13:44, schrieb Michel Fortin:
 On 2011-04-12 07:18:39 -0400, Daniel Gibson <metalcaedes gmail.com>
 said:

 Also you shouldn't write directly against OSS or ALSA but use SDL or
 OpenAL or libao or ... instead.

The problem with intermediary libraries is that they require work on the programmer side to work. I think there is value in being able to write a simple program just by importing std.simpleaudio and having it work instantly without having to install any library or play with linker flags (which will be handled by pragma(lib) if you let DMD handle the linker). And it's also easier to distribute your app if it doesn't depend on dynamic libraries not installed by default on the system. I'm not saying those libraries are not useful, only that they come with some complications.

Err.. I didn't say "don't use std.simpleaudio" but "don't use OSS/ALSA directly but some platform independent abstraction" - which could as well be your std.simpleaudio :)

I misunderstood then. I thought you were saying that std.simpleaudio should be implemented using one of these platform abstractions. Actually it could, but I think it'll diminish its value.

This doesn't contradict itself ;) I think it would make sense to let simpleaudio use one of these abstractions so it's easier to port it to new platforms (ideally there wouldn't be any porting involved it all because the abstraction already does that). But the user using simpleaudio shouldn't be bothered with these details - the interface for simpleaudio should be the same regardless of what it uses to communicate with the sound hardware (OSS/ALSA/windows whatever/SDL/...). It needs to abstract away these details anyway to be the same on windows/Linux/OSX/...
Apr 12 2011
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
If you use OSS, it's completely worthless. I know OSS4 is great, but most 
modern distros don't use it. If sound is playing, it won't work (unless 
launched with padsp/aoss), if it isn't, you've suddenly blocked sound for 
the user. I really don't give shit how simple it is, or the politics, it's 
a bad user experience for most on Linux.

Don't waste our time with a sound module that defaults to OSS on Linux.
Apr 13 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
From reading about it more it seems PortAudio is usable as an MIT license.

Apr 13 2011
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Andrej Mitrovic wrote:
 What about PortAudio?

Any idea where the usable documentation is? I glanced through the wiki but it seems to devote all its time to explaining how to compile it... not a good sign. btw though, this is one of the reasons why I often prefer doing it myself rather than using libraries. Libraries often don't do what I want anyway, and if they do, it takes longer to figure out how they work than it does to just read the underlying spec! Add on the runtime and license requirements and it's just blargh. I might just put in a simple alsa branch to satisfy the ones who want that and leave it at that until SDL 1.3 goes stable. At that point we can reconsider bringing it in. SDL works pretty well, has decent documentation, and I already know how to use it anyway.
Apr 13 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Yes, tutorials are here:
http://www.portaudio.com/trac/wiki/TutorialDir/TutorialStart

Well in any case, if MIT is Boost compatible and you're stuck on an
implementation problem you could take a look at the portaudio sources.
It has good source-code documentation and is well organized, from what
I can tell.
Apr 13 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
What about PortAudio? It seems to have some kind of custom license, so
I don't know if it's boost-compatible:
http://www.portaudio.com/license.html

It does look quite permissive, so if it's boost-compatible I see no
reason not to use it. It takes care of handling playback for you on a
multitude of platforms, with support for multiple audio driver
standards (ASIO/WDM/*nix types..). All that's left is to make routines
that can read/write different types of audio files. libsndfile is a
good library, but that one is licensed under LGPL.

I've been using it myself and it works fine for high-latency and
low-latency audio playback and sequencing.
Apr 13 2011