Nice new app, run on Linux!

[dovidhalevi]

This is a nice new app, not as much a resource hog as some sound programs. New interface to learn but looks nice.

Run it on Linux? Yes, indeed. The Wine windows emulation layer with an addition of a wine-asio driver and voile. Runs quite nicely.

BTW, if one can compile it for a Mac (BSD-unix ased), one could most probably compile it native for Linux as well. How about it, mu-guys?

[pljones]

Is it running okay for you under wineasio? (Mmm, which version?) What's your PC spec? Last time I tried it, it was still a bit glitchy, although that was prior to the RCs coming out. I'll have to run it again!

<later>
Yes, it seems a lot better now. I'm running JACK at 2.9ms latency. CPU's running pretty high:
Transport not running:
Bach.MuSession - 10%
Demo.MuSession - 18%
KraftGroove.MuSession - 36%

Transport running:
Bach.MuSession - 27-38%
Demo.MuSession - 44-45%
KraftGroove.MuSession - 44-49%

Test system:
Kernel 2.6.22-14-rt (and see sig below)
Ubuntu Hardy Heron (alpha)
wine-0.9.52

Screen updates were very slow. The character redraw as the transport position advanced was very visible. Transport position updates weren't as smooth as Windows - about four redraws per bar, I'd estimate, on KraftGroove (much better on Bach). I'm not sure how the -rt scheduler works, particularly, but it could be that the UI thread simply isn't allowed much time if the RT thread is being heavily used?

I got xruns when playing DaHornet...
</later>

[dovidhalevi]

A very good, complete post. I did not run any benchmarks, just fired up one of the demos to see IF it worked and it did. I do have a problem on program exit, possibly because of the two views.

I cannot pin the source of the slow UI repaints but some apps have this problem, others do not. Certain VSTs run using one of the Linux hosting alternatives have this problem, others do not.

For a comparison, Tracktion (version 1 freebie) will also run. Playback is troubled (but their demos do run a load of plugins). Tracktion is based on its authors' opensource Juce framedwork and could be compiled quite readily for Linux, but since most Linux freeks don't shell out money for expensive (or even inexpensive) software, the authors will not bother. Since MU has a free "cripple-ware" version and a very modestly priced complete version, it might be worthwhile to do it--would run jack directly without the benefit of ASIO but VST would still be available. EnergyXT is another such package that runs in Linux out of the box (an achievement!) but they had to open their sources to some third party to get jack support.

In the end, I would like to see all this opensource. Geeks like me will compile and fudge around but many audio pros would still rather shell out a modest price and have a finished turnkey package.

[pljones]

...Linux CPU...
Transport not running:
Bach.MuSession - 10%; .. Demo.MuSession - 18%; .. KraftGroove.MuSession - 36%

Transport running:
Bach.MuSession - 27-38%; .. Demo.MuSession - 44-45%; .. KraftGroove.MuSession - 44-49%

Windows CPU:
Transport not running:
Bach.MuSession - 4%; .. Demo.MuSession - 8%; .. KraftGroove.MuSession - 20%

Transport running:
Bach.MuSession - 13-18%; .. Demo.MuSession - 24-26%; .. KraftGroove.MuSession - 27%

My Windows system is generally running pretty lean but I did these tests with Firefox, Thunderbird, Eclipse (IDE), foobar2000 and Pidgin running (idling). On Linux, in addition to that lot, I have a webserver and an icecast server running (idling), along with most of the system services Ubuntu runs by default (I'm lazy about turning them off as I'm not using it seriously yet).

I'd like to try something similar with Reaper, as that runs smoothly on Linux, too; I've not been clocking its CPU or comparing with Windows. It would be interesting to see whether the difference is common to the different OS or particular to an app (indicating possible room for optimisation). I've not had any screen redraw problems with Reaper, but it uses pretty much the Windows API for drawing its widgets (given the look'n'feel), so it gets full benefit from WINE's native widgets (<- WINE Is Not an Emulator ). MULAB, of course, has its own widgets.

[pljones]

I do have a problem on program exit, possibly because of the two views.

Oh, it could be! I have to remember to use ctrl-q (or File->Quit) to quit rather than close the window.

[pljones]

Eep.

Try adding a plugin to the MPA. Right-Click... The option "Add Plugin" doesn't do anything. Load up a MuSynth in a Rack, load a patch and switch to deep editor. All the components show up okay. Right-Click... Still "Add Plugin" does nothing. (Run from a console window, there are no obvious WINE problems occurring.)

[muzycian]

Just FYI: MU.LAB on Linux is not (yet) supported.

[pljones]

Works pretty well, though. (And I bet fixing the issues Linux has are going to make it work better on the other platforms, too...)

[muzycian]

I can't yet do any Linux research as i don't have a linux here.

Just some quick linux questions for my personal interest:

-> can you easily install linux on a win xp machine without creating any windows installation troubles?

-> how much harddisk space does the linux os take?

-> is it still the case that there are multiple linuxes: one optimized for this kind of work, one optimized for that kind of work, etc...?

-> are there many vst plugins for linux?

-> what about audio hardware: are ALL audio devices supported by some generic driver thing? (cfr some asio4all thing). Or do you need a linux specific driver for your audio device? In the latter case: what % of audio devices is supported?

[deleted]

DELETED

[muzycian]

Thanks for the info michi!

Not that i plan going into linux soon, but i never hurts to get some more detailed view on it.

[pljones]

BTW there is a "pljones" mentioned in the code of wineasio ?!?

Now how did that get there? wineasio is just a translation layer for JACK so that it looks like a simple ASIO driver to WINE. I added some more complex configuration support, tidied the code up and slapped the two teams around who were trying to work on the code independently so there was one single source tree again .

If I were recommending a linux to try, I'd say JackLab or Ubuntu (I believe both have "live CDs" -- you boot off the CD but your configuration is held on your PC in a single file on a Windows partition, usually). Ubuntu also has another install option that uses the Windows filesystem without requiring repartitioning or a bootloader change (well, it adds to the Windows boot.ini). I run Ubuntu when I'm playing with Linux - I gave it 11Gb and it's using over half that now. You can read/write NTFS from Linux safely these days (and ext2/ext3 from Windows) -- I use exactly the same profile for Firefox and Thunderbird whether I'm in Linux or Windows.

If you've used MIDI Yoke on Windows, JACK is kind of like the same thing for Audio, letting you patch between applications. Not all audio apps use JACK, though (mostly they're ones that aren't being developed any more but are still around because they're interesting).

There are "LADSPA" plugins, kind of like GUI-less VST effects. You can also wrap a VST or VSTi and use it with JACK - either with FST or the DSSI tools. (FST is easier, needs WINE but provide the GUI; DSSI turns the VST into a LADSPA plugin, I think - I've not used it.)

You can find a list of ALSA-supported hardware on the ALSA site but as michi says, it's probably supported. (My Echo Mia took a while, though!)

Basically, though, a host can get away with supporting JACK for audio and ALSA's MIDI. (JACK is also available on Windows and OSX, so you can test support for it without installing Linux if you want.)

[muzycian]

Thanks for the detailed info guys.

Pfew, this all sounds very / too technical...

Of course, as a technician, i could find my way thru;

But i'm afraid most musicians won't.

And i'm choosing the musician's side.

Anyway, i stay open.