A digital audio stream is represented by a sequence of momentary amplitude values, or samples. All samples in the stream have the same bitness, or size: 8, 16, 20, 24 bits and so on. Sample size defines sample value range and a dynamic range of the digital sound in decibels, which is near to six times larger than sample size in bits.
Audio stream contains various number of parallel channels. Usually, audio streams have a single channel (mono) or two channels (stereo). Modern audio hardware and software support five, eight or even more channels (for example, Dolby 5.1, 7.1 etc.). In each sample block, called a frame, channel sample values are placed together, from left to right. In a single frame, all channel sample values are sampled simultaneously, in the same moment of time.
A sampling rate means how frequently sample values are measured on recording or converted to signal amplitudes on playback. Sampling rate means how many frames (sample blocks, not individual channel sample values) are transferred within a second. This parameter is often called "samples per second" but it is correct only for a mono stream, when a frame contains a single sample value. In the general case, it should be read as "frames per second".
Sampling rate also defines an maximal signal frequency available for coding; it is a half of a given sampling rate, in Hertz. To represent audio signal containing frequencies up to 16 kHz, at least 32000 samples (frames) per second is required.
A combination of the sampling rate, sample size and number of channels is called a digital audio format.
An audio format can be shortly specified as these three values: 44100/16/2 or (44100, 16, 2) means 44100 samples per second, 16 bits per sample and two channels (stereo).
Multichannel (more than 2 channels) formats also contain a channel configuration (distribution) parameter.
|Channel/speaker configuration (distribution)|
For mono and stereo audio data formats, only known, dedicated speaker placements are available: for mono, there is only a single speaker; for stereo, there are only two speakers or headphone parts. So it is not necessary to specify their placement additionally.
For multi-channel formats, there can be several speaker placement schemes for the same number of channels. For example, old 5.1 speaker configuration used back channels (5.1 back) while modern configuration uses side channels (5.1 surround) instead. Therefore, it is not enough to specify only a number of channels; you need to specify channel-to-speaker relations as well.
VAC supports the following audio channels:
|LF||Low Frequency (Subwoofer)||8|
|FLC||Front Left of Center||40|
|FRC||Front Right of Center||80|
Hex mask represent a bit mask corresponding to a single channel, in hexadecimal form. To get a mask for several channels, add their masks together, using Windows calculator in HEX mode. For example, a mask for FC+BR+SL channels will be 4+20+200 = 224 hex (0x224 in popular C/C++ notation).
Channel data (sample values) in the frame are always arranged within the frame in the same order as listed in the table above. So left channel samples always precede right channel samples, subwoofer channel samples always precede back channels samples, and so on.
For details, see a description on the Microsoft site (enter "KSAUDIO_CHANNEL_CONFIG" in the search field if no results are displayed). Additional information can be found here (enter the "channel mask" if no results are displayed).
See here how to set speaker configuration for an audio device.
|Audio data encoding|
Sample values can be represented using various encoding methods. A simplest and most widely used method is the Pulse Code Modulation (PCM) when a numeric sample values immediately represents a linear absolute signal amplitude.
VAC supports only fixed-point PCM encoding.
Audio format conversion (resampling) is a particular case of data conversion in audio streams. To convert an audio data stream with a given format to a stream with another format, the following actions should be performed:
- Sampling rate conversion if sampling rates are different. Usually, it is a most time-consuming operation.
- Sample size (bit depth) conversion. It is the lowest time-consuming operation.
- Channel set conversion. Depending on the source and destination channel sets, it can consume less or more processing time.
See here for some known format conversion issues.
To communicate with an audio devices, each application must use some interface presented by Windows. Each interface consists of a set of functions and is restricted by a set of conditions and rules.
MME (MultiMedia Extensions) is an oldest audio interface introduced in Windows 3.0. it is intended for a streaming audio and has relatively high latency. Under Windows 9x/ME, MME interface uses old-style 16-bit code, as some other operating system parts. But MME is simple, exists in all Windows versions since 1991 and its behavior had not been changed. MME supports only shared access mode. Audio data are passed via buffer chain passed by a client. Most audio applications can use MME interface. Windows limits port name length to 31 characters.
DirectSound interface has been introduced in Windows 95 as a part of the DirectX acceleration set. It combines a low-level, hardware-close, low-latency audio operations with a high-level, device-independent programming. Audio data are passed via circular buffer. Originally intended for games, DirectSound interface quickly became very popular in sound synthesis and recording/playback applications. In Windows 5.x, DirectSound supports both shared and exclusive access modes. In Windows 6.x, DirectSound acceleration features (the exclusive access mode) are not supported anymore so interface efficiency became the same as MME.
Kernel Streaming (or WDM/KS Audio) interface has been introduced in Windows 2000/98. WDM stands for the Windows Driver Model, an universal driver structure and behavior making available to use a common binary driver file in Windows 98/ME/2000/XP and higher systems. KS stands for the Kernel Streaming, the audio/video streaming technology of the Windows kernel. WDM/KS Audio is a sophisticated lowest-level interface including many new features, it allows to achieve highest audio precision and lowest latency. In Windows 2000/XP and later, all higher-level interfaces are implemented on top of the WDM/KS Audio interface. WDM/KS supports only exclusive access mode. In Windows 5.x, audio data are passed via buffer chain (standard streaming or legacy mode); in Windows 6.x, circular buffer mode is also supported (looped streaming or RT Audio mode). Streaming mode support is dependent on a particular driver.
WASAPI interface has been introduced in Vista. The abbreviation stands for Windows Audio Session API. It supports both shared and exclusive access modes. In the exclusive mode, it is highly efficient like hardware-accelerated DirectSound but in shared mode, its efficiency is comparable with shared-mode MME and DirectSound. Main WASAPI advantage is that it has a modern style, object-oriented, flexible, allows to use local and global effect processors (LFX and GFX) and provides a way to insert user-defined processing objects (APOs) in a signal path. Audio data are passed via circular buffer.
Only KS interface allows direct driver connection with no intermediate layers. An application having properly-implemented KS interaction can achieve highest quality and efficiency. Only driver and/or hardware bugs may affect signal quality and latency.
Other interfaces work via System Audio Engine. WASAPI in exclusive mode has almost the same efficiency as KS but may be affected by system layer implementation (for example, there are some problems in Win7 fixed in Win8).
Four interfaces described above are Windows standard ones. Additionally, there are some third-party interfaces intended for professional audio processing. Most popular of them is Steinberg's ASIO (Audio Streaming Input/Output). ASIO is designed for extreme performance and precision. VAC doesn't directly support ASIO but there are some ASIO wrappers over WDM/KS like ASIO4ALL or ASIO2KS.
Each audio device in Windows is represented by its port. The port is a "logical" or "software" device connection point in the system like network ports. Don't confuse software ports with hardware input/output ports.
The "port" term is almost not used in official documentation; the "device" term is used instead. It often causes misunderstanding because a single hardware device is usually represented by multiple software connection points in the system. So VAC documentation uses the "port" term to represent a "software connection point".
Audio device ports are called Wave ports. By example, a typical audio card has two wave ports: Wave Input and Wave Output. The recording port is used to record (capture) audio data to applications, and the playback port is used to play (render) audio data from applications.
Audio ports are accessed via audio interfaces. Different interfaces can expose different port sets. For example, for a single WDM/KS port that represents a pin, higher-level interfaces may create several logical endpoints that represent separate source lines.
For recording/input ports, the "capture" synonym can be used. For playback/output ports, the "render" synonym can be used.
In the WDM/KS driver technology, each device driver exposes a set of pins. Each pin represents a device connection point: recording/capture, playback/render, volume control/mixer, clock and so on. A pin is a low-level synonym of a port. The "pin" term is similar to the "lead" in electronics.
To use a pin for audio streaming, Windows creates an instance of the pin by "opening" it. Each pin instance forms a separate audio stream. If an application accesses the pin directly, using WDM/KS interface, the instance is created for the application itself, nobody else can use this instance. If an application accesses the pin in the shared mode through System Audio Engine, the engine creates a single instance for itself and then shares it among all connected applications. It allows single-client drivers to be used by multiple applications at the same time.
If the driver supports multiple pin instances, there can be multiple clients of a corresponding port. Most drivers support only a single pin instance so there can be only a single client (System Audio Engine or a WDM/KS application).
A typical audio adapter has a single digital recording channel that application can use to capture audio signal but several source (input) lines like Microphone, Line, Phone, CD and others. To capture audio signal coming from a particular source line, this line should be selected first. In Windows 5.x, you need to use Windows Mixer application to select a source line. Windows 6.x creates audio endpoints for this purpose.
As a virtual device, VAC has no real source lines. But some applications want to connect to a given line type (Microphone or S/PDIF) so VAC provides several fake source lines. All of them are identical but Windows can use different default settings for each line. For example, Windows 6.x uses less sampling rate recording from the Microphone line than from the Line In.
Source line set is a cable configuration parameter.
Windows versions prior 6.x create recording (capture) waveform audio port for each capture waveform device or pin exposed by a driver. This recording audio port represents entire device that may have several source lines. Selecting such port in a recording application was not enough to record audio signal from a particular source line. A device mixer should be configured to select (connect) an appropriate source line before recording starts.
To eliminate additional steps, Windows 6.x introduced a new thing called endpoint, or an "endpoint device". Instead of creating recording audio port from an entire device, Windows creates a separate endpoint from each device's source line, naming them like "Mic Volume (AC97 Audio)" or "Line In (AC97 Audio)", and exposes them as a recording port set. When an application selects a particular endpoint as a recording port, Windows automatically selects the appropriate source line in the device's mixer.
Since source lines in most audio devices are multiplexed, not mixed, only a single endpoint can be used for recording at a time. If a recording endpoint is used for recording, all other device endpoints multiplexed in the same group become unavailable.
VAC devices and their source lines are software-emulated so they are represented as "mixed" and several applications can record from different cable endpoints simultaneously.
Some endpoints can be connected (plugged in) while other are unconnected (not plugged in). With a real hardware device, an endpoint can become connected when a connector is plugged into a jack. Only connected endpoints are available for playback/recording and visible in application's audio device list.
You can view all audio endponts and their states in Windows Audio Properties applet, right-clicking on any item of Recording or Playback lists and enabling "Show disabled endpoints" and "Show disconnected endpoints".
Please note that endpoint creation in Windows 6.x is a very slow process. For example, creation of 30-40 endpoints (when a driver is initially loaded or restarted) may require up to a minute of 100% CPU load on 2 GHz machine.
Also please note that all Virtual Cables with enabled speaker pin type will have the same playback endpoint name, like "Speakers (Virtual Audio Cable)". It is by system design, not due to a bug.
|Stream (pin instance)|
In general, a term "stream" is used to designate any kind of data stream (a continuous data flow).
For the audio application, the "stream" means an audio connection with a data flow to (or from) an audio device.
For a WDM/KS driver, this term is used to designate a data flow connected to a particular pin instance by request from a client. Each new pin instance forms a new stream. Each stream has its own audio format. An application can be connected to a stream either directly or via the System Audio Engine proxy layer.
The application that uses an audio port/endpoint and opens it, connecting to its provider, is called a client. Most low-level audio drivers allow only single client (instance) for each pin but System Audio Engine supports unlimited number of clients. VAC driver allows any number of clients to open each pin directly (in the exclusive mode).
If an application requests a port connection several times without closing it, it means that port provider has several clients. In other words, each port opening request is treated as new client appearance. Client disconnects from the provider when it closes a port instance.
When an application accesses low-level audio port (pin), provided immediately by a low-level driver, by WDM/KS interface, it becomes a driver's client. When an application accesses a high-level audio port (endpoint), it becomes System Audio Engine's client. In turn, System Audio Engine accesses a low-level port (pin) and becomes low-level driver's client.
All audio interfaces use audio buffer conception to interchange audio data between applications and devices. A buffer is a memory block containing an audio data fragment or intended to be filled with such data fragment. Data buffering is used to make data transfer more smooth and reliable.
A smallest data unit that a computer can transfer between a device and main memory is a word. In audio, each computer word contains only 1-2 frames of 16-bit stereo sound. It is extremely small amount for real-time streaming. So audio frames are packed in blocks containing thousands, hundreds or (as an exception) dozens of frames each.
In MME and legacy WDM/KS, a buffer chain algorithm is used to interchange audio data between an application and the audio subsystem; application sends several buffers to driver, driver plays them or fills them with data, and returns them back to application. An application must use more than one buffer because some time passes between a moment when a device driver inform about buffer completion and the moment when it receives a next buffer from the application.
In DirectSound, WASAPI and modern (RTAudio) WDM/KS, ring buffers are used; application allocates a single memory block logically divided into several parts, tells the driver which part is ready for playback/recording, and the driver notifies the application when part processing is done.
To maintain a smooth and continuous audio stream, an application must provide enough buffering time. Most applications use 500.1000 ms of buffering time, divided into 8..12 chain buffers in MME or to 4..12 circular buffer parts in DirectSound, WDM/KS or WASAPI . But the more buffering time, the more latency is introduced. So you need to balance these parameters for each configuration used.
When a Virtual Cable gets its first input or output client (stream), a particular audio format is chosen as the cable format. Cable format parameters are determined from a first client (stream) format and the cable format range.
Internal mixing is performed in the cable format so all render/output stream data are converted to the cable format, and mixed results are converted from the cable format to capture/input stream formats. If cable channel mixing is enabled, VAC also converts channel sets in multichannel streams.
|Cable format range|
A range of audio formats allowed to be selected as a cable format. The wider this range is, the more formats are available to be chosen for a cable, the more often format conversion occurs. Format range is a cable configuration parameter.
|Cable channel mixing|
By default, VAC converts channel sets in multichannel streams if number of channels in stream and cable formats are different. For example, when converting from stereo stream to mono, VAC mixes (sums) both left and right channels, producing a single channel stream. When converting from mono stream to stereo, VAC spreads a single channel into left and right. When converting 4-, 6- and 8-channel streams, more complex rules are applied.
If channel mixing is disabled, VAC performs channel scattering (placing sequentially packed channel data to specified channel configuration positions) or gathering (extracting specified channel configuration positions and placing them to a sequentially packed set) instead of mixing them. See here for details.
In some situations, disabled channel mixing may produce undesirable effects.
Channel mixing mode is a cable configuration parameter.
|Stream format limiting mode|
|System audio engine (formerly KMixer)|
KMixer (kernel-mode audio mixer) is a system kernel-mode audio component (a special kind of an audio driver), a part of the Windows 98/ME and 2k/XP/2k3 audio subsystem. In Vista/Win7, KMixer has been replaced by user-mode AudioDG service. For convenience, it is named System Audio Engine here.
System Audio Engine acts as a "proxy" to each WDM/KS audio driver accessed via DirectSound, MME and WASAPI interfaces in the shared mode. When an application uses shared connection mode, a separate pin instance is implicitly created to the System Audio Engine. See Audio layering issues for details.
In some cases, restarting System Audio Engine may help to eliminate some audio problems without rebooting the entire system.
|Shared and exclusive pin access|
Most audio device drivers support only a single instance of each capture or render pin (they are single-client drivers). To allow to access these pins from several applications at the same time, an intermediate (proxy) layer is required. In Windows, this layer is provided by the System Audio Engine: MME (all) and DirectSound/WASAPI (by default) connections are established in the shared mode when the engine creates a single pin instance for itself and all clients are connected to the engine, not immediately to the pin. System Audio Engine chooses an appropriate format for the pin instance, and then converts audio data between pin format and client stream formats. This mode is convenient but often not efficient enough.
DirectSound (in Windows 5.x), WASAPI (in Windows 6.x) and WDM/KS (in all systems) support exclusive pin access modes while the pin instance is created for a requestor application only. No other clients (applications and even system sounds) are allowed to share this instance. The pin is instantiated with the format requested and no format conversion is performed between client application and the driver. This mode is efficient but not convenient enough because there can be only a single application that can use the pin at a time. If the driver supports multiple pin instances like VAC, there is no such restriction.
Implementing multi-client pin access, VAC behaves like System Audio Engine in the shared mode, mixing playback streams together, distributing cable data among recording streams and performing format conversions. So most efficient VAC usage method is to use exclusive access modes when connecting to Virtual Cables is possible.
PortCls stands for "Port Class Driver". It is Windows kernel-mode library (portcls.sys) that should be used by each audio miniport driver to connect to the system. PortCls receives all system requests, translates it and passes to a miniport driver.
In Windows XP and later systems, on a multi-CPU/core hardware, PortCls has some bugs. To avold these bugs, VAC implements a workaround, processing most streaming requests without calling PortCls. Processing can be switched back to PortCls engine for particular cables using cable configuration parameters.
When an application and a driver deal with digital audio, they don't interchange single samples/frames; instead, they use memory buffers to store blocks of audio data. To respond to a real-time event, an application or a driver needs some time, from microseconds to dozens of milliseconds. Due to buffering and processing delays, there are some time between an audio signal arrives at a device input and its digitized value arrives in application memory. This time period is called latency.
|Timing event (formerly an Interrupt)|
Due to a discrete nature of the digital audio, continuous digital audio stream transfer is performed in series of blocks. To transfer a stream from each cable's output port to its input port, VAC has internal timing clock that generates system events allowing VAC to be called to transfer a next data block of the stream. Earlier VAC versions used timer interrupts for that. Current versions use timer events but the "interrupt" term is kept for a succession.
The more is event frequency, the shorter is event period, the less is block size, the smoother is stream transfer. But decreasing interrupt/event period causes increase of system timer resolution and timer interrupt frequency so system overhead is increased too. VAC driver sets system timer resolution to a half of the "MS per int" parameter specified.
|Mixer (volume control tool)|
In general, a mixer stands for a device that mixes several audio signals together and allows to control their volume, balance, timbre and other parameters. Almost each audio adapter has its own mixer that allows to select recording sources, change recording/playback levels, and so on. These features are called a "adapter mixer" or a "driver mixer".
Windows prior to Vista/Win7 have a standard mixer control application that is often called "Windows mixer". It can be invoked by double-clicking at the speaker icon in the system tray. A window with a set of sliders and check boxes is displayed. You can view the mixer in two modes: playback (the default) and recording. In playback mode, the mixer controls output audio lines available for playback and repeated (monitored) input lines routed to the output (speakers). In recording mode, the mixer controls input lines available for recording.
To configure mixer panel, open Options menu and select Properties. In the dialog, select a device you want to control, select a mode and check input/output lines you want to see in the panel.
In Windows 6.x, system mixer became much more simpler. It can be opened by right-clicking the speaker icon in the system tray and selecting "Open Volume Mixer". You can change playback/recording levels for devices selected under an icon or for system/application sounds. Clicking on speaker icons at the bottom, you can mute/unmute audio sources.
Don't confuse Windows mixer control application with KMixer (System Audio Engine) Windows component.
System tray (notification area) is a rightmost area of the horizontal taskbar or a lowest area of the vertical taskbar, where system clock and application icons are located. In Win 5.x, this area always shows all existing icons. Starting from Win 6.x, some icons can be hidden. If there are hidden icons, double up arrow is displayed in the notification area.
|Windows Control Panel|
Windows Control Panel is a set of Windows built-in control and management applets. You can open it by clicking Start - Settings - Control Panel.
Don't confuse Windows Control Panel with VAC Control Panel.
|Audio Properties Applet|
Audio Properties Applet is a built-in Windows Control Panel applet that manages and controls multimedia and audio devices. The applet can be opened by two ways:
|Windows Device Manager|
Device Manager is a built-in Windows Management Console applet, displaying a device list and allowing to configure/reinstall them. Device Manager can be opened by several ways:
- Right-click on My Computer and select Manage.
- Right-click on My Computer, select Properties, open Hardware tab and click Device Manager.
- Open Windows Control Panel, open Administrative Tools then open Computer Management.
Each streaming device, both hardware and software, needs a clock source to transfer streaming data smoothly and uniformly. After each time period measured by the clock, a portion of streaming data is sent or received.
An asynchronous device (a computer, audio card, radio etc.) has its own clock source (a clock generator). A synchronous device (also called "slave") receives a clock signal from a master device having its own clock generator. Some audio devices (for example, professional audio cards) having their own clocks and normally working asynchronously, allow to use an external clock source to work synchronously with en external device.
When the CPU interacts with an audio adapter (on-board chip, a card, an external USB adapter) to send/receive a command or data block,
CPU clock is used as a source, and the audio adapter acts as a slave
(synchronous) device. But in audio streaming mode, adapter's clock is used (except of professional adapters that support external clock source) and CPU acts as a slave device.
In other words, the CPU determines when to send/receive a command or data block but an adapter determines when playback/recording of data portion completes. As the streaming has been started, CPU cannot instruct the adapter to move streaming data slower or faster; it only can change the sampling rate if the adapter supports sampling rate changing on the fly.
Two asynchronous devices, each of them has its own clock source, cannot have exactly the same clock frequency (rate, or speed). Since their clocks are different, their rates always are slightly different, and actual sampling rates are slightly different too. As a pair of a real watches, two asynchronous audio devices cannot have their data streams to flow in a strict match, and one stream slowly forestalls while other stream is late. As a result, there will be some gaps or losses in the overall audio data stream.
VAC supports clock correction feature to minimize this effect.
|System default (preferred) audio device|
Windows supports up to 256 different MME/DirectSound/WASAPI audio devices (ports) for audio input and output. Any of them can be assigned as a system default, or a preferred device that is used by default. Such assignment can be performed using Audio Properties applet. In application's device selection menus, a default device appears as the "Microsoft Sound Mapper", "Wave Mapper", "System Default" or something like.
If an application issues a request to a default device, Windows routes it to an actual device that was previously set as a default.
In Windows 5.x, default audio devices are set at a per-user basis. For each user account, there are its own default recording and playback default device settings. In Windows 6.x, default devices are set at per-system basis.
See the system default device issues for details.
|Default audio format for a device|
To support shared access mode, System Audio Engine creates a single, common pin instance for all client applications, using a common audio format. But the engine does not know which formats will be used in the future so it cannot choose a best format automatically.
In Windows 5.x, common format selection is based on the first connection request. For a recording request, the common format is the same as requestor's format. For a playback request, the common format is most "wide" format supported by the pin. If the pin supports high sampling rates, bit depths and number of channels, using most usual formats involves unnecessary format conversions, overhead and audio degradation.
To control these issues, Windows 6.x maintain a default audio format for each playback and recording device. When a device is opened in shared mode, System Audio Engine always uses its default format. So you can freely choose between default formats to achieve either best audio quality or best performance or best compatibility.
Default formats can be chosen in the "Sound" applet from Windows Control Panel. Open "Playback" or "Recording" tab, double-click a device and select "Advanced" tab.
Starting from Win7, Windows implements the Listen feature intended to monitor (hear a signal from) a recording audio device. When this feature is turned on for a particular recording device, System Audio Engine starts to continuously record from the device and immediately play back recorded signal to the given playback device. Thereby this feature is similar to Audio Repeater application.
To use Listen feature for a device, open the Audio Properties Applet, select Recording tab, double-click an endpoint, open the Listen tab, check the "Listen to this device" checkbox and select desired output device (usually speakers).
With this feature, you can either listen for a signal coming from a Virtual Cable (enabling Listen feature for a source endpoint for the cable and choosing headphones/speakers as a target device) or supply a Virtual Cable with a signal (enabling Listen feature for a source device and choosing Virtual Cable as a target device).
Once you turned Listen feature on, it remains active until explicitly turned off. Since there is no visible activity indicator, it is easy to forgot about it. If you have wrong/unwanted audio signals played back and/or recorded, make sure that there is no Listen feature activated by mistake for some devices used.
|Speaker pin type|
WDM/KS drivers of most audio adapters provide KSNODETYPE_SPEAKER type for their playback pins. Such pin type allows to configure channel distribution with the "Configure" button of Windows Audio Properties Applet but System Audio Engine starting from Win 6.x always assigns the "Speakers" name for endpoints linked to these pins. If an audio adapter (real or virtual) has more than a single output line, it is impossible to distinguish them by name.
As a workaround, VAC uses KSNODETYPE_LINE_CONNECTOR for playback pins by default. It allows to use an unique name like "Line N" for each output line but does not allow to use system channel configuration features. Additionally, some channel processing problems may occur in applications using DirectSound.
Please note that enabling speaker pin type for some cables under Win 6.x causes playback endpoints of these cables to have the same "Speakers" name. Most audio applications distinguish between audio devices only by their names, not unique internal identifiers. Therefore, if you enable speaker pin types for two Virtual Cables and both these cables have the same "Speakers (Virtual Audio Cable)" name, audio application might confuse between these cables. Most probably an application will lose proper cable selection between running sessions.
A privileged (superuser) account in the system. Applications that run from this account can perform various administrative actions. Since VAC is a device driver, a special privilege is required to install it into the system or to restart it, applying a configuration change.
In Windows 5.x, any member of the "Administrators" group has such privilege and can perform these actions.
In Windows 6.x, there is UAC feature (enabled by default). Only built-in administrator account (named "Administrator") can perform all privileged actions without additional measures. Other accounts marked as "administrator" are "virtually privileged" and can perform privileged operations only by privilege elevation. The difference is only that a plain user account requires administrator password for privilege elevation while account marked as administrator does not.
If UAC is enabled, Windows tries to automatically elevate privilege level for applications marked as privileged (such applications cannot work from a non-privileged account). VAC installer and uninstaller are marked as privileged applications so Windows will ask for privilege elevation if you don't have enough privileges.
But VAC Control Panel is not marked as privileged because it can perform both privileged and non-privileged actions. So if you run VAC Control Panel from an account other than "Administrator" (even marked as administrator), only non-privileged actions will be available. You will not be able to perform actions that require driver or System Audio Engine restart.
To start an application behalf on the built-in Administrator account, either log in using "Administrator" as a user name or right-click an application icon and select "Run as administrator" item.
Initially, Windows supported only local work session when a user sits immediately at the console (display, keyboard, and mice) of a computer running Windows. Starting from Windows 2000, remote sessions were introduced, when a user sits at a "terminal" (or a "client") computer but all user's actions are sent to a remote "terminal server" computer running Windows and the results (screen contents, sounds etc.) are sent back to a client computer. Terminal connections are established via Remote Desktop Protocol. Using such connection, a user can work with a remote computer as if he/she worked with it locally. But there are some limitations.
There are two types of Windows remote connections: separate (isolated) and direct ("console"). For a separate connection, Windows establishes a new login session, isolating user environment from other users. For a direct connection, remote user is connected to a main console session environment.
With desktop-sharing products like TightVNC, TeamViewer, LogMeIn, Remote Administrator, connections are established directly by translating screen updates from the server to your computer and translating your mouse/keyboard actions from your computer to the server. No separate logon session is created and your computer acts as a "remote console" for the server computer. Having such connection, you can use all server resources, feeling yourself like sitting at the server immediately.
There are some compatibility issues related to remote connections.
An environment created by virtualization tools is called "virtualized environment".
Different virtual machine software offer different layers of platform virtualization. Some platform virtualization products offer full hardware virtualization (VMware, Virtual PC, Virtual Box, Parallels Workstation, Virtual Iron, Bochs) while most other products like Parallels Virtuozzo (mostly used in Windows VPS/VDS technology) offer only a partial virtualization (for example, OS level virtualization).
There are some compatibility issues related to virtualized environment.
Digital signature is a special digital sequence to check data authenticity. If data are illegally modified (tampered with), their signature becomes invalid and it can be easily checked.
Windows uses two types of digital signatures for executable (PE) files:
- Publisher signature is applied directly by a software publisher (vendor) using a publisher certificate and certify the file as authentic one. A publisher certificate is obtained once and then used to sign all developed software. Publisher certificates can be obtained from many companies but only six of them can issue certificates to sign Windows kernel-mode executables. These six companies issue publisher certificates only for companies (juridical persons), not for individuals (natural persons). Therefore, individual software developers cannot obtain a publisher certificate.
- Windows Logo signature is applied by Microsoft Windows Hardware Quality Lab (WHQL) and certify the file as passed Windows-compliance tests. A software package is submitted to WHQL to test and if tests are successful, WHQL signs executable files as Windows-compliant. Windows Logo signature requires a publisher signature. WHQL must sign each software release, even a minor bugfix.
A buffer overflow occurs if the buffer has no room for data should be placed into it (some data will be lost from a flow). An underflow occurs if the buffer has not enough data should be retrieved from it (data flow will contain a gap). If a buffer is filled at one side and drained at another side, overflows will occur if the filling flow is more "thick" than the draining one, and vice versa.
Compared with car fuel tank usage, an overflow occurs if your car tank has no more room to accommodate fuel provided via the filling hose. If the hose has no special protective cutoff, fuel excess will flow out and you lose it. On the contrary, if you don't fill a tank at the proper time, it runs out and your car will stop suddenly, requiring a maintenance.
In a multi-node or multi-layer chain, stream data overflow/underflow not necessary means a crack, pop or glitch. On the contrary, no data overflows/underflows do not mean that there are no cracks, pops or glitches. Data processing node/layer (a driver, an application, a service, a plugin etc.) that registers an overflow/underflow knows nothing about other nodes/layers in the chain; if they use extensive buffering, it may prevent audio stream from breaking. Therefore, if a node/layer had successfully passed data portion to another node/layer in the chain, there may be buffering problems in other nodes/layers, causing stream breaks.
PortCls system driver has a bug causing a significant drop of audio data processing efficiency on multi-CPU or multi-core hardware. VAC implements multiple subdevices where most audio drivers implement only a single subdevice so this bug does not occur with most hardware audio drivers.
The problem is described in details in microsoft.public.development.device.drivers newsgroup. You can find the post, entering "skype portcls getmapping" in Google search string. Sorry, there is no stable link.
The best way to avoid this problem is to use VAC internal data processing engine instead PortCls one (internal engine is used by default).
If PortCls engine should be used for some reason, only possible workaround is to disable concurrent request processing in PortCls. For this, VAC offers some driver parameters and cable parameters to restrict CPU affinity of worker threads, belonging to System Audio Engine or to any client. Create the appropriate driver parameter value in the registry, setting it to a number of cables causing the problem, or create affinity restriction parameters for selected cables. Then restart VAC driver to propagate parameter changes.
A worker thread is a driver's thread that performs all stream processing work (data transfer, volume control, format conversion etc.). Different threads can be executed on different CPUs/cores, achieving optimal performance and load distribution. By default, VAC driver starts one worker thread per physical CPU/core so all available CPU power can be used to process stream data.
By default, worker thread scheduling priority is relatively high (between a normal thread priority and highest possible priority value). It guarantees that stream data processing will take advantage over most regular threads but not to consume all possible CPU time.
|Stream buffer watermarks|
The watermark technique is used to optimize buffer usage if client applications use non-optimal buffering settings and don't allow to specify them explicitly. In terms of the car fuel tank usage, this technique is like a manager that helps an absent-minded car owner to fill the tank in good time. Usually, a car can be driven until its fuel tank is completely exhausted; a manager detects if fuel level is too low and suggests to refill before fuel is exhausted completely.
In stream buffer watermark technique, stream data buffer provided by a client is like a tank, and the marks are measured in milliseconds of audio data duration, marking minimal and maximal audio data/space reserve limits. If watermark control is enabled, driver does not process stream data until client supplies enough data/room buffers up to high watermark specified (in duration).
Watermark technique does not eliminate buffering problems because VAC driver cannot force applications to provide buffers as fast and smooth as possible. This technique only can reduce amount of buffer overflows/underflows, replacing continuous popping/crackling with isolated and less frequent pops/cracks.
|Stream data buffer|
VAC driver uses a small internal data buffer for each stream, used for technical purposes. In most cases, a very small (several milliseconds) buffer length is enough to perform all tasks needed by the driver. But this buffer can significantly improve stream stability if a client application or System Audio Engine does not provide data buffers in time. Please read here for details.
Modern Windows NT releases are the following:
- 5.0 - Windows 2000 (Win2k)
- 5.1 - Windows XP (WinXP)
- 5.2 - Windows 2003 Server (Win2k3)
- 6.0 - Windows Vista, Server 2008
- 6.1 - Windows 7 (Win7), Server 2008 R2
- 6.2 - Windows 8 (Win8)
So the "Win 5.x" means Windows 2000/XP/2003 and "Win 6.x" means Vista, Server 2008, Windows 7 and Windows 8.
Windows 9x/ME have 4.x versions and don't belong to Windows NT family.