Hacker News Reader

Comment by PaulDavisThe1st | Hacker News Reader

Here's a list of the libraries we use in the Ardour project. Let me know how the, what is it, "crate" situation is for these or equivalent libraries:

atk, atkmm, aubio, autoconf, automake, bison, boost, cairo , cairo , cairomm, cmake, cppunit, curl, expat, fftw, flac, flex, fontconfig, freetype, gdk-pixbuf, gettext, glib, glibmm, gnome-common, gnome-doc-utils, gobject-introspection, gtk-doc, gtk-engines, gtk+ X, gtk+ Quartz, gtk+, gtkmm, gtk-osx-docbook , harfbuzz, intltool, itstool, jpegsrcva, libarchive, libffi, libiconv, liblo, libogg, libpng, libsamplerate, libsigc++, libsndfile, libtool, libusb, libvorbis, libwebsockets, libxml, libxslt, lilv, LRDF, lv, libgnurx , NSS, NSS-PEM, pango, pangomm, pcre, pixman, portaudio svn rev, raptor, rasqal, rdflib, readline , readline , redland, rubberband, serd, sord, sratom, suil, taglib, tar, termcap, tiff, util-linux , uuid , vamp-plugin-sdk, xz, zlib

View on HN

That is a great question. While I'm not going through all the dependencies, I can give a brief overview.

First off, a lot the crates we use are actually just bindings or abstractions over these essential parts such as os-specific windowing stuff. Winit and Glutin are the main examples.

For OS audio stuff, there is cpal, but we found that the way it's designed is not the best for a DAW (no duplex support or MIDI). We may end up creating our own solution under the rusty-daw-io repo, although someone is also looking into creating bindings to RTAudio.

We are using femtovg in place of cairo. The developer of our GUI library is also working on improving the text layout and shaping inside femtovg.

We are using Symphonia for decoding audio files (although we may end up binding to ffmpeg if it doesn't work out).

We aren't using any networking in mvp, but there is no shortage of networking crates in rust.

We will also likely use bindings to libsamplerate if we find that a native Rust one is not good enough.

I don't recognize a lot of those dependencies. If there is a crucial one I missed, please let me know!

Of course some would point out why use Rust if you are using so many non-Rust dependencies? That is a fair argument. Me and my team just really prefer writing in Rust, so we are willing to put in the extra effort of using bindings.

A large chunk of those libraries come the depstack of our GUI library (GTKmm). Pango, Harfbuzz etc. are all just dependencies for the GUI library, but also our own Canvas library (we had to write our own, since nothing out there came close to requirements; the Canvas is heavily Cairo-based but could fairly trivially be ported to any 2D drawing API).

More DSP-y/audio-centric libraries would include:

  fftw - fastest fourier transform in the west
  rubberband - the only open source stretcher worth using (though we do have code to use soundtouch also)
  lilv,serd,sord,sratom,suil - LV2 infrastructure
  vamp-plugin-sdk - for offline (non-realtime) audio analysis
  aubio - used by VAMP
  liblo - almost certainly the best FLOSS OSC library

We created our own audio/MIDI I/O abstraction initially based on JACK (which was initially based on Ardour :). The Windows version uses PortAudio which has its pros and cons; the macOS version directly uses CoreAudio; the Linux version directly uses ALSA (and then there is a separate cross-platform JACK one too).

Nice. I have not heard of rubberband. I'll definitely take a look into it! For FFT I believe there is a native fft crate in rust which we'll likely use. I just haven't gotten around to making any spectrometers yet.

We're not using any OSC in the mvp, but I'll keep those libraries in mind.

Someone else is independently working on their own LV2 and VST hosting crate, which is what we'll use too. We may need to end up implementing our own VST3 and AU hosting code when the time comes.

The goal of the rusty-daw-io crate is pretty much what you described in creating an abstraction over Jack, Pulseaudio, CoreAudio, and Alsa. Although I'm going to see if using bindings to RTAudio could save us time and effort here.

Also, what do you use offline audio analysis for? Sounds interesting.

The offline analysis is for now used only for transient detection (so you can split by transient, and potentially "conform" a transient-laden track (e.g. percussion) to fit the tempo).

I wanted to use VAMP for tempo detection as part of the new clip launching features, but found that the code it uses really doesn't work well on short (1/2/4 bar loops). I ended up (for now) using Minibpm, a single-file implementation from Chris Cannam, who is responsible for both rubberband and VAMP. It's not perfect. but for the most part it works really well. Even the Live manual notes that they will sometimes "guess" the tempo incorrectly, typically by a factor of 2 in either direction.

Neat!

I don't know, but it's hardly as interesting as whether someone can create a full cross-platform GUI using the ecosystem. Just a year ago the support for that was next-to-nonexistent.

My point is that for large-scale software like a DAW, you either need a LOT more than a cross-platform GUI, or you will be reimplementing a very very large body of code that has existed in FLOSS form (but other languages) for (in some cases) decades.

Or just generating bindings for it. Bindgen exists for this reason. A minority of libraries such as that will require a smarter wrapper but for most it is probably sufficient to just use it in a reasonable way.

...sure. But then you start to lose one of the most talked-up benefits of Rust, "safety". Or am I missing something?

You are missing something. For a piece of Rust software to run in any widely used computing environment, it is required to interface with a large body of non-Rust software via a non-typechecked ABI. Moreover, the Rust standard library itself contains many, many instances of the unsafe keyword. The benefits of Rust safety do not come from building a hermetically isolated tower of pure safe Rust code from the ground up, and those benefits do not become null and void the moment you include one C library used via FFI.

Rust safety is about being able to take an unsafe component, encapsulate its implementation details, and encode sound usage patterns for that component in a public API which can then be statically checked by the compiler. This allows the difficult problem of determining whether an entire codebase is sound, memory-safe, and free of undefined behavior to be factored into many smaller, more tractable problems of verifying that individual components are sound given their APIs. You can even do this with wrappers and bindings to C libraries, and there are many examples of this in the Rust ecosystem.

Wins are often incremental. It's much better to start with the potential of guaranteed safety, sidestepped by a manual (opt-in) sacrifice of it in favor of getting something working, and slowly chipping away at the unsafety over time; than to start with the dispensation of safety as an institution altogether (C/C++) and hope that someday you can work your way to safety.

Put another way, as a developer, I'd much rather be part of a project using a language that is safe by default, which opts in to the unsafety it needs yet which hopes to someday simply remove all the `unsafe` keywords, than one that hopes to stumble its way to safety through relentless trial and error, testing, bug reports, debugging, etc. and has no actual measure of its level of safety.

On top of that, if you only use, say 10% of one of those libraries, you can easily wrap the 10% of that library in a safe fashion instead of waiting for 100% of the library to have its own safe wrapper.

Reply on news.ycombinator.com