In this installment of my "The Open Source Musician" series I'll talk about the trails and tribulations of getting my Linux-based home studio computer up and running and starting my first recording projects. Look here for the first part of the series.
The Software
As mentioned in the previous article, home recording in the UNIX/Linux world is a bit different than doing the same thing in the Windows or Mac world, at least in my (admittedly fairly limited) experience. Using Cakewalk or similar under Windows one tends to perform most tasks inside Cakewalk itself. Or at least I always did. Linux, on the other hand, follows more in the UNIX tradition of having tools that perform a single task very well and is intended to be linked with other tools to get a bigger task completed. As a refresher, the tools I'm using with Linux are as follows:
JACK
The place I always start is with JACK. JACK, which is another of those ubiquitous recursive acronyms so popular with Open Source developers, stands for JACK Audio Connection Kit. The name may not be much of a clue to the neophyte but JACK is in many ways the hub of the Open Source studio. JACK is very literally the glue that ties all the disparate parts together. JACK is, very basically, a sound server that sits between the sound card driver (like ALSA) and the software that comprises the studio. That sounds simple enough that one might wonder why it's needed. After all, does it have an equivalent on Windows or Mac? I don't think so (I could easily be wrong) but then again it's not really needed if you're using one software package to record, sequence, mix, master, etc. Since all these sub-tasks are performed by separate pieces of software in an Open Source studio they all have to have some way to communicate with each other. That is the function that JACK performs. All of the software packages listed above (and many more besides) are JACK clients. That means they all use (or can use) JACK as a transport mechanism for routing audio or MIDI from one software package to another, all internally to the computer. What's more, JACK doesn't know or care where the audio or MIDI data it's routing comes from. It treats a guitar plugged into your sound card's recording interface or MIDI coming from your keyboard or electronic drum kit via a USB or serial interface exactly the same as it treats data coming from another source internal to the computer. If all of this leaves you scratching your head then don't worry too much, it's one of those things that becomes clear when a concrete example is given.
JACK is also the primary place where one concerns oneself with system latency. JACK is intended to be a very low-latency sound server but making it work as such means getting it configured right and, in some cases, having the right hardware. As is usually the case in situations like these, having the wrong hardware can make this task nigh upon impossible. The bad news here is that as far as I'm able to discern setting up JACK is mostly an exercise in trial-and-error. It definitely was for me and all the guides I've read about setting it up end up suggesting the very same thing. Once the operating system is configured with a low-latency kernel (this was handled by installing Ubuntu Studio in my case) one simply fires up a command prompt or a program like QJackCtl, plugs in some reasonable defaults, and tries to start it up. If the server starts successfully you can either move on to the next stage if JACK's latency and performance are adequate with the settings used or, more likely the case, stop the server again, tweak some settings in a quest for lower latency, restart the server, observe, and repeat until satisfied. Or perhaps I should say "repeat until it's as good as it'll get with your hardware" rather than "repeat until satisfied."
I suppose this is the place that I should note the fact that almost every setback, problem, headache, and complication I've encountered in my quest for an Open Source home studio to date have been related, in one way or another, to JACK. In fact, I believe I've only had two that were completely unrelated to JACK and I'll talk about those later. For now I need to qualify that statement because it sounds like JACK is a problematic piece of software, and it emphatically is not. Or at least it hasn't been for me. The problems, setbacks, headaches, and complications that have been JACK-related have been either the nature of the beast, misconceptions on my part, things I didn't know or understand, and configuration modifications that were simple once I understood I had to do them.
The first problem I encountered with JACK was just configuration. As mentioned previously it's a mostly trial-and-error affair. That seems kind of archaic and crappy but I honestly don't think it can be helped. After all, the latency that can be achieved by a given system is entirely dependent UPON that system. How are the JACK developers supposed to know the capabilities or eccentricities of your sound card? Or worse, upon your sound card when it's combined with your driver version, motherboard, kernel revision, etc. I suppose they could compile databases of cards and their performance metrics or write code that performs various and sundry tests trying to discover a good base setting but honestly I'd rather see them keep writing great code and let me worry about making it work on my system.
The second problem, or perhaps misconception, involved multiple sound cards. My system has a AC97-based sound card on the mother board and as I mentioned in the last article I installed a old Sound Blaster Audigy Platinum when I set the machine up. I originally had both cards enabled and Ubuntu Studio had no problem with that at all, in and of itself. To make things even more complicated, I sometimes had a third sound card (at least as far as Ubuntu Studio and ALSA were concerned) because I was using my Digitech GNX4 as an audio interface via it's built-in USB connectivity. When the GNX4 is connected to the computer Ubuntu treats it just like another sound card. JACK really didn't have a problem with the multiple sound cards, it just didn't like being told to use an interface on one card for recording and an interface on another for playback. What I was trying to do originally was to use my GNX4 as a recording interface but use the Audigy as the playback interface so I could monitor what I was playing or listening back to through my speakers (the GNX4 is a floor-unit guitar effects processor, among other things, and needs to be plugged into a power amp or used with headphones to be heard). JACK didn't care for that configuration at all. Some reading lead me to the information that JACK can only be used with one audio interface at a time due to issues with synchronizing the master clocks (and therefore the audio) on multiple sound cards. That kind of made sense once it was pointed out to me, but it was still a bummer given my available configuration options, and even moreso because at the time I'd been unable to get the external breakout box for the Audigy to work (a problem I later solved, thereby greatly simplifying my setup. The problem with the Audigy ended up being a power connection I missed during install.). Since I had to use the same hardware interface for both recording and playback at any given time I was relegated to using my GNX4 and a set of headphones anytime I was recording tracks. Thankfully Ubuntu Studio's handling of the GNX4's USB interface was seamless enough that I was able to do so. JACK's performance did suffer in this configuration though, resulting in some Xruns from time to time. Xruns are JACK's way of telling you it's having trouble keeping up and is loosing pieces of data. They are A Bad Thing, and something that's to be avoided whenever possible. I'm quite certain the Xruns were being caused by the system trying to pass audio data from the GNX4 to the computer (recording) and from the computer to the GNX4(playback), all through a USB 1.1 connection (because that's all the GNX4 supports). Anyway, this configuration worked ok for a while, until it led me directly to problem number three.
Problem number three had to do with sample rates. During all of my previous work I was switching more-or-less randomly between 44.1K and 48K sampling rates in an effort to optimize my JACK performance. When I started recording with the GNX4 as the interface I happened to have the system set to 44.1. Since it worked I didn't bother to check the 48k setting. I got the first-run drum track, a guitar track, and a bass track all laid down for the original song I was trying to record while setting up and testing my new studio workstation. Once I got the rhythm tracks recorded I wanted to switch back to just listening through my speakers (verses the headphones which were the only way I had to monitor sound through the GNX4) so I could experiment with some effects as well as routing, mixing, and mastering. When I reconfigured JACK to use my sound card as the interface the problem showed itself. JACK wouldn't operate with my sound card at 44.1K and wouldn't operate with the GNX4 at 48K. The GNX4 only supports 44.1K sample rates so I thought I was dead in the water. After some more reading about the emu10k1 chipset that is at the heart of the Audigy I discovered that there were two different ways it can be used to record. One way is with what I guess would be best termed the "primary" or "consumer" recording interface and one way that is directly through the chip's onboard 16-channel mixer. The emu10k1 chipset operates natively at 48K and if recording is being done directly through the mixer that's the only rate it will operate at. If, however, one uses the "primary" recording interface the card will do hardware-based on-the-fly resampling to 44.1k. I had JACK set up to record directly from onboard mixer so it would fail if I tried to operate at 44.1k. Reconfiguring JACK to use the other interface allowed me to switch to a 44.1k rate and continue without Ardour complaining about different sample rates and, if those complaints were ignored, playing the song back too fast and slightly pitch-shifted. This might seem as though the problem were solved, and it was to a point, but I noticed after working this way for a little while that JACK's performance was definitely degraded by having the card operating at a non-native sample rate. This performance degradation surfaced in the form of a markedly increased number of Xruns while working with the audio in Ardour. I ultimately ended up solving this problem by finding the missing power connection and getting the breakout box for the Audigy working. Once I had that fixed I decided to not waste any more time with it and simply re-recorded my drum, guitar, and bass tracks through the Audigy at it's native 48k sample rate.
In the next installment of series I'll talk more about Ardour, Rosegarden, and JAMin, with maybe a bit about Hydrogen thrown in as well. Stay tuned.
The Software
As mentioned in the previous article, home recording in the UNIX/Linux world is a bit different than doing the same thing in the Windows or Mac world, at least in my (admittedly fairly limited) experience. Using Cakewalk or similar under Windows one tends to perform most tasks inside Cakewalk itself. Or at least I always did. Linux, on the other hand, follows more in the UNIX tradition of having tools that perform a single task very well and is intended to be linked with other tools to get a bigger task completed. As a refresher, the tools I'm using with Linux are as follows:
- JACK, for tying it all together.
- Hydrogen, for creating drum and percussion tracks
- Ardour, as my primary Digital Audio Workstation (DAW) software
- Rosegarden, for non-percussion sequencing
- JAMin, for mastering
JACK
The place I always start is with JACK. JACK, which is another of those ubiquitous recursive acronyms so popular with Open Source developers, stands for JACK Audio Connection Kit. The name may not be much of a clue to the neophyte but JACK is in many ways the hub of the Open Source studio. JACK is very literally the glue that ties all the disparate parts together. JACK is, very basically, a sound server that sits between the sound card driver (like ALSA) and the software that comprises the studio. That sounds simple enough that one might wonder why it's needed. After all, does it have an equivalent on Windows or Mac? I don't think so (I could easily be wrong) but then again it's not really needed if you're using one software package to record, sequence, mix, master, etc. Since all these sub-tasks are performed by separate pieces of software in an Open Source studio they all have to have some way to communicate with each other. That is the function that JACK performs. All of the software packages listed above (and many more besides) are JACK clients. That means they all use (or can use) JACK as a transport mechanism for routing audio or MIDI from one software package to another, all internally to the computer. What's more, JACK doesn't know or care where the audio or MIDI data it's routing comes from. It treats a guitar plugged into your sound card's recording interface or MIDI coming from your keyboard or electronic drum kit via a USB or serial interface exactly the same as it treats data coming from another source internal to the computer. If all of this leaves you scratching your head then don't worry too much, it's one of those things that becomes clear when a concrete example is given.
JACK is also the primary place where one concerns oneself with system latency. JACK is intended to be a very low-latency sound server but making it work as such means getting it configured right and, in some cases, having the right hardware. As is usually the case in situations like these, having the wrong hardware can make this task nigh upon impossible. The bad news here is that as far as I'm able to discern setting up JACK is mostly an exercise in trial-and-error. It definitely was for me and all the guides I've read about setting it up end up suggesting the very same thing. Once the operating system is configured with a low-latency kernel (this was handled by installing Ubuntu Studio in my case) one simply fires up a command prompt or a program like QJackCtl, plugs in some reasonable defaults, and tries to start it up. If the server starts successfully you can either move on to the next stage if JACK's latency and performance are adequate with the settings used or, more likely the case, stop the server again, tweak some settings in a quest for lower latency, restart the server, observe, and repeat until satisfied. Or perhaps I should say "repeat until it's as good as it'll get with your hardware" rather than "repeat until satisfied."
I suppose this is the place that I should note the fact that almost every setback, problem, headache, and complication I've encountered in my quest for an Open Source home studio to date have been related, in one way or another, to JACK. In fact, I believe I've only had two that were completely unrelated to JACK and I'll talk about those later. For now I need to qualify that statement because it sounds like JACK is a problematic piece of software, and it emphatically is not. Or at least it hasn't been for me. The problems, setbacks, headaches, and complications that have been JACK-related have been either the nature of the beast, misconceptions on my part, things I didn't know or understand, and configuration modifications that were simple once I understood I had to do them.
The first problem I encountered with JACK was just configuration. As mentioned previously it's a mostly trial-and-error affair. That seems kind of archaic and crappy but I honestly don't think it can be helped. After all, the latency that can be achieved by a given system is entirely dependent UPON that system. How are the JACK developers supposed to know the capabilities or eccentricities of your sound card? Or worse, upon your sound card when it's combined with your driver version, motherboard, kernel revision, etc. I suppose they could compile databases of cards and their performance metrics or write code that performs various and sundry tests trying to discover a good base setting but honestly I'd rather see them keep writing great code and let me worry about making it work on my system.
The second problem, or perhaps misconception, involved multiple sound cards. My system has a AC97-based sound card on the mother board and as I mentioned in the last article I installed a old Sound Blaster Audigy Platinum when I set the machine up. I originally had both cards enabled and Ubuntu Studio had no problem with that at all, in and of itself. To make things even more complicated, I sometimes had a third sound card (at least as far as Ubuntu Studio and ALSA were concerned) because I was using my Digitech GNX4 as an audio interface via it's built-in USB connectivity. When the GNX4 is connected to the computer Ubuntu treats it just like another sound card. JACK really didn't have a problem with the multiple sound cards, it just didn't like being told to use an interface on one card for recording and an interface on another for playback. What I was trying to do originally was to use my GNX4 as a recording interface but use the Audigy as the playback interface so I could monitor what I was playing or listening back to through my speakers (the GNX4 is a floor-unit guitar effects processor, among other things, and needs to be plugged into a power amp or used with headphones to be heard). JACK didn't care for that configuration at all. Some reading lead me to the information that JACK can only be used with one audio interface at a time due to issues with synchronizing the master clocks (and therefore the audio) on multiple sound cards. That kind of made sense once it was pointed out to me, but it was still a bummer given my available configuration options, and even moreso because at the time I'd been unable to get the external breakout box for the Audigy to work (a problem I later solved, thereby greatly simplifying my setup. The problem with the Audigy ended up being a power connection I missed during install.). Since I had to use the same hardware interface for both recording and playback at any given time I was relegated to using my GNX4 and a set of headphones anytime I was recording tracks. Thankfully Ubuntu Studio's handling of the GNX4's USB interface was seamless enough that I was able to do so. JACK's performance did suffer in this configuration though, resulting in some Xruns from time to time. Xruns are JACK's way of telling you it's having trouble keeping up and is loosing pieces of data. They are A Bad Thing, and something that's to be avoided whenever possible. I'm quite certain the Xruns were being caused by the system trying to pass audio data from the GNX4 to the computer (recording) and from the computer to the GNX4(playback), all through a USB 1.1 connection (because that's all the GNX4 supports). Anyway, this configuration worked ok for a while, until it led me directly to problem number three.
Problem number three had to do with sample rates. During all of my previous work I was switching more-or-less randomly between 44.1K and 48K sampling rates in an effort to optimize my JACK performance. When I started recording with the GNX4 as the interface I happened to have the system set to 44.1. Since it worked I didn't bother to check the 48k setting. I got the first-run drum track, a guitar track, and a bass track all laid down for the original song I was trying to record while setting up and testing my new studio workstation. Once I got the rhythm tracks recorded I wanted to switch back to just listening through my speakers (verses the headphones which were the only way I had to monitor sound through the GNX4) so I could experiment with some effects as well as routing, mixing, and mastering. When I reconfigured JACK to use my sound card as the interface the problem showed itself. JACK wouldn't operate with my sound card at 44.1K and wouldn't operate with the GNX4 at 48K. The GNX4 only supports 44.1K sample rates so I thought I was dead in the water. After some more reading about the emu10k1 chipset that is at the heart of the Audigy I discovered that there were two different ways it can be used to record. One way is with what I guess would be best termed the "primary" or "consumer" recording interface and one way that is directly through the chip's onboard 16-channel mixer. The emu10k1 chipset operates natively at 48K and if recording is being done directly through the mixer that's the only rate it will operate at. If, however, one uses the "primary" recording interface the card will do hardware-based on-the-fly resampling to 44.1k. I had JACK set up to record directly from onboard mixer so it would fail if I tried to operate at 44.1k. Reconfiguring JACK to use the other interface allowed me to switch to a 44.1k rate and continue without Ardour complaining about different sample rates and, if those complaints were ignored, playing the song back too fast and slightly pitch-shifted. This might seem as though the problem were solved, and it was to a point, but I noticed after working this way for a little while that JACK's performance was definitely degraded by having the card operating at a non-native sample rate. This performance degradation surfaced in the form of a markedly increased number of Xruns while working with the audio in Ardour. I ultimately ended up solving this problem by finding the missing power connection and getting the breakout box for the Audigy working. Once I had that fixed I decided to not waste any more time with it and simply re-recorded my drum, guitar, and bass tracks through the Audigy at it's native 48k sample rate.
In the next installment of series I'll talk more about Ardour, Rosegarden, and JAMin, with maybe a bit about Hydrogen thrown in as well. Stay tuned.
0 comments:
Post a Comment