What is JACK?

JACK Architecture

JACK is system for handling real-time, low latency audio (and MIDI). It runs on GNU/Linux, Solaris, FreeBSD, OS X and Windows (and can be ported to other POSIX-conformant platforms). It can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. Its clients can run in their own processes (i.e. as normal applications), or can they can run within the JACK server (i.e. as a "plugin").

JACK was designed from the ground up for professional audio work, and its design focuses on two key areas: synchronous execution of all clients, and low latency operation.

Traditionally it has been hard if not impossible to write audio applications that can share data with each other. In addition, configuring and managing audio interface hardware has often been one of the most complex aspects of writing audio software. JACK provides a system for freely connecting independent audio data I/O points, thus allowing the audio output from one JACK-savvy application to be sent to the audio input of any other JACK-aware client. The system supports multiple connections to and from any audio I/O points, and all data streams are synchronized to sample-accuracy.

As a sound server, JACK operates between the low-level sound system drivers and any JACK-aware client applications, managing the flow of multiple freely interconnected audio data streams.

Features:

• JACK is free software; you can redistribute it and/or modify it under the terms of the GNU GPL and LGPL licenses as published by the Free Software Foundation, http://www.gnu.org/. The JACK server uses the GPL, as noted in the source file headers. However, the JACK library is licensed under the LGPL, allowing proprietary programs to link with it and use JACK services.
• JACK provides a high level abstraction for programmers that removes the audio interface hardware from the picture and allows them to concentrate on the core functionality of their software.
• JACK allows applications to send and receive audio data to/from each other as well as the audio interface. There is no difference in how an application sends or receives data regardless of whether it comes from/goes to another application or an audio interface.
• On Linux all devices supported by ALSA (PCI, USB and Bluetooth) or FFADO (FireWire) will work with JACK.
• Routing audio from Flash to JACK is possible.
• Routing Gstreamer audio via JACK is possible.
• If you use applications that use the ALSA API for audio I/O and not some intermediate such as GStreamer or PulseAudio, you can still force most of them to route their audio to/from JACK.
• There is NO extra latency caused by using JACK for audio input and output. The only impact of using JACK is a slight increase in the amount of work done by the CPU to process a given chunk of audio.
• An audio app in order to use JACK must be callback-based. This means that it should not block on writes or reads from a PCM device; rather, it should be "driven" by a function that gets called at regular intervals. This is a design decision.
• Although not a requirement, Jack supports any streaming data type, not just audio.
• Applications connected using Jack may have their own graphical interfaces. Jack does not make any specifications as to different GUI toolkits or libraries. As a consequence of this, different parts of a running Jack setup may be spread across multiple processes.
• Jack provides full, sample accurate synchronation.
• To represent audio data, Jack uses 32 bit IEEE floats, normalized to value range [-1,1].
• Only noninterleaved audio streams are supported.
• Jack client may consume or produce multiple data streams.
• It should be possible to connect already running applications.
• It should be possible to add or remove Jack clients while the server is running.
• "Zero-Copy" architecture
• as an API JACK provides many benefits because of its high-level of abstraction:
• no hardware configuration
• no software (driver) configuration
• no format negotiation (all channels are mono, 32 bit floating point)
• no main loop (JACK-managed thread handles it)
• on the other hand:
• requires multi-threaded (lock-free) programming skills
• involves use of a client/server system
• "pull" model is harder for some kinds of apps

Sharing files between a Windows guest and Ubuntu host using VMware and Samba

VMware Workstation (and presumably the other enterprise-grade products in the VMware family) come with the handy “shared folders” feature which makes sharing files between a host and a virtual appliance nice and simple. The free products (VMware Player and Server) do not, unfortunately, have this ability and so we must find another way.

This quick guide shows how to use Samba to achieve the same aim. It is aimed at Ubuntu users but (the general concepts at least) should work on any modern Linux distribution. It is also written with a Windows XP guest in mind but a similar process should work in Windows Vista, Windows 2000 and other operating systems.

The goal is to set up a network share which both operating systems can transparently read and write to.

For reference, I am using Ubuntu 9.10.

Which VMware?
I’ll presume you have VMWare already installed with a Windows XP guest virtual appliance already set up. This guide is aimed at users of VMware Player and Server editions (I am using VMware Player 3.1).

VMware Player is a simple:

sudo apt-get install vmware-player

away. For the Server edition, you’ll probably want to consult the wiki.

Install Samba

If you don’t already have Samba installed, now would be a good time to do it:

sudo apt-get install samba

In order to keeps things clean and easy to manage, we’ll set up a new user account to own the share. This account name will be used when connecting to the share from within Windows. For the purposes of illustration, I will be creating a share called sandbox with the username and group also being sandbox.

Create the new group and user account with no login privileges:

sudo groupadd sandbox
sudo useradd --gid sandbox --shell /bin/false sandbox

To avoid creating a redundant home directory, you can add:

--home /nonexistent

to the end of the previous command.

Now you need to add a matching Samba account. You’ll be prompted to set a password – make note of this as this is what you will use to connect to the share from within Windows.

sudo smbpasswd -a sandbox

Next you’ll need to create a directory to be used as the share (assuming you don’t already have one). Create a directory, setting the username to your usual login and group to sandbox. Then chmod the directory 775 (assuming you wish both yourself and the virtual appliance to have read/write access). Here is what I entered:

cd $HOME
mkdir sandbox
sudo chown :sandbox sandbox
sudo chmod 775 sandbox

When you write to the share from within Ubuntu, new files will be created with the default permissions 644 with the username and group being your own user account. When your Windows client connects to the share, it will access it as if it were the local system user sandbox and so the group permissions will apply and you won’t be able to write to any files created from within Ubuntu.

To get around this problem, we can set the groupid bit for the sandbox directory which means all new files created will inherit the permissions of the parent and so the sandbox user from within Windows will be able to make read and write changes as desired.

sudo chmod g+s sandbox

If you don’t understand the above, don’t worry, just chmod the directory with the command above and all should be well.

Setting up the Samba share

Now all that’s left to do is to tell Samba about our share. Open up /etc/samba/smb.conf in your favourite text editor.

sudo gedit /etc/samba/smb.conf

Firstly, we need to set the security mechanism to user. Look for the line:

security = user

and make sure it is uncommented (remove the preceding semicolon if there is one).

Now, scroll down to the Share Definitions section and add the following:

[sandbox]
path = /home//sandbox
valid users = sandbox
read only = No
create mask = 0777
directory mask = 0777

Be sure to set the correct path to your share. Save the file and restart the Samba daemon:

sudo /etc/init.d/samba restart

That should be it. You should now be able to connect to your share from within the Windows guest. At this point you need to know what IP address to connect to from within Windows. This depends on what networking mode you are using for your virtual appliance.

Bridged Networking
In this mode, your guest OS has its own IP address and so the address it needs to connect to is your usual host machine’s address. In this case your address is probably the top line from the output of this command:

ifconfig
grep "inet addr:"NAT networking

In this mode, your guest OS shares your host’s address (in terms of other machines on the LAN) and communicates with the host via a private network. In this case, the IP address you need to connect to is most likely the bottom one from the output of this command:

ifconfig grep "inet addr:"

Connecting to the share from within Windows
If you are unsure as to your host’s IP address, try and ping it first from within the Windows guest to confirm you have the right one.

Having worked out what IP address to connect to, you should now be able to connect to your share from within Windows.

The easiest way to do this is:

1.Open up My Computer
2.Go to the Tools menu and then Map Network Drive
3.Choose a drive letter to map the network share to
4.In Folder, enter: \\HOSTIP\sandbox (replacing HOSTIP)
5.Click “Connect using a different user name” and enter:

username: sandbox
password: yourpassword

6.Click OK and then the Finish button to connect

Hopefully, congratulations are in order. If not, be sure to make sure that any firewalls you have running (host or guest) have the correct rules set to allow communication between the two systems.

SOURCE: 2tap

How to Add Shared Folders in Vmware Player

You have to add some shares to the configuration file of the virtual machine. Open the .vmx file in a text editor and add the following lines at the bottom of the file to add some random shared folders and enable the drag-and-drop feature:

isolation.tools.dnd.disable = "FALSE"

isolation.tools.copy.enable = "TRUE"

isolation.tools.paste.enable = "TRUE"

sharedFolder.maxNum = "2"

sharedFolder0.present = "TRUE"

sharedFolder0.enabled = "TRUE"

sharedFolder0.readAccess = "TRUE"

sharedFolder0.writeAccess = "FALSE"

sharedFolder0.hostPath = "C:\"

sharedFolder0.guestName = "C"

sharedFolder0.expiration = "never"

sharedFolder1.present = "TRUE"

sharedFolder1.enabled = "FALSE"

sharedFolder1.readAccess = "TRUE"

sharedFolder1.writeAccess = "FALSE"

sharedFolder1.hostPath = "/"

sharedFolder1.guestName = "/"

sharedFolder1.expiration = "never"

You can add more or less shares, but don’t forget to change the sharedFolder.maxNum value accordingly. Don’t worry about the locations of the shared folders, they can be changed with your VMware software.

Credit goes: http://chrysaor.info/?page=faq#shared_folders