unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dirk Scheuring <scheuring@gmail.com>
To: guix-devel@gnu.org
Subject: Re: A secure multimedia workstation
Date: Tue, 10 Feb 2015 16:21:27 +0100	[thread overview]
Message-ID: <CALvC8ZAvM5+9Wjvzyy3Xmq9EuYV7C_6fz7n7DaT25k3iWqtPfA@mail.gmail.com> (raw)
In-Reply-To: <20150209182303.GA24693@debian>

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	other threads:[~2015-02-10 15:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-02 10:11 A secure multimedia workstation Dirk Scheuring
2015-02-05  1:24 ` 宋文武
2015-02-07 23:08 ` Ludovic Courtès
2015-02-09 17:33   ` Dirk Scheuring
2015-02-09 17:55     ` David Thompson
2015-02-09 18:23     ` Andreas Enge
2015-02-10 15:21       ` Dirk Scheuring [this message]
2015-02-10 15:45         ` Ricardo Wurmus
2015-02-10 15:56         ` Ludovic Courtès
2015-02-10 18:37         ` Andreas Enge
2015-02-11  8:25           ` Dirk Scheuring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALvC8ZAvM5+9Wjvzyy3Xmq9EuYV7C_6fz7n7DaT25k3iWqtPfA@mail.gmail.com \
    --to=scheuring@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).