Troubleshooting Linux Audio, Part 3b
In this final section I'll present some MIDI-specific troubleshooting tips, along with a brief description of the setup here at StudioDave, a few closing remarks, and of course some links to the Linux music-maker du jour.
MIDI problems are generally easier to diagnose than audio difficulties. As you might already know, MIDI does not carry audio data, and the tools for troubleshooting MIDI problems are quite simple to use and understand. Your MIDI troubleshooting toolkit should include at least a MIDI monitor program and the ALSA amidi utility. The amidi tool can be used to send an arbitrary MIDI command string to any MIDI device in your system, and the MIDI monitor can watch the data stream to see if your command was correctly sent and delivered. Figure 1 shows off the gmidimonitor at work receiving a program change message sent from amidi.
The problem-solving flowchart remains essentially the same for MIDI as with audio. Check your hardware connections and power-on status, make sure your MIDI devices are actually supported by ALSA and that the correct drivers are installed, and check the virtual connections between your sending and receiving devices.
One special MIDI problem exists for Linux. The default kernel configuration includes a setting (under Processor Type & Features) for the timer frequency resolution, which affects the timing resolution of a MIDI data stream. If this value is set too low your MIDI streams may feel sluggish and unaligned. The resolution should be set to 1000. If it is not you will need to either install a distribution with an optimized kernel or you will have to configure and install your own kernel.
Some MIDI programs require that the kernel include an active realtime clock (RTC). Media-optimized kernels will activate the RTC as a matter of course, but if you're in doubt (or if your application has responded with an error regarding the RTC) you can check its status with the cat /proc combo :
Use this command to check set the clock to its optimal value :
echo 1024 > /proc/sys/dev/rtc/max-user-freq
To permanently add this setting to your boot options, become the root user and run the following command :
echo "dev.rtc.max-user-freq=1024" >> /etc/sysctl.conf
By the way, you should always copy the original file to a back-up location before working on it.
Some Further Tips And Recommendations
Sage advice to the interested reader: Scale your expectations. Some problems are directly due to economic necessity, i.e., what you can and can't afford. For Linux audio people that means hardware (our native software is famously inexpensive), and in this domain hardware means microphones, instruments, amplifiers, speakers, cables, mixing consoles, computers, and of course, soundcards and audio boards.
If you need professional-quality results from your Linux audio work, then your choices are few and clear. The M-Audio Delta systems are popular for serious desktop and project studio production, while the RME Hammerfall is the preferred interface for fully professional recording houses.
If your needs are more modest you might be happy with the Creative Labs SBLive and Audigy cards. Both are available with a break-out box for easy access to their audio and MIDI ports, and both provide a handy S/PDIF digital audio interface.
Standards-compliant USB audio devices should work with the kernel and ALSA USB modules. Some Firewire devices are already supported by the FFADO project; see the project archives and the archives of the Linux Audio Users/Developers mail lists for information regarding specific device support.
On-board audio chipsets are designed for consumer-grade sound support. Their quality varies with the overall quality of the motherboard, but in general you should avoid using on-board sound hardware for serious desktop audio production. This is especially true for laptops, most of which can accept high-quality USB or PCMCIA external hardware alternatives.
I have a small home studio, suitable for good quality project recordings and MIDI composition. It includes three computers, all locally networked. Two AMD64-based machines are used for project audio and MIDI work. The third machine, a PII 366 MHz laptop, is MIDI-capable, but its audio abilities are relatively weak. If needed, a CoreSound PCMCIA card provides a high-quality digital audio input channel for the laptop. All machines are accessible via MIDI. routed through a Yamaha MJC8, an 8-in/8-thru MIDI junction controller. Audio output from the computers and external hardware is routed through a Yamaha DMP11 MIDI-controllable mixer. High-quality audio production is available to both desktop machines (both include an M-Audio Delta 66 digital audio interface).
Problems I've encountered and resolved include crackling JACK, USB interference, mixer channel noises, and of course hardware issues such as bad connectors and poor connections. Fortunately I've also found valuable advice and assistance from the members of various lists, forums, and wikis, and I've been able to resolve happily all the troubleshooting issues I've encountered to date. May your own experience be as fortunate.
Linux Music Makers
Some years ago I found a page named Miki's Music that contained pieces composed with the excellent Rosegarden audio/MIDI sequencer. In the passage of time, Miki has become Wingse, the music collection has grown, but Rosegarden is still the composer's preferred music composition software. Check out the entire collection, but for a sweet taste listen to June Rainy Hill, and if you're up for some undisguised humor in music check out the lively Celtic Dance.
I'll return in a few weeks with news and updates from around the Linux audio world. So much good stuff is happening here, it's hard to decide where to focus. New packages appear, old stalwarts get stronger, and I have some interesting new projects in the works. Let me know what you'd like to see reviewed and profiled here, just add a note to the Comments section and I'll get right on it.
Similis sum folio de quo ludunt venti.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development