Show HN: Libsoundio 1.0.0 – cross-platform audio input and output(libsound.io)
libsound.io
Show HN: Libsoundio 1.0.0 – cross-platform audio input and output
http://libsound.io/
41 comments
I'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.
Andy, 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.
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.
> 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 :)
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 :)
1) 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 !
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 !
> 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/
[2]: https://salt.bountysource.com/teams/gdaw
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/
[2]: https://salt.bountysource.com/teams/gdaw
Genesis 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.
Please 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.
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.
I 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
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
I have some stuff drawn on paper but the UI is very much all up in the air at this point. When the project gets further along the project will be ready for a more interesting UI discussion.
Heh. On OpenBSD you'd have libsoundio on top of libsndio.
Yeah, I realized that a little bit late, heh. I did search for "libsoundio" to see how unique that was, but I did not find libsndio until later.
My 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?
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?
I'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!
You're welcome, and don't be afraid to open an issue if you run into a problem.
Very 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 ..
Thanks for the compliment.
Looks 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.
It 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.
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.
I'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-Po...
[1] https://github.com/andrewrk/libsoundio/wiki/libsoundio-vs-Po...
I'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.
Looks very nice and I can't wait to see it in action in Genesis.
Cross-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.
How 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.
Unfortunately, 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.
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.
It 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.
Compilers 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!
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!
Nice. 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.
It is something I am looking already some time for a multiplatform way to get the main mix stream.
The example on the front page includes this line:
int default_out_device_index = soundio_default_output_device_index(soundio);
Can 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.)
You can do that on systems that support it, like JACK and PulseAudio.
So 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!
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!
Some 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 but it really needs a FOSS competitor.
Right, so on systems with "Stereo Mix" device, you could use libsoundio to capture from it.
This is awesome! The next CSound or ChucK or SuperCollider could be built on this...
Does it support MIDI and inter-client synchronization like Jack does? (or better)
No, that is out of scope. But it is perfectly acceptable to depend simultaneously on libsoundio and JACK or ALSA.
Any plans to support ASIO?
ASIO 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?
neat!