Re: [Audacity-devel] Audacity workshop on Sugar OS

[Richard A. <ri...@au...>]

On Sat, 2010-08-21 at 21:04 +1100, Sean Linton wrote:
> I am looking at presenting some of the potential uses for Audacity on
> the OLPC XO computers and sugar system at an up coming Pacific Chapter
> Internet Society Conference.
> 
> Lately I have been discussing with people the potential to use
> Audacity as a way of helping communities create content, and
> distribute recorded programs and music to community radio stations. 
> 
> It seems that the OLPC or (Sugar labs) developers have taken the idea
> so far and have not really been able fully integrate Audacity into the
> Sugar system. 
There is no reason why this should be any harder than any other Linux
application, as Audacity for Linux is a normal GTK+ application. The
problem is the user-space Sugar layer on top of the Linux kernel, the
restrictions that imposes on applications, and the sugar features that
can't be accessed from "normal" applications.

> Versions of the program will run fine, however for Sugar users there
> are a few things that could be looked at which would help streamline
> the process of using Audacity as a way of creating community media. 
> 
> The first thing is the ability to save an Audacity file onto a USB or
> SD card. The XO computer is a solid state net book and has at most 4
> GB storage, and closer to 500mb - 1GB on average. For the big files
> that Audacity generates some external media support will probably be
> needed. At this stage I am confronted with permission errors if I try
> to write to my flash drive, I know this is not a problem with the
> drive or Sugar because I have Sugar writing to the drive without any
> difficulty?   
It is nothing that Audacity will be able to fix. Reading around the web
it seems that Sugar has subverted the normal GNU/Linux usage of users
and groups, which Audacity of course is unaware of. That said, I think a
little careful scripting should allow Audacity to work in most
conceivable environments by setting an appropriate Umask and default
group before running Audacity.

What could be done from there onwards I don't know without having access
to an OLPC system (including kernel I suspect, so just Sugar on it's own
would probably work fine out of the box).

> I am also looking at how mp3 support would help in terms of creating
> widely accessible formats, I appreciate that OGG is superior in many
> ways including accessibility but it seems that without mp3 support
> exporters are limited to computer hardware in many ways. It is a shame
> that the computer terminal should monopolize the products that
> audacity is capable of exporting.  
>  
> I have had some advice about LAME and the Fedora repositories but I am
> thinking about how this can resolved by the average sugar user. 

Custom .xo packages? But you would have to host them (somewhere
tolerant) yourself. With care you wouldn't need root access to install
it, providing that you also brew audacity to install in a custom prefix
and can allow the LAME package to install in the same custom prefix.

> Finally the mesh networking between the XO computers allows great
> support for peer to peer collaboration. Currently applications can be
> shared with a neighborhood and be worked on remotely, Audacity support
> for this feature would represent a great step forward in utilizing the
> potential of an empowering technology in the hands of young people.  

That's a really major challenge, because Audacity's project structure is
designed for aggressively single-process access (quite largely
single-threaded, with locking to enforce this). Basically, the problem
is the same as for graphics - how do you merge changes from multiple
sources in multiple directions? A distributed version control system
like Git does this, but only for plain text where diffs can be used to
decide what changes to take. It also has no way to cope with files that
depend on changes elsewhere, which an audacity project structure is full
of.

There is also a practical problem, which is bandwidth and access times.
In order to play back audio, it will need to be on the local disk (or
other local storage). So each user in a multi-user scenario will need to
hold a complete local copy of the data set, and propagate any change
made to all the other users in the session, whilst simultaneously
accepting changes from other users. This propagation will be bandwidth
intensive, even if you found a way to use FLAC lossless audio codec to
reduce file sizes (which would be CPU intensive).

Audacity beta does already have the facility to export projects
compressed using Ogg for uploading, but this is only a way to transfer
complete projects (once you have closed and exited Audacity), and the
lossy compression means I wouldn't want to do a lot of transfers because
it would degrade the quality progressively. There is no automated way to
merge projects other than to open them all (from different directories)
and manually copy and paste tracks to and fro.

Overall, I don't think there is a great deal of Audacity development
interest in running Audacity within the Sugar environment (given that it
is known to work on the hardware just fine without Sugar in the way),
especially as the hardware availability continues to be doubtful. If
someone comes up with non-invasive patches to make it work better and
that don't affect using Audacity normally, then we will consider them,
but doing any significant work is unlikely.

Richard