6 ms·
Show HN: Libsoundio 1.0.0 – cross-platform audio input and output
- rainabba 11y agoLooks very nice and I can't wait to see it in action in Genesis.
- melissanoelle 11y agoI'm his partner and I've watched him work on this tirelessly for the past 9 weeks and I've seen how much dedication and research he's put into every aspect of this.
- 0x400615 11y agoYou should be very proud of your partner.
- melissanoelle 11y agoI am very, very proud of him.
- brickmort 11y agoneat!
- baldfat 11y agoMy sound engineering side thought one thing: Latency - It isn't bad for vocals or if you are playing a single audio source, but if you have multiple of sound sources and ALSA and JACK devices playing how are you going to handle latency?
- robhack 11y agoLooks very interesting, I might switch from PortAudio to this for my project. But I think I'll wait a bit though, I'm not quite ready to give up on WinXP/Vista support yet.
- pierrec 11y agoIt relies on WASAPI for Windows, so it should work on Vista which is the first version to introduce that API (unless I missed another requirement). And as a side note, that is definitely the way to go. WASAPI is a massive improvement over previous windows audio APIs, especially for low latency / pro audio. I'm flabbergasted that some DAWs still don't support it.
- robhack 11y agoI'm confused, does it support Vista? The PortAudio comparison made me believe it doesn't, as this is written in PortAudio's pros : « Supports older versions of Windows than Windows 7. » [1] [1] https://github.com/andrewrk/libsoundio/wiki/libsoundio-vs-PortAudio https://github.com/andrewrk/libsoundio/wiki/libsoundio-vs-Po...
- AndyKelley 11y agoI've only tested on Windows 7, but looking over the API functions I used, I could probably relax the restriction to Vista. I'm not sure I'd be willing to extend testing and support to Vista without getting some funding. It feels harsh to say, but I have ambitious plans which will be stalled if I git bogged down with deprecated and proprietary software.
- bch 11y ago1) this looks very cool. Nice to see a pure C lib developed with such apparent restraint. 2) any plans on support OSS for things like *BSD/Solaris ? 3) plans to support writing out to disk with even a single format, like .au, or .wav ? I'm looking forward to playing with this !
- AndyKelley 11y ago> any plans on support OSS for things like BSD/Solaris ? BSD/Solaris support is within scope, however I am now going to focus my development efforts on Genesis DAW [1]. So the way that these other backends can get support is: * someone contributes code * enough is contributed financially[2] to support me working on more backends. > plans to support writing out to disk with even a single format, like .au, or .wav ? Would you like to file an issue and explain the use case? Let's talk it over. [1]: http://genesisdaw.org/ http://genesisdaw.org/ [2]: https://salt.bountysource.com/teams/gdaw https://salt.bountysource.com/teams/gdaw
- pierrec 11y agoGenesis looks super interesting. After going through the first posts I have a lot to say about it - I will probably write to you, or post a rant somewhere. But I will say this right away: I'm unlikely to ever use it, unless some holes are poked into the walled garden that you're planning. Digital musicians are hackers, and a quick glance at the history of DAWs should reveal the paramountcy of free modularity.
- AndyKelley 11y agoPlease do write to me, I'd love to read your feedback. I'm trying to go for the very opposite of "walled garden" so I'm really interested to hear your concerns about that and how I could make it better.
- veli_joza 11y agoI looked into Genesis but it's hard to get a feel of what the final product will look like from screenshots. Do you perhaps have some mock-ups? For me UI is more important than feature-set; the interface that doesn't get in my way increases my creativity. Especially if I'm recording and I have to switch between playing instruments and operating complicated software. The only DAW that I think gets it right is MultitrackStudio[1], with perfect combination of features and effortless interface. [1] http://multitrackstudio.com/screenshot_standard.png http://multitrackstudio.com/screenshot_standard.png
- nice_byte 11y agoI've been writing a library that is essentially a wrapper over OpenAL and libogg/libvorbis to provide a simple interface for playing encoded sound samples or streams. However, OpenAL is a pain, and the only decent free implementation seems to be OpenAL-soft, which seems to be doing all the mixing in software. This library could be a good replacement, thanks author!
- AndyKelley 11y agoYou're welcome, and don't be afraid to open an issue if you run into a problem.
- andresmanz 11y agoCross-platform, open source, lightweight and C(++). The example code on the website could use a little clean-up, but it's fine. Perfect! Thank you, sir.
- AndyKelley 11y agoHow would you clean up the example code? I want the example code to be as clean as possible. Also, I must protest that it is C++. The library links against libc, not libstdc++, and the only non-C feature used in the source code is templates.
- binarycrusader 11y agoUnfortunately, just the use of templates may require linking to parts of some compiler's C++ runtime in some cases, depending on how they're used. Also, templates don't always work equally well across compilers. You'd really be better off with pure C. This looks like an excellent library, so please don't take that as criticism, just an observation.
- AndyKelley 11y agoIt sounds like your understanding and my understanding of linking are not compatible. I carefully link only with C and disable exceptions, run time type information, and check the output with ldd to make sure no C++ symbols snuck by. If I'm mistaken about how this works I want to know about it, but I'm still convinced that the generated library is indistinguishable from a library compiled with -std=c99 rather than -std=c++11.
- binarycrusader 11y agoCompilers are free to link their own internal runtime libraries into an executable beyond the ones you explicitly specify. The only time they are not is if you explicitly use options that prevent them from doing so; in the case of gcc, that's the -nostdlib or -nodefaultlibs as appropriate to your scenario. I do appreciate that you actually checked the output of ldd. Regardless, again, only as an observation, you'd still be better off with pure C. Even if you don't use standard C++ libraries, and have eliminated the need for any special runtimes, the rules of C and C++ are not the same, even as of C11/C++11. So there may be subtle interoperability concerns. Again, this is all merely observation; I haven't yet used your library, only airing potential technical concerns you may wish to research. Regardless, thanks again for your excellent contribution to the community!
- loomi 11y agoNice. Is there a way to fetch the main out audio? It is something I am looking already some time for a multiplatform way to get the main mix stream.
- judofyr 11y agoThe example on the front page includes this line: int default_out_device_index = soundio_default_output_device_index(soundio); Is that what you're looking for? Or something else?
- loomi 11y agoCan I then get everything what is played by all applications on this device. Like fetch and send through the network? (Not pushing audio to the main out.)
- AndyKelley 11y agoYou can do that on systems that support it, like JACK and PulseAudio.
- loomi 11y agoSo Linux only? I guess it would be a pretty unique addition to have a method to grab the main mix on Windows, Linux, and OS X in a common way!
- voltagex_ 11y agoSome Windows drivers had a "Stereo Mix" device under Recording to grab the currently playing audio. There's also http://software.muzychenko.net/eng/vac.htm http://software.muzychenko.net/eng/vac.htm but it really needs a FOSS competitor.
- AndyKelley 11y agoRight, so on systems with "Stereo Mix" device, you could use libsoundio to capture from it.
- btown 11y agoAndy, I just learned about your Genesis project, and it's great to see people pushing towards collaborative DAWs. I've been doing detailed planning for my own vision for a collaborative DAW for years now, though various other projects have kept distracting me from giving it enough coding time to get it off the ground! I'm curious how you're thinking of solving latency & disconnection issues between participants. It looks like you're representing things as a sequential list of transactions, and immutable transactions are definitely the starting point for everything I've considered! The question is: what happens if multiple people send each other conflicting transactions at the same time? Google Wave solved this by enforcing a single server-side ordering of all events, and making sure that all transactions would be accepted using Operational Transformation even if they occurred out of order. Without OT, you may have cases where Alice makes a change, only to have it invalidated and essentially erased by Bob's change that may have "won" on the server side. And while OT may be largely "solved" for text content, it doesn't seem well-studied for music or other timeline-based content. As an alternative, source control manages to get along fine without automated conflict resolution/OT, since we're willing to dive into merge conflicts and resolve things ourselves. So theoretically, you could create "Git for Music" and drive that from your app. But what's the UI equivalent of version control in a DAW? What, exactly, does a "diff" look like in musical notation? And how do you make it unobtrusive to non-coder musicians? All very interesting problems, and it's always great to have multiple innovators in this space! Would be happy to connect offline if you'd like.
- AndyKelley 11y ago> The question is: what happens if multiple people send each other conflicting transactions at the same time? Google Wave solved this by enforcing a single server-side ordering of all events, and making sure that all transactions would be accepted using Operational Transformation even if they occurred out of order. Without OT, you may have cases where Alice makes a change, only to have it invalidated and essentially erased by Bob's change that may have "won" on the server side. And while OT may be largely "solved" for text content, it doesn't seem well-studied for music or other timeline-based content. I've planned this out on paper. It's going to be solved in a peer to peer manner, no central server. It will work the same way that git rebasing works. When conflicting transactions occur simultaneously, there is a deterministic way to determine the order, then each peer rebases the transaction and resolves conflicts automatically in a deterministic way. Undo/redo is really complicated, but I believe I have a pragmatic approach that will work. I don't expect users to resolve conflicts; instead I will make the effort of editing small and leave it to users to manually correct automatic conflict resolution if there is a problem. No "diff"s, no coding knowledge necessary. Do feel free to email me if you want to chat about this problem :)
- AstralStorm 11y agoDoes it support MIDI and inter-client synchronization like Jack does? (or better)
- AndyKelley 11y agoNo, that is out of scope. But it is perfectly acceptable to depend simultaneously on libsoundio and JACK or ALSA.
- dbattaglia 11y agoAny plans to support ASIO?
- AndyKelley 11y agoASIO is within scope and the API is compatible. However, based on my research it looks like WASAPI is a superior alternative to ASIO. Do you have information that suggests otherwise?
- fitzwatermellow 11y agoThis is awesome! The next CSound or ChucK or SuperCollider could be built on this...
- fit2rule 11y agoVery clean and well-written codebase, I just spent an interesting 20 minutes reading your sources and I have been very happily observing your strict observation of smart rules and well-planned architecture. Well done on some cool code ..
- AndyKelley 11y agoThanks for the compliment.