Software dictates component choices even in proprietary editing softeware

[Ralf Mardorf]

Yet another mail my provider didn't send,
while I also didn't receive a postmaster reply. Sorry, if I should have
missed, if it should have come through the list.

-------- Forwarded Message --------
From: Ralf Mardorf <ralf.mardorf at alice-dsl.net>
To: ubuntu-studio-devel at lists.ubuntu.com
Subject: Re: Software dictates component choices even in proprietary
editing softeware
Date: Mon, 20 Jun 2011 01:11:23 +0200

On Sun, 2011-06-19 at 21:35 +0000, Luke Kuhn wrote:
> My experience has been that if you are building a machine especially
> to max-out open source multimedia editing, components should be
> selected for how they perform with Linux, not how they perform in
> Windows or anything else.  This is no different than many pro video
> editing packages. Avid used to sell their video editors only as
> complete machines build around their software. When they started
> selling the software by itself, they advised that only specific CPU's
> and videocards be used-and got buckets of complaints when people
> installed it on "unsupported" hardware.

Since I'm using Linux only I chose my hardware to fit to Linux and no
other OS, but it's hard to do that, resp. it's a crapshoot. Even Paul
Davis claims that he has got issues regarding to mobo + additional
hardware. There's no way to get information what set up will work.
> 
> There is a problem if NO hardware in a category supports Linux, of
> course. In that case we can either find a way to make Linux support
> the product (like ndiswrapper adapting prorietary wireless drivers
> does), or find a way to mod or hop up some other product to fill the
> gap.
> 
> 
>  Sound cards could be physically modded with different connections and
> mods to the analog circuitry.  This would mean starting with the
> requirements for connectivity and for audio quality, finding a card or
> cards for which it is possible to write a driver giving that audio
> quality and number of channels, and then adding a secondary board
> giving the external connections and signal levels. 
> 
> 
> If more channels are needed an array of cards feeding an external
> adapter box might work better, rather like some of those
> multi-graphics card gaming machines but for audio recording and
> playback.
> 
> 
>  I have given some though to the inputs that would be needed for an
> audio studio with multiple drum mikes and mikes for each instrument
> recording all in real time to separate tracks, and what I figured
> would be the solution is multiple sound cards on a board with plenty
> of pci or pci-e slots, two channels each from their left and right
> inputs , plus line and front mic inputs, possibly wired through an
> external box to accept standard cables. Should be able to build at
> least a 12-track physical setup this way with 6 cards,  maybe 16
> physical tracks with 4 cards or even 28 with 7. A driver would have to
> be written to treat all these cards as a single large soundcard with
> all these inputs and outputs.
> 
> 
> Publishing the circuit diagrams of the mod boards or adapter boxes
> would be the easiest and most open-source mode of distribution, so
> long as local production is not out of a hobbyist's or a paid
> techinician's capability.
> 
> 
> I think of selecting a computer in general  as being like selecting a
> gun, and the software as the ammunition, which is selected first.
> High-cost pro audio cards, and also the larger, power-hungry video
> cards, are rarely found and scavenged and repurposed machines, they
> are bought when a computer is built to to a job. My advice for dealing
> with such parts is this:  Ubuntustudio should publish a "blacklist" of
> parts it is known NOT to work with, so people building computers for
> it know not to buy these components.

There are a lot of blacklists and whitelists, and even greylists. I
tried to use a whitelisted modem for FAX, but too bad, there was a board
revision + a microchip that doesn't work with Linux, while there was the
claim that all revisions should be ok.

My computer e.g. doesn't work with Jack1, there at least is one coder
who has got the same issue.

But anyway, I agree that at least some experiences with sound cards
would be a good idea.

Since I made some first coarse tests with my RME HDSPe AIO + additional
ADAT device and did compare it with my Terratec EWX 24/96 cards I could
write something about "misunderstandings". E.g. that sync doesn't mean
identically phases, even if the dealer claims that there will be no
additional latency etc..

> In 2009 and 2010 I built two video editing machines to run kdenlive
> and audacity as fast as possible, and to be able to produce simple
> content in Blender. That meant AMD 4-cores back in 2009, the on-board
> sound on those boards as all functions worked fine with linux, and ATI
> videocards as their open-source drivers became effective in 2010.
> Install my exact package on something with different specs, and it may
> work poorly, maybe not at all if nvidia graphics are involved. It will
> run on the netbook, but only audacity, the web browsers, and small res
> video playback are expected to work there. Since the first machine
> works  well,  I built the second machine to be electrically an exact
> copy.

I read that people needed to switch the distro after doing an upgrade (64 Studio to AV Linux), because firewire audio devices that worked perfectly before the upgrade, didn't work after the upgrade, using another distro with current versions of apps, everything was ok.
> 
> 
> The real problem with Linux video editors is this: very little support
> for GPU rendering outside of Blender. Blender has only basic video
> editing included, though it can create  sequences from scratch.
> Cinelerra can use opengl to display effects, not to render, and
> kdenlive doesn't use it at all, so playback bogs down when effects are
> added. With source clips being in 1080i,  this is a real issue, and
> forces the use of the most powerful CPU's available.

I've given up to do serious video editing on my machine, but I hope
http://rg42.org/wiki/a3vtl will enable audio sync, since SMPTE is a big
issue and sync to Bosch or Sony machines can't be done, at least not
with Ardour as slave.
Building from svn didn't work for me yesterday, Robin wrote, that it
should work when building from git, at the moment he is behind upstream
development.
> 
> Kdenlive has bugs and issues, but costs nothing and what it cannot do,
> I can create as a separate clip in blender. Since the compression
> suck, I render out uncompressed and compress in avidemux, which runs
> very quickly on all 4 cores. If there were some way to merge the
> Blender, Cinelerra,  Kdenlive, and avidemux codebases into a single
> "Ubuntustudio Creative Suite" package, while fixing multithreading in
> ffmpeg and using openCL for rendering, we would then have a package
> competitive with commercial video editing suites.  Again like
> commercial stuff, rendering times could easily vary by a factor of 10
> to one between the "right" and "wrong" hardware!  In this case,
> ranking hardware for desirability would be the approach, rather like
> gamers with videocards.

A coder has written there are issues regarding to the colour depth,
regarding to bugs etc.. Anyway, if it should work for home usage, I
would use it.
> 
>  Scrounged hardware, which I have often used for standalone audio
> editors and web access machines, is a different scenario. Here the
> need is often to swap out stuff that Linux doesn't like such as older
> Soundblaster video cards. When you are stuck with a "random source"
> scenario, things get more difficult. For this, I recommend people try
> to find the distro that is the closest fit to what they have, again
> like finding ammo for an odd gun.
> 
> 
>  Video cards can be ignored in a non-accelerated, non video playback
> nor editing scenario, like when I was using an expendable Pentium II
> laptop to produce audio news reports from a dicey location. That had
> an odd audio setup that required a LOT of hacking to get any sound
> output as well. Having the "gun" I had to come up with the
> "ammunition" by customizing Ubuntu Jaunty.  I still have that box,
> won't upgrade the software due to the severe difficulty of making
> audio work on that old clunker.
> 
> 
> There are several reasons people stick with open-source multimedia
> software, no matter what the Windows/ pay software people have. For me
> they are issues of cost, issues of trust-and in my role as a far-left
> journalist, very fundamental issues of ideology. I regard the
> open-source community as operating in direct competition with the
> economic model I cover the oppostion to.  The trust issue is the
> security of encryption given problems with police raids on
> journalists-including myself. The cost issue is obvious-what I save of
> software, I can put into optimized hardware instead or not spend at
> all, or maybe I don't have access to such resources in the case of
> high-priced video editing suites. I would rather spend an extra 30
> minutes per rendering job than buy two licenses at $10K apiece for a
> pro video editing suite.
> 
> 
> In short, I see the market for Ubuntustudio and other open-source
> multimedia suites as being not the professional content creators, but
> the competition for the paid content producers.  It is my sincere hope
> that collaborative media projects and collaborative software both
> succeed in the long run in "overgrowing" their paid competition though
> sheer weight of numbers and the overwhelming advantage of being both
> free and controllable by the users. Someone making content for FOX or
> Hollywood can afford to have someone else set up their workstation,
> the rest of us cannot. That means people who want a serious
> content-creation machine are going to have to build it. Certainly a
> semi-pro studio serving a dozen neighborhood bands should be able to
> find  a hacker (and maybe a hardware hacker at that) able to set up
> their computer, and it helps if that hacker has some guidance so
> mistakes don't lead them to throw in the towel.
> 
> 
> Publishing blacklists of known troublesome hardware and whitelists of
> known best hardware-or even lists of "validated" hardware" like Avid
> does would mean that setting up a content creation workstation would
> not involve guesswork or multiple attempts to buy hardware that
> actually works.

I had to do this. While two test Windows installs worked OOTB, excepted
of MIDI jitter, but the jitter was more worse for Linux, Linux audio was
much more resource hungry and didn't like my computers, so I switched
one hardware component after the other. I'm not sure if everything is
fixed now and btw. for the KORG nano I installed wine ;). There already
is a python script, but because everybody claimed to use wine with the
proprietary editor, I won't be the guinea pig.

Btw. at the moment I'm testing Debian testing with a self build
$ uname -a
Linux debian 2.6.39.1 #1 SMP PREEMPT Tue Jun 7 01:40:05 CEST 2011 x86_64
GNU/Linux

If ex 2.6.39 should work I hope Oneiric will use it, since this might
solve some issues, e.g. the proprietary NVida driver does work on my
machine. Several people claimed that on their machines the proprietary
NVidia driver should have improved audio.

I'll switch distros when ever it's needed, to fit to my needs, as long
as those distros are based on .dep packages. Switching between .dep
and .rpm is something I'll stop and I won't learn how to handle distros
that go a different way as e.g. Gentoo does.

Btw. a whitelist at least will be subjective to quality issues.
With a fat purse it's possible to test tailor-made Apple and Microsoft
based machines. Searching the web, I didn't find this for Linux audio,
excepted of OEM products for some target groups, but not for all audio
users.