Using JACK for GStreamer

Gstreamer includes a jackaudiosink in the gstreamer-plugins-bad package. To get started install this package. You would also need some more stuff to get the whole thing working so just follow the below apt-get command,
shell$ sudo apt-get install gstreamer0.10-plugins-bad jackd jack-rack jack-tools patchage
Now to route the gstreamer audio data via JACK you need to do some tweaking to the gstreamer properties in gconf-editor.
shell$ gconf-editor

Now navigate to /system/gstreamer/0.10/default. In the ‘audiosink’, musicaudiosink’ enter the following:

jackaudiosink connect=none

If you leave off the 'connect=none', the sink will automatically connect to the outputs of your soundcard in Jack. You may want this for default audio and chat (just remove 'connect=none'), but not for music if you want EQ, dynamics, etc. processing on it. You may want to change the description of the sinks as well...otherwise it just shows up as 'ALSA custom' in gnome-sound-properties.

Next, we make a rule for jack.plumbing. In the version of jackaudiosink that ships with Feisty, the outputs are by default named 'GStreamer:out_x'; In Gutsy, they are named by the program, so for Banshee, they would be 'Banshee:out_x'.

Save this in your home directory as '~/.jack.plumbing':

(connect "GStreamer:out_1" "jack_rack:in_1")
(connect "GStreamer:out_2" "jack_rack:in_2")
(connect "jack_rack:out_1" "alsa_pcm:playback_1")
(connect "jack_rack:out_2" "alsa_pcm:playback_2")

Now you need a script to automate it. Put this in a script (again, you may need to modify the jackd command to suit your set up, depending on what your primary soundcard is labeled as in ALSA, and if you have -RT kernel, running jack with '-R' will give you better performance), save it in your home folder, 'chmod +x' it:

jackd -dalsa -dhw:0 &
sleep 2
jack.plumbing &
sleep 1
jack-rack -n &

Now you're set. Try running that script, and if everything works, jack-rack should pop up. If it doesn't, jackd didn't start correctly. If you save a jack-rack file, you can tell jack-rack to load it in the script above by just adding the path to the file after the '-n'. If jack-rack popping up on every boot annoys you, get alltray (sudo apt-get install alltray) and run jack-rack like so: "alltray jack-rack -n &", and it will dock in your system tray.
Alternatively you could omit the jackd server start in the script and start it with the qjackctl and then run the above script for JACK plumbing.
Now run your favorite gstreamer audio application (exaile, banshee, rythymbox, etc.) and see if you have any sound when you hit play. If not, open patchage and manually connect the output pins from your sound application to the input pins of jack-rack (just drag and drop). Jack rack's output should already be connected to the outputs of your soundcard.

OR just to test with Gstreamer alone follow these steps:

Run the above script that pops up the JACK rack.

Now start your favourite gstreamer pipeline (example gst-launch0.10 audiotestsrc ! audiocovert ! jackaudiosink) and check if the audio data (sine in the example case) is routed via JACK.

Installing Ubuntu using USB Flash Drive

Create a Bootable Ubuntu USB Flash Drive

You would first need to download the UNetbootin software. This is not a installer, rather just double click on it to run it.Select your options as shown in the image below and press OK button.

The process will extract the files from the ISO image, copy them to the flash drive and then install the bootloader. Depending on what you are installing, this really doesn’t take very long. Once the process is completed, you’ll be prompted to reboot… which you don’t necessarily have to do unless you want to test booting the flash drive on the same machine you are using. Otherwise you can hit the Exit button.
Booting from Flash Drive
Now that you are all finished, you can try and boot from the flash drive. Every BIOS is different, but most of them will have a message like “Press F12 for the Boot Menu”, which is highly suggested. The boot menu will allow you to select the USB drive as the boot device. Instead of the regular Ubuntu boot menu that you might be used to seeing, you will see the UNetbootin menu, which has essentially the same options.

Quickly Fill Multiple Cells with a Value or Formula in Excel

This might be quite useful for people working on excel regularly.

Use the keyboard shortcut Ctrl+Enter to quickly fill multiple cells with a value or formula. For example, you may want to enter a bunch of 0's (zeros) in a range of cells. Or, you want to apply the same formula to a range of cells without changing the cell formats.

1. Select a range of cells
2. Enter the value or formula
3. Instead of pressing Enter afterwards, press Ctrl+Enter to fill the entire range of cells.

This is basically an alternative approach to entering a value in a single cell and then copying that cell and pasting the value or the formula. Using Ctrl+Enter does not copy formatting.

If you are using a relative reference in your formula (like =A1), then the formula in the other filles cells will be the same as if you entered the formula in just the one cell and then copied that cell to the other cells in the range. If you want the formula reference to not change when you use Ctrl+Enter, you will need to use an absolute reference (like =$A$1).

Priority Inversion

When tasks share resources, as they often do, strange things can and will happen. Priority inversions can be particularly difficult to anticipate. Here's an introduction to priority inversions and a pair of techniques you can use to avoid them.

Most commercial real-time operating systems (RTOSes) employ a priority-based preemptive scheduler. These systems assign each task a unique priority level. The scheduler ensures that of those tasks that are ready to run, the one with the highest priority is always the task that is actually running. To meet this goal, the scheduler may preempt a lower-priority task in mid-execution.

Because tasks share resources, events outside the scheduler's control can prevent the highest priority ready task from running when it should. If this happens, a critical deadline could be missed, causing the system to fail. Priority inversion is the term for a scenario in which the highest-priority ready task fails to run when it should.

Resource sharing

Tasks need to share resources to communicate and process data. This aspect of multi-threaded programming is not specific to real-time or embedded systems.

Any time two tasks share a resource, such as a memory buffer, in a system that employs a priority-based scheduler, one of them will usually have a higher priority. The higher-priority task expects to be run as soon as it is ready. However, if the lower-priority task is using their shared resource when the higher-priority task becomes ready to run, the higher-priority task must wait for the lower-priority task to finish with it. We say that the higher-priority task is pending on the resource. If the higher-priority task has a critical deadline that it must meet, the worst-case "lockout time" for all of its shared resources must be calculated and taken into account in the design. If the cumulative lockout times are too long, the resource-sharing scheme must be redesigned.

Since worst-case delays resulting from the sharing of resources can be calculated at design time, the only way they can affect the performance of the system is if no one properly accounts for them.

Priority inversions

The real trouble arises at run-time, when a medium-priority task preempts a lower-priority task using a shared resource on which the higher-priority task is pending. If the higher-priority task is otherwise ready to run, but a medium-priority task is currently running instead, a priority inversion is said to occur.

This dangerous sequence of events is illustrated in Figure 1. Low-priority Task L and high-priority Task H share a resource. Shortly after Task L takes the resource, Task H becomes ready to run. However, Task H must wait for Task L to finish with the resource, so it pends. Before Task L finishes with the resource, Task M becomes ready to run, preempting Task L. While Task M (and perhaps additional intermediate-priority tasks) runs, Task H, the highest-priority task in the system, remains in a pending state.

Many priority inversions are innocuous or, at most, briefly delay a task that should run right away. But from time to time a system-critical priority inversion takes place. Such an event occurred on the Mars Pathfinder mission in July 1997. The Pathfinder mission is best known for the little rover that took high-resolution color pictures of the Martian surface and relayed them back to Earth.

The problem was not in the landing software, but in the mission software run on the Martian surface. In the spacecraft, various devices communicated over a MIL-STD-1553 data bus. Activity on this bus was managed by a pair of high-priority tasks. One of the bus manager tasks communicated through a pipe with a low-priority meteorological science task.

On Earth, the software mostly ran without incident. On Mars, however, a problem developed that was serious enough to trigger a series of software resets during the mission. The sequence of events leading to each reset began when the low-priority science task was preempted by a couple of medium-priority tasks while it held a mutex related to the pipe. While the low-priority task was preempted, the high-priority bus distribution manager tried to send more data to it over the same pipe. Because the mutex was still held by the science task, the bus distribution manager was made to wait. Shortly thereafter, the other bus scheduler became active. It noticed that the distribution manager hadn't completed its work for that bus cycle and forced a system reset.

This problem was not caused by a mistake in the operating system, such as an incorrectly implemented semaphore, or in the application. Instead, the software exhibited behavior that is a known "feature" of semaphores and intertask communication. In fact, the RTOS used on Pathfinder featured an optional priority-inversion workaround; the scientists at JPL simply hadn't been aware of that option. Fortunately, they were able to recreate the problem on Earth, remotely enable the workaround, and complete the mission successfully.

Workarounds

Research on priority inversion has yielded two solutions. The first is called priority inheritance. This technique mandates that a lower-priority task inherit the priority of any higher-priority task pending on a resource they share. This priority change should take place as soon as the high-priority task begins to pend; it should end when the resource is released. This requires help from the operating system.

The second solution, priority ceilings, associates a priority with each resource; the scheduler then transfers that priority to any task that accesses the resource. The priority assigned to the resource is the priority of its highest-priority user, plus one. Once a task finishes with the resource, its priority returns to normal.

A beneficial feature of the priority ceiling solution is that tasks can share resources simply by changing their priorities, thus eliminating the need for semaphores:

void TaskA(void)

{

               ...

               SetTaskPriority(RES_X_PRIO);

               // Access shared resource X.

               SetTaskPriority(TASK_A_PRIO);

               ...

}

While Task A's priority is elevated (and it is accessing shared resource X), it should not pend on any other resource. The higher-priority user will only become the highest-priority ready task when the lower-priority task is finished with their shared resource.

While not all of us are writing software for missions to Mars, we should learn from past mistakes and implement solutions that don't repeat them. Many commercial RTOSes include support for either priority inheritance or priority ceilings. Just make sure you enable one.

Source: EETimes