guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A secure multimedia workstation


From: Dirk Scheuring
Subject: Re: A secure multimedia workstation
Date: Tue, 10 Feb 2015 16:21:27 +0100

Andreas Enge wrote:

> ... Definitely you could start helping the Guix project (and your own
project) by packaging software that you are interested in and that we do
not provide yet. Some guile/scheme knowledge is helpful, but not
strictly required, see
https://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf Some
experience in installing software by hand is needed, though.  The irc
channel is usually a good place to ask for advice.

This is interesting. You seem to make packaging much easier than I
thought it would be. I wonder why that is.

I know next to nothing about Guix yet, but I know some things about
audio production software, and the problems you can experience while
running it. For example, Ricardo Wurmus (1) recently added Ardour (2), a
popular Digital Audio Workstation. Ardour depends on JACK Audio
Connection Kit (3), as do many applications in the Linux Audio
ecosystem. Multimedia distros like Ubuntu Studio and KXStudio include
JACK, plus a kernel version compiled with the -lowlatency flag, to
prevent dropouts/xruns when you're doing multichannel audio recording in
Ardour, which might also have other samplers, synthesizers and drum
machines feeding into it for playback, through JACK. So you want a
kernel that prioritizes audio throughput above all else.

I wouldn't know whether such a kernel was available for Guix currently,
and if it wasn't, I wouldn't know how to compile one, and make it
available. I would have to learn these things first, before I could
start packaging something like Ardour. At least, so I thought.

Moreover, there are production workflows which depend on Ardour being
connected to other programs (5) which in turn depend on JACK. So I
thought that I would have to track down all those interdependencies
between programs, and include knowledge about them, libraries, etc. in
the package receipt. I have to learn how to do that before I can
seriously contribute, don't I?

Also, not all audio applications support JACK. PulseAudio tends to fight
with JACK, both trying to grab the audio hardware, but several other
popular apps use PulseAudio, rather than JACK, as their audio
server. The solution here is to configure PulseAudio to pipe its output
into JACK, and as I'm trying to find out how to do that (6), I stumble
across the remark

"I performed the following changes to the files in /etc/pulse"

when I realize that there is no /etc/pulse in Guix! Rather, the
configuration files are represented - as is everything else - by their
contribution to the hash values in /nix/store. Or that's how I currently
understand it.

So it seems like I have to learn how to map the relevant parts of the
LSB to /nix/store, and I will also have to find out which parts are
relevant for any program I have to include in my package, and I have to
learn how to express this information in my receipt, so that the build
process can use it successfully. And the deeper I crawl into this rabbit
hole, the longer my list of known unknowns grows, while unknown unknowns
remain unknown. I figured it might take me a while to work through all
this, given that I have other jobs, and a family.

Or am I overcomplicating things here? Thanks for any advice,

Dirk

(1) http://lists.gnu.org/archive/html/guix-devel/2015-01/msg00477.html
(2) http://en.wikipedia.org/wiki/Ardour_%28software%29
(3) https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit
(4) 
https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit#Low_latency_scheduling
(5) http://kxstudio.sourceforge.net/Applications:Cadence
(6) 
http://askubuntu.com/questions/100862/running-jackd-on-startup-replacing-pulseaudio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]