digitalmars.D - Anyone interested in simpleaudio.d too?
- Adam D. Ruppe (39/39) Apr 11 2011 I just dug up my old wav.d and quickly added wav.play() support
- Adam D. Ruppe (6/6) Apr 11 2011 Oh, I forgot to mention. Right now it is wav.play() but if I
- Daniel Gibson (9/37) Apr 11 2011 Hmm I think for output (both for video and audio) it may really be
- Michel Fortin (7/9) Apr 12 2011 Any reference for that? The website says LGPL or commercial license.
- Daniel Gibson (6/14) Apr 12 2011 Yeah,
- Mike Parker (6/18) Apr 12 2011 Also see,
- Adam D. Ruppe (8/10) Apr 12 2011 SDL 1.3 looks quite nice, but it's going to be several months
- spir (13/34) Apr 12 2011 An excellent article on the topic:
- Daniel Gibson (11/49) Apr 12 2011 ALSA is the de facto standard on Linux.
- Michel Fortin (15/17) Apr 12 2011 The problem with intermediary libraries is that they require work on
- Daniel Gibson (4/20) Apr 12 2011 Err.. I didn't say "don't use std.simpleaudio" but "don't use OSS/ALSA
- Michel Fortin (8/28) Apr 12 2011 I misunderstood then. I thought you were saying that std.simpleaudio
- Daniel Gibson (11/39) Apr 12 2011 This doesn't contradict itself ;)
- Bernard Helyer (6/6) Apr 13 2011 If you use OSS, it's completely worthless. I know OSS4 is great, but mos...
- Andrej Mitrovic (11/11) Apr 13 2011 What about PortAudio? It seems to have some kind of custom license, so
- Adam D. Ruppe (13/14) Apr 13 2011 Any idea where the usable documentation is? I glanced through the wiki
- Andrej Mitrovic (6/6) Apr 13 2011 Yes, tutorials are here:
- Andrej Mitrovic (0/1) Apr 13 2011
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
Adam D. Ruppe <destructionator gmail.com> 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
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
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
Am 12.04.2011 12:55, schrieb Michel Fortin:On 2011-04-12 00:46:18 -0400, Daniel Gibson <metalcaedes gmail.com> said:Yeah, http://slouken.blogspot.com/2011/04/exploring-galaxy.html?showComment=1302234229839#c4323023909103671526 (slouken is Sam Lantinga, the main developer of SDL) Cheers, - DanielEspecially 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>
Apr 12 2011
On 4/12/2011 7:57 PM, Daniel Gibson wrote:Am 12.04.2011 12:55, schrieb Michel Fortin: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.On 2011-04-12 00:46:18 -0400, Daniel Gibson<metalcaedes gmail.com> said:Yeah, http://slouken.blogspot.com/2011/04/exploring-galaxy.html?showComment=1302234229839#c4323023909103671526 (slouken is Sam Lantinga, the main developer of SDL)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>
Apr 12 2011
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
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
Am 12.04.2011 13:10, schrieb spir:On 04/12/2011 06:30 AM, Adam D. Ruppe wrote: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, - DanielI 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
Apr 12 2011
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
Am 12.04.2011 13:44, schrieb Michel Fortin:On 2011-04-12 07:18:39 -0400, Daniel Gibson <metalcaedes gmail.com> said: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 :)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.
Apr 12 2011
On 2011-04-12 07:47:48 -0400, Daniel Gibson <metalcaedes gmail.com> said:Am 12.04.2011 13:44, schrieb Michel Fortin: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/On 2011-04-12 07:18:39 -0400, Daniel Gibson <metalcaedes gmail.com> said: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 :)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.
Apr 12 2011
Am 12.04.2011 14:40, schrieb Michel Fortin:On 2011-04-12 07:47:48 -0400, Daniel Gibson <metalcaedes gmail.com> said: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/...Am 12.04.2011 13:44, schrieb Michel Fortin: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.On 2011-04-12 07:18:39 -0400, Daniel Gibson <metalcaedes gmail.com> said: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 :)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.
Apr 12 2011
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
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
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
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
From reading about it more it seems PortAudio is usable as an MIT license.
Apr 13 2011