Support of audio interfaces under Linux

[wolftune]

So... After reading 5 pages of posts... Windows or MAC is the better choice for recording music??? I guess that the best thing for me (Us????) is to use Linux for our every day use, and have a PC/MAC setup for recording music???

The question is what you mean by "best". Because if you want to record on GNU/Linux, it's totally doable, there's some great tools and there is some totally working hardware. If you compare the situation, yes, we are nowhere near feature parity with Mac or Windows even though we have some advantages on our side. But the situation we have may not be where we wish it were, but that doesn't mean it isn't workable. We have a lot of good stuff going for us. But I can't say that makes our situation all around better — except that if you care about software freedom, you don't want to be forced into those entire proprietary ecosystems just to record music. You *can* do what you need to do in *most* cases with GNU/Linux, including *most* music recording stuff.

[asbak]

So... After reading 5 pages of posts... Windows or MAC is the better choice for recording music??? I guess that the best thing for me (Us????) is to use Linux for our every day use, and have a PC/MAC setup for recording music???

Neither.

Alesis HD24 or similar is a much better choice for recording music.

Failing that a reasonably well tuned computer with compatible hardware comes in a distant second. My guess is that a Mac + pricey hardware may get you up and running the fastest when starting out from zero ie no real knowledge about various computer and computer audio platforms.

For editing and production work of already recorded tracks it perhaps doesn't matter all that much what one uses but of course the true faithful of [insert-your-platform] will argue that their particular system is better because blah blah blah.

Linux can work quite well but because audio isn't a priority in its overall development, because of lack of support from hardware vendors and because of the limited size of the audio development effort it lags behind Windoze and Mac to some extent. Having said that it is perfectly possible to do pro-audio on Linux. It just isn't all that easy or straight-forward to get to that point unless you already know quite a bit about it.

[ChaoticGuitars]

Ok, I think I am understanding some of this. How about this question. What would the probability of the software that comes with "XXXX" audio interface works under installation under Vine. Is this viable or am I still looking for Bigfoot riding the Loch Ness Monster in french maid outfit????
And yes, I have weird dreams.

[wolftune]

Ok, I think I am understanding some of this. How about this question. What would the probability of the software that comes with "XXXX" audio interface works under installation under Vine. Is this viable or am I still looking for Bigfoot riding the Loch Ness Monster in french maid outfit????
And yes, I have weird dreams.

I think you mean Wine, not Vine. When interfaces come with VST plugins, that probably can work. Their custom control software probably not (but other folks are more expert on this than I). There are some cases where there is Linux support. If you mean when they come with limited versions of DAWs, just use a Linux DAW instead.

[ChaoticGuitars]

Wolftune, thank you for the correction, I did mean Wine. I appreciate yours and everyone else feedback. I am new and I have a habit of if I don’t know something I will ask. I have found it is better than bumbling through and hoping to figure it out. Its a stuck habit from the Army.... None the less..... Thank you

Jason

[asbak]

Ok, I think I am understanding some of this. How about this question. What would the probability of the software that comes with "XXXX" audio interface works under installation under Vine. Is this viable or am I still looking for Bigfoot riding the Loch Ness Monster in french maid outfit????
And yes, I have weird dreams.

It may work... maybe.... but there's not really much point in doing this. Performance is never going to be as good as on the native OS. If you want to run Windows software then use a Windows OS.

Ardour, Muse, Rosegarden, Qtractor, LMMS etc all work fine on Linux. The biggest challenge (at least for me) was to get the computer set up in such a way that the audio subsystem worked well. The information on how to achieve this is widely available but there aren't too many sources which are clear, accurate, comprehensive, current and necessarily specific to one's particular environment so you end up spending a lot of time chasing ghosts and smashing your head over frustrating issues. On the other hand, it also forces you to learn a bit about how things work so it's a double edged sword. Frustrating initially and awesome once you've cracked the worst problems.

The one exception (for me) to using Windows apps under Linux is when there are no alternatives available. For example, if you have a nice Windoze softsynth or FX VST which isn't ported to Linux. In such a case the only way to use it in Linux would be to run it under Wine. In some cases it can be made to work surprisingly well but it's just not ideal in terms of performance and system stability. Probably OK when editing tracks but not a good idea for live playing.

[ssj71]

What would the probability of the software that comes with "XXXX" audio interface works under installation under Vine. Is this viable or am I still looking for Bigfoot riding the Loch Ness Monster in french maid outfit????

In my experience the people who are most frustrated by linux audio are usually those trying to use unsupported software or hardware. So I'd google software XXXX linux and if nobody's using it, unless you're willing and able to troubleshoot and figure out a solution on your own, you'll do best to steer clear. You might have to make some sacrifices (as in you can't use shiny software XXXX) and you will almost surely need to learn some tricks, but we're here to help you and there is almost always some alternative that IS supported (not a clone, but similar features). I mean, if the Beatles didn't have Windows or Mac, you can do pretty well without using them either.

[ChaoticGuitars]

OK, also, would it be better if I was running KXStudio?? I installed Ubuntu Studio with only the intention of using it for recording music, and it APPEARS KXStudio is designed for just that. Sorry for the newbie questions, I am exactly that. I am trying to learn through guidance offered here. I’m used to working with wood and metal, not lines of code.

[ssj71]

OK, also, would it be better if I was running KXStudio?? I installed Ubuntu Studio with only the intention of using it for recording music, and it APPEARS KXStudio is designed for just that. Sorry for the newbie questions, I am exactly that. I am trying to learn through guidance offered here. I’m used to working with wood and metal, not lines of code.

Ubuntu Studio tends to get a bad wrap here. I think its not perfect for a some of machines because of the restictions Canonical puts on its official Ubuntu forks (like Studio), so they don't have the full configuration KX does. I've used Ubuntu Studio quite a bit and never had problems. However I ALWAYS install all the KXStudio packages n it, as they are kept more up to date and have more available. Read http://kxstudio.sourceforge.net/Repositories to learn how. Once you do that you practically have KXstudio. I just don't much care for KDE that KX ships with. Not to my taste is all.

[asbak]

OK, also, would it be better if I was running KXStudio?? I installed Ubuntu Studio with only the intention of using it for recording music, and it APPEARS KXStudio is designed for just that. Sorry for the newbie questions, I am exactly that. I am trying to learn through guidance offered here. I’m used to working with wood and metal, not lines of code.

KXStudio is probably a good way to get started and get to grips with the basics.

A lot of people like to install their own. Some guys like to run Debian, some guys like to run Arch and they install KX's repositories on their OS and add whatever else it is they want to use. Different windows managers are used ie KDE, Gnome, Cinnamon, XFCE etc etc. On a slow and struggling system you'd be better off using a lightweight windows manager like XFCE. On a reasonably OK spec machine it probably doesn't matter too much what window manager you use.

If you install your own there's a long list of settings you need to adjust in order to optimise the system for audio usage and that's where it gets tricky. Possibly the most important mod of all is to install a PREEMPT 1000 mHz kernel. In Debian that means you'd have to compile it yourself or use something like liquorix because the default Debian kernel is hopeless for audio. Anyway, for now KXStudio's iso may be the best bet and if you eventually feel like you need to move on then revisit the "roll your own" topic later.

And the advice about using supported hardware is very relevant. Not all devices work equally well. Some sort of work (UMC-404 for example) but it just doesn't work consistently well or without problems, at least not for me. A UA-25 is excellent and troublefree. There are later and better devices out there, read through the compatibility matrix of what's well supported and work from that. On-board audio probably won't work too great with jackd but if you combine a decent audiocard with the onboard audio, for example running jack on the good audio card and pulseaudio on the onboard audio you have a flexible setup which allows you to do normal stuff (youtube videos, watch movies etc) and have proper low latency audio at the same time via jack on the good soundcard. Then of course you may need a hardware mixer to combine the signals from the good audio card, the onboard audio and so on so you can monitor it on your monitors or hifi speakers or whatever. The possibilities are endless.

Once you become familiar with the basics and you start digging it will become apparent that there is truly a huge amount of very usable and excellent software ranging from sequencers to great softsynths & softsamplers to modular synths to effects plugins to recording suites like Ardour and so on. It's feasible to do an A - Z production in Linux. It just takes a bit of time to learn the ropes and resolve some of the issues which may crop up depending on your choice of hardware, software and so on.

[ChaoticGuitars]

I would like to thank everyone for taking the time and explaining all this to me. I think with everything explained, I still have more learning to do.... But isn’t that true for everyone.

[ssj71]

Possibly the most important mod of all is to install a PREEMPT 1000 mHz kernel

I don't know if I agree 100%. Does KXstudio ship default with a preempt kernel? I know a lot of people have fine results with stock kernels.

[asbak]

Possibly the most important mod of all is to install a PREEMPT 1000 mHz kernel

I don't know if I agree 100%. Does KXstudio ship default with a preempt kernel? I know a lot of people have fine results with stock kernels.

I don't know what kernel KXStudio (here I am referring to the distro on installable iso) ships with and don't use it but assumed that falkTX would have optimised it seeing as he interacts with users on a daily basis, would have received an enormous amount of feedback and that part of that feedback would have concerned the performance of software in KX. Based on my limited knowledge so far it just doesn't seem plausible that it would work very well for low-latency operations if it didn't have (amongst other things) a PREEMPT (or RT) type kernel. Whether or not "most users" care about low-latency operations I have no idea. To me it matters though.

- What jackd settings do users who succeed with stock kernels make use of?
- What particular audio hardware are the users succeeding with stock kernels on let's say Debian using? Is the general consensus that it "works well out of the box with most audio hardware"?
- What are the exact characteristics of those stock kernels, ie compare the /boot/config files of stock on system A with system D. Are they necessarily the same for Ubuntu vs Debian or Mint or Arch?
- What kind of audio usage are the users who succeed with stock kernels on Debian putting their systems through? Does it mean playing back mp3's in vlc or similar, does it mean recording tracks in audacity and ardour with high latency settings in jackd, does it mean playing back softsynths via midi keyboard with low-latency jackd settings so one hears the sound being returned with minimal delay and no xruns, clicking & popping?

I'd have to throw out the book on what's been my experiences thus far and start over if "stock linux kernels worked great for audio".
It's not impossible that I've been doing it all wrong and that things just coincidentally started working better after, amongst other things, replacing kernels and that I'm being fooled by a placebo effect but it would come as a huge surprise.

[asbak]

[UPDATE: This issued bothered me so much that I just had to confirm that I wasn't losing my mind.]


My Results, exact same configurations used apart from kernels

#1
OS: Debian Jessie 64
Debian 3.16 kernel
jackd -S -R -P89 -dalsa -dhw:2 -r48000 -p64 -n2 -Xraw
Muse hosting Linuxsampler + "Little Lizard" piano samples & OBX.

Before having even pressed a note the counter hits 7 Xruns. After a few mins screwing around by the time session is shut down Xrun counter hits 17.


#2
OS: Debian Jessie 64
Self-compiled 3.18 PREEMPT Kernel
jackd -S -R -P89 -dalsa -dhw:2 -r48000 -p64 -n2 -Xraw
Muse hosting Linuxsampler + "Little Lizard" piano samples & Obx.

By the time Muse finished loading a saved project containing Linuxsampler + Piano samples & OBX counter hits 1 Xrun, presumably this was caused by loading the samples but I cannot be 100% sure. No notes pressed so far.
Screw around on keyboard playing piano, switch to OBX for around 5 mins or so. Zero Xruns during this period.


Final Results for short test


Stock Debian 3.16 kernel - 17 Xruns
Linux 3.18 PREEMPT kernel - 1 Xrun (which occurred during application loading phase and not during actual playing and usage)

[ssj71]

Thats a pretty good test, though you aren't exactly comparing the same kernel one with patch, one without.

EDIT: You just mean a preempt enabled kernel right, not a RT kernel? I kinda assumed that you meant RT. If you meant just enabling the preempt option, disregard the below discussion on RT kernels. I was a bit confused on the difference before. See this.

My understanding is that many of the optimizations the RT kernel patches offer are now merged into the mainline, so a RT kernel isn't AS critical as it was a few years ago.

More to my point, I just don't think we should tell every person coming to linux audio "the first thing you should do is go compile your own kernel" (which maybe you weren't suggesting that; I don't know where you got your kernel). It really proliferates the stereotype that linux is only for pale-faced coders alone in the dark of their lonely apartments, lit only by the monitor. If you'd suggest an easy way to get an RT kernel I wouldn't have commented (and I'm curious to see what you say).

So in a nutshell I would not say as much:

"stock linux kernels worked great for audio".

as I would say "stock kernels in audio distros are good enough for most audio work." The latencies will probably be higher than with RT, but I use the low-latency kernel kxstudio offers without too much trouble. The lowlatency is not patched but enables the options that have been merged in from the RT patches mentioned above). I would prescribe RT kernels strictly on an as needed basis. Don't fix what ain't broke.

Often you can configure a system better to reduce xruns rather than get a new kernel. For example on my laptop the firewire interrupt is shared with the wifi. So any time I record I turn of networking. That makes a much bigger reduction in xruns than RT kernels (though I jumped straight to and RT kernel but it didn't help and later reverted). RT kernels will not support any additional audio hardware than stock kernels. In fact preempt/lowlatency will not support any more than vanilla kernels. Again, latency might need to be set higher, but for me 2-10ms is plenty low with the lowlatency kernel. Some people need low latency (like the softsynth example you give) but very often people get in some strange preoccupation with trying to lower latency for tasks that have no real need for it.

I just want to be precise and clear on what the benefits/costs of RT kernels actually are. Perhaps I'm just misunderstanding your original intent, in which case I apologize.