Using the Hammerfall HDSP on Linux
Now that the modules are loaded, and hdsploader has been run we can try to play a sound using aplay. Like any other ALSA driver, the HDSP driver mutes all channels at startup, so first you need to set the gain control, or volume, properly for your playback channels. One way to do this is to simply run alsamixer -c 1. When the bars are at 50% the channel is output with approximately 0dB gain. A more precise way is using amixer directly. The gain is as follows:
0 = -inf dB 32768 = 0 dB 65535 = +6 dB
A simple way to set all channels to 0dB gain is to use the following script:
#!/bin/bash for i in $(seq 1 18);do amixer -c 1 cset name=Chn,index=$i 32768 done
Now that you've done that, hook up your speakers to the first two analog outputs, and try the following:
aplay -D hdsp_analog some_stereo_file.wav
If all goes well you should see something like this:
Playing WAVE 'some_stereo_file.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
By default, playback channels are connected to their respective hardware outputs; if this isn't true in your setup, you won't hear anything. If this is the case, read the following section on configuring the matrix mixer.
You also can change the -D option to send audio to different channels. For instance, using hdsp_adat would send the audio to the first two adat channels; hdsp_spdif would go to the spdif outputs. All of this is controlled by asoundrc.
If playing a sound worked, try recording a sound with arecord. This time, hook up a sound source to your first two analog channels, and run the following:
arecord -D hdsp_analog -f dat recording.wav
Press Crtl-C to halt recording. If everything worked, recording.wav should be a stereo file at 48kHz. In this case, the matrix mixer has no effect on what's recorded; the first channel recorded always corresponds to the first hardware input and so on.
As mentioned above, all software using the HDSP must be closed before switching between SingleSpeed and DoubleSpeed mode. But normally, software sets the sample rate. So what now? Well, there is a setting related to the AutoSync functionality (more on that later) that can do the job, Sample Clock Source. I won't explain exactly how it works just yet, but basically, by setting the internal clock to different frequencies, the card automatically switches modes. For instance, to switch to DoubleSpeed mode run:
amixer -c 1 cset numid=11 6
To switch back to SingleSpeed mode run:
amixer -c 1 cset numid=11 3
In both cases, don't forget to make sure that no application currently is using the sound card.
Sound routing is the most powerful feature the HDSP has to offer. Unfortunately, because it is not a feature found on many sound cards, the interface used to control it is not an ALSA standard. As of ALSA version 0.9.3, the matrix mixer interface is somewhat of a hack and is subject to change. It's possible to write values to it but not to read them back. In any case, the syntax used is source,destination,gain, where gain is as explained above, and source and destination are as follows:
For the Multiface:
input: 0-7 (analog), 16-23 (adat), 24-25 (spdif), 26-43 (playback) output: 0-7 (analog), 16-23 (adat) 24-25 (spdif), 26-27 (line out)
For the Digiface:
input_source : 0-25 (physical channels), 26-51 (playback) output_source : 0-25 (physical channels), 26-27 (line out)
The routing for the Multiface is also shown in Figure 1. By default, the playback channels are routed to the hardware output channels in order. All other possible connections are muted (0 or -inf dB gain).
To change an entry, use the following command:
amixer -c 1 cset numid=5 src,dest,gain
For instance, you could direct the SPDIF input to analog out with the following:
amixer -c 1 cset numid=5 24,0,32768 amixer -c 1 cset numid=5 25,1,32768
When you're finished, run the commands again, but with 0 as the gain instead of 32768. Don't forget that you can have multiple channels going to a single output or multiple outputs from a single input. Any combination is possible—use your imagination.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide