biblesync

package: biblesync-devel

title: biblesync(7)

text:
# biblesync(7)

## NAME
biblesync - multicast navigation synchronization in Bible programs

## SYNOPSIS

```
#include <biblesync.hh>

typedef enum_BibleSync_mode {

    BSP_MODE_DISABLE,

    BSP_MODE_PERSONAL,

    BSP_MODE_SPEAKER,

    BSP_MODE_AUDIENCE,

    N_BSP_MODE

} BibleSync_mode;

typedef enum_BibleSync_xmit_status {

    BSP_XMIT_OK,

    BSP_XMIT_FAILED,

    BSP_XMIT_NO_SOCKET,

    BSP_XMIT_BAD_TYPE,

    BSP_XMIT_NO_AUDIENCE_XMIT,

    BSP_XMIT_RECEIVING,

    N_BSP_XMIT

} BibleSync_xmit_status;

typedef void (*BibleSync_navigate)(char cmd, string speakerkey,

                                   string bible, string ref, string alt,

                                   string group, string domain,

                                   string info,  string dump);

Public interface:

BibleSync *object = new BibleSync(string application,

                                  string version,

                                  string user);

BibleSync_mode BibleSync::setMode(BibleSync_mode mode,

                                  BibleSync_navigate *nav_func,

                                  string passPhrase);

BibleSync_mode BibleSync::getMode(void);

string BibleSync::getVersion(void);

string BibleSync::getPassphrase(void);

BibleSync_xmit_status BibleSync::Transmit(string bible, string ref, string alt,

                                          string group, string domain);

BibleSync_xmit_status BibleSync::Chat(string message);

static int BibleSync::Receive(void *object);

bool BibleSync::setPrivate(bool privacy);

void BibleSync::setBeaconCount(uint8_t count);

void BibleSync::setUser(string user);

void BibleSync::listenToSpeaker(bool listen, string speakerkey);
```

## DESCRIPTION
BibleSync is a published protocol specification by which cooperating Bible programs navigate together. It is implemented as a C++ class providing a small, clean interface including basic setup, take-down, transmit, polled receive, and a bare few utility methods.

The value of BibleSync is found in several examples:

A single user may have multiple programs, or multiple computers/devices, all of which he wishes to follow along together.

Similarly, a group of people working closely together, such as translators or a group Bible study, can stay together as they work.

In an instructional motif, BibleSync takes either the active or passive mode, providing for a unidirectional navigation control.

## BIBLESYNC ESSENTIALS
BibleSync communicates using local multicast. Three operational modes are provided: Personal, Speaker, or Audience.

In Personal mode, BibleSync operates as a peer among peers, both sending and receiving navigation synchronization on the shared local multicast network. Applications are expected to respond appropriately to navigation, and to send synchronization events of their own as the user moves about his Bible.

In Speaker or Audience mode, BibleSync either transmits only (Speaker) or receives only (Audience) navigation. The Audience is expected to follow along with the Speaker's direction. The Speaker ignores incoming navigation; the Audience transmits no navigation.

The difference between Personal and Speaker/Audience is thus strictly as to whether both sides of the conversation are active for each participant.

On startup of the protocol, BibleSync transmits a presence announcement, informing other communication partners of the application's participation. BibleSync makes this announcement available to the application; whether the application shows these announcements to the user is the application designer's choice.

Thereafter, as appropriate to the operational mode selected, BibleSync is tasked with polled reception of incoming navigation event packets and transmission of navigation event packets on the user's part.

Transmitters (Personal and Speaker modes) issue availability beacons every 10 seconds. Received beacons for previously-unknown Speakers are handed up to the application as "new Speaker" events. These beacons provide for receivers (Personal and Audience modes) to maintain a managed list of available Speakers. Furthermore, when a transmitter ceases to issue beacons, its presence in the list of available Speakers is aged out until being removed after 30 seconds of beacon silence. The application is again informed as a Speaker ages out with a "dead Speaker" event.

Default listening behavior is that the first Speaker heard via beacon is marked for listening. Other transmitters claiming Speaker status via beacon are initially ignored, but their presence is made known to the application. This provides for the application to maintain a list from which the user can select Speakers he wishes to synchronize his application. It is useful for the application to provide blanket "listen to all" and "listen to none" functions, as well as per-Speaker selections, informing BibleSync of these choices. In any case, this default "first Speaker only" policy can be overridden by the application with any other policy desired, through the use of listenToSpeaker() as the application designer requires.

Synchronization events include 5 data elements: The Bible abbreviation; the verse reference; an alternate reference (if desired; not required) which may allow the application to interpret better based on variant versification; a synchronization group identifier; and the domain.

The group identifier is a single digit between 1 and 9. The specification is imprecise as to this parameter's use. The initial implementation of BibleSync in Xiphos uses the synchronization group as an indicator of the tab number in its tabbed interface: Not only is the Bible navigated, but the tab in which to navigate is selected.

The domain parameter is currently fixed as "BIBLE-VERSE". This will be put to greater use in future revisions of the protocol.

BibleSync transmits no packet when the application leaves the conversation.

## PUBLIC INTERFACE

### Object creation
The application must create a single BibleSync object, identifying the application's name, its version, and the user.

### setMode
setMode identifies how BibleSync should behave. The application must provide as well the navigation callback function by which BibleSync will inform the application of incoming events; the callback makes all the navigation parameters provided in event packets available to the application. setMode returns the resulting mode. The application provides the passphrase to be used as well; this argument defaults to "" (empty string), indicating that the existing passphrase should be left in place.

### getMode
The application may request the current mode.

### getVersion
The version string of the library itself is returned.

### getPassphrase
Intended for use when preparing to enter any active mode, the application may request the current passphrase, so as to provide a default.

### Transmit
The protocol requires all the indicated parameters, but all have defaults in Transmit: KJV, Gen.1.1, empty alternate, 1, and BIBLE-VERSE.

### Chat
This is a method for transmission of casual text messages to all others in the conversation. It is expected to be received by applications who will display them in a suitable manner to the user.

### Receive
This is a static method accessible from either C or C++. It must be called with the object pointer so as to re-enter object context for the private internal receiver. Receive() must be called regularly (i.e. polled) as long as it continues to return TRUE. When it returns FALSE, it means that the mode has changed to BSP_MODE_DISABLE, and the scheduled polling should stop. See also the note below on polled reception.

### setPrivate
In the circumstance where the user has multiple programs running on a single computer and does not want his navigation broadcast outside that single system, when in Personal mode, the application may also request privacy. The effect is to set multicast TTL to zero, meaning that packets will not go out on the wire.

### setBeaconCount
Beacon transmission occurs during every Nth call to Receive(); the default value is 10. This presumes the application will call Receive() once per second. If the application will call Receive() less frequently, divide that time (say, 2 seconds) into 10 to get a value (5) to use with this call. Use setBeaconCount() prior to enabling Personal or Speaker mode.

### setUser
If the application allows the user to set a name via settings dialog, setUser() is available to re-assign the associated user name as seen by others.

### listenToSpeaker
Aside from default listen behavior detailed above, the application specifically asks to listen or not to listen to specific Speakers. The key is as provided during the notification of a new Speaker.

## RECEIVE USE CASES
There are 7 values for the cmd parameter of the nav_func. In all cases, the dump parameter provides the raw content of an arriving packet.

### 'A'
Announce. A general presence message is in alt, and the individual elements are also available, as overloaded use of the parameters: bible contains the user; ref contains the IP address; group contains the application name and version; and domain contains the device identification.

### 'N'
Navigation. The bible, ref, alt, group, and domain parameters are presented as they arrived. info and dump are also available.

### 'S'
Speaker's initial recognition from beacon receipt. Overloaded parameters are available as for presence announcements.

### 'D'
Dead Speaker. speakerkey holds the UUID key of a previously-identified application which is no longer a candidate for listening.

### 'C'
Chat. Message text is in alt and other parameters are overloaded as per announce, above.

### 'M'
Mismatch. The incoming event packet is mismatched, either against the current passphrase or for a navigation synchronization packet when BibleSync is in Speaker mode. The info parameter begins with either "announce" or "sync", plus the user and IP address from whom the packet came. As well, in the sync case, the regular bible, ref, alt, group, and domain parameters are available. In the announce case, the presence message is in alt, with overloaded individual parameters as previously described.

### 'E'
Error. This indicates network errors and malformed packets. The application's nav_func is provided only the info and dump parameters.

## NOTES

### Polled reception
The application must provide a means by which to poll regularly for incoming packets. In Xiphos, which is built on GTK and GLib, this is readily provided by mechanisms like g_timeout_add(), which sets a regular interval call of the indicated function. GLib will re-schedule the call as long as the called function returns TRUE. When it returns FALSE, GLib un-schedules the call. Receive() adheres to this straightforward convention. Therefore, it is imperative that every time the application moves from disabled to any non-disabled mode, Receive is again scheduled for polled use.

A 1-second poll interval is expected. Brief experience during development has shown that longer intervals lead to a perception of lag. If the application designer nonetheless expects to call Receive() less frequently, it is necessary to use setBeaconCount() to change the number of calls to it between beacon transmissions.

During every Receive() call, all waiting packets are processed.

### No datalink security
BibleSync is a protocol defined for a friendly environment. It offers no security in its current specification, and any packet sniffer such as wireshark(1) or tcpdump(8) can see the entire conversation. The specification makes passing reference to future encryption, but at this time none is implemented.

### Managed Speaker lists
The addition of transmitter beacons was a result of initial experience showing that it can be too easy for a user to mis-start BibleSync, or for a malicious user to interject himself into serious work. The goal of beacons is to provide a means by which, on the one hand, the user can be made aware of who is attempting to be a Speaker and, on the other hand, confine the set of Speakers whom the user will permit to make synchronization changes in the application. The simplest use of 'S' new Speaker notification events is to respond with listenToSpeaker(true, speakerkey) which in effect makes BibleSync behave as though there are no beacons. More serious use of 'S'/'D' is for the application to manage its own sense of available Speakers, providing a means by which the user can make sensible selections about how to react to each Speaker's presence. BibleSync can be told to listen to legitimate Speakers, and to ignore interlopers, whether intended maliciously or merely due to other users' inadvertent behavior.

### Sending verse lists
One of the better uses of BibleSync is in sharing verse lists. Consider a relatively weak application, perhaps on a mobile device, and a desktop-based application with strong search capability. Run searches on the desktop, and send the result via BibleSync to the mobile app. The ref parameter is not confined to a single reference. In normal citation syntax, the verse reference may consist of semicolon-separated references, comma-separated verses, and hyphen-separated ranges. Be aware that the specification has a relatively short limit on packet size, so that at most a few dozen references will be sent.

### Standard reference syntax
It is the responsibility of the application to transmit references in standard format. BibleSync neither validates nor converts the application's incoming bible, ref, and alt parameters. The specification references the BibleRef and OSIS specifications.

## SEE ALSO
http://biblesyncprotocol.wikispaces.com (user "General_Public", password "password"), http://semanticbible.com/bibleref/bibleref-specification.html, socket(2), setsockopt(2), select(2), recvfrom(2), sendto(2), and ip(7), especially sections on IP_ADD_MEMBERSHIP, IP_MULTICAST_IF, IP_MULTICAST_LOOP, and IP_MULTICAST_TTL.


rfcomm

package: bluez

title: rfcomm(7)

summary: RFCOMM protocol

text:
# rfcomm(7)

## Name
rfcomm - RFCOMM protocol

## SYNOPSIS

```
#include <sys/socket.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/rfcomm.h>
rfcomm_socket = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
```

## DESCRIPTION
The RFCOMM protocol provides emulation of serial ports over the L2CAP(7) protocol. The protocol is based on the ETSI standard TS 07.10.

RFCOMM is a simple transport protocol, with additional provisions for emulating the 9 circuits of RS-232 (EIATIA-232-E) serial ports.

## SOCKET ADDRESS

```
struct sockaddr_rc {

    sa_family_t rc_family;

    unsigned short rc_bdaddr;

    unsigned char rc_channel;
};
```

Example:

```
struct sockaddr_rc addr;
memset(&addr, 0, sizeof(addr));
addr.rc_family = AF_BLUETOOTH;
bacpy(&addr.rc_bdaddr, bdaddr);
addr.rc_channel = channel;
```

## SOCKET OPTIONS
The socket options listed below can be set by using setsockopt(2) and read with getsockopt(2) with the socket level set to SOL_BLUETOOTH.

### BT_SECURITY (since Linux 2.6.30)
Channel security level, possible values:

Value

Security Level

Link Key Type

Encryption

BT_SECURITY_SDP

0 (SDP Only)

None

Not required

BT_SECURITY_LOW

1 (Low)

Unauthenticated

Not required

BT_SECURITY_MEDIUM

2 (Medium - default)

Unauthenticated

Desired

BT_SECURITY_HIGH

3 (High)

Authenticated

Required

BT_SECURITY_FIPS (since Linux 3.15)

4 (Secure Only)

Authenticated (P-256 based Secure Simple Pairing and Secure Authentication)

Required

Example:

```
int level = BT_SECURITY_HIGH;
int err = setsockopt(rfcomm_socket, SOL_BLUETOOTH, BT_SECURITY, &level,

                     sizeof(level));
if (err == -1) {

    perror("setsockopt");

    return 1;
}
```

### BT_DEFER_SETUP (since Linux 2.6.30)
Channel defer connection setup, this control if the connection procedure needs to be authorized by userspace before responding which allows authorization at profile level, possible values:

Value

Description

Authorization

0

Disable (default)

Not required

1

Enable

Required

Example:

```
int defer_setup = 1;
int err = setsockopt(rfcomm_socket, SOL_BLUETOOTH, BT_DEFER_SETUP,

                     &defer_setup, sizeof(defer_setup));
if (err == -1) {

    perror("setsockopt");

    return err;
}
err = listen(rfcomm_socket, 5);
if (err) {

    perror("listen");

    return err;
}
struct sockaddr_rc remote_addr = {0};
socklen_t addr_len = sizeof(remote_addr);
int new_socket = accept(rfcomm_socket, (struct sockaddr*)&remote_addr,

                        &addr_len);
if (new_socket < 0) {

    perror("accept");

    return new_socket;
}
/* To complete the connection setup of new_socket read 1 byte */
char c;
struct pollfd pfd;
memset(&pfd, 0, sizeof(pfd));
pfd.fd = new_socket;
pfd.events = POLLOUT;
err = poll(&pfd, 1, 0);
if (err) {

    perror("poll");

    return err;
}
if (!(pfd.revents & POLLOUT)) {

    err = read(sk, &c, 1);

    if (err < 0) {

        perror("read");

        return err;

    }
}
```

### BT_FLUSHABLE (since Linux 2.6.39)
Channel flushable flag, this control if the channel data can be flushed or not, possible values:

Define

Value

Description

BT_FLUSHABLE_OFF

0x00 (default)

Do not flush data

BT_FLUSHABLE_ON

0x01

Flush data

### BT_CHANNEL_POLICY (since Linux 3.10)
High-speed (AMP) channel policy, possible values:

Define

Value

Description

BT_CHANNEL_POLICY_BREDR_ONLY

0 (default)

BR/EDR only

BT_CHANNEL_POLICY_BREDR_PREFERRED

1

BR/EDR Preferred

BT_CHANNEL_POLICY_BREDR_PREFERRED

2

AMP Preferred

### BT_PHY (since Linux 5.10)
Channel supported PHY(s), possible values:

Define

Value

Description

BT_PHY_BR_1M_1SLOT

BIT 0

BR 1Mbps 1SLOT

BT_PHY_BR_1M_3SLOT

BIT 1

BR 1Mbps 3SLOT

BT_PHY_BR_1M_5SLOT

BIT 2

BR 1Mbps 5SLOT

BT_PHY_BR_2M_1SLOT

BIT 3

EDR 2Mbps 1SLOT

BT_PHY_BR_2M_3SLOT

BIT 4

EDR 2Mbps 3SLOT

BT_PHY_BR_2M_5SLOT

BIT 5

EDR 2Mbps 5SLOT

BT_PHY_BR_3M_1SLOT

BIT 6

EDR 3Mbps 1SLOT

BT_PHY_BR_3M_3SLOT

BIT 7

EDR 3Mbps 3SLOT

BT_PHY_BR_3M_5SLOT

BIT 8

EDR 3Mbps 5SLOT

## RESOURCES
<http://www.bluez.org>

## REPORTING BUGS
<linux-bluetooth@vger.kernel.org>

## SEE ALSO
socket(7), rctest(1)

## Copyright
Free use of this software is granted under the terms of the GNU Lesser General Public Licenses (LGPL).

branch: sisyphus


bluealsa-plugins

package: bluez-alsa

title: bluealsa-plugins(7)

summary: Bluetooth Audio ALSA Plugins

text:
# bluealsa-plugins(7)

## Name
bluealsa-plugins - Bluetooth Audio ALSA Plugins

## DESCRIPTION
BlueALSA permits applications to access Bluetooth audio devices using the ALSA alsa-lib API. Users of those applications can then use Bluetooth speakers, headphones, headsets and hands-free devices much as if they were local devices. This integration is achieved by two ALSA plugins, one for PCM audio streams and one for CTL volume controls.

## PCM PLUGIN
The BlueALSA ALSA PCM plugin communicates with the bluealsa(8) service. It can be used to define ALSA PCMs in your own configuration file (e.g. ~/.asoundrc), or you can use the predefined bluealsa PCM.

### The Predefined bluealsa PCM
The simplest way to use the PCM plugin is with the predefined ALSA PCM device bluealsa. The definition of this PCM device is of type plug so audio format conversion, if required, is done automatically by the PCM. It has parameters DEV, PROFILE, CODEC, VOL, SOFTVOL, DELAY, and SRV. All these parameters have defaults. Parameter values in an ALSA PCM name are specified using the syntax:

```
bluealsa:DEV=01:23:45:67:89:AB,PROFILE=a2dp,CODEC=aac,VOL=60,SOFTVOL=no,DELAY=0,SRV=org.bluealsa
```

### PCM Parameters
DEV

The device Bluetooth address in the form XX:XX:XX:XX:XX:XX. Device names or aliases are not valid here. The default value is 00:00:00:00:00:00 which selects the most recently connected device of the chosen profile.

PROFILE

May be either a2dp or sco. sco selects either Hands-Free (HFP) or Headset (HSP) profile, whichever is connected on the selected device. The default is a2dp.

CODEC

Specifies the codec to be used by the profile. When a connection is established between a device and a host, BlueALSA negotiates the best available codec with the device; this parameter allows the ALSA configuration to override that selection. The default value is unchanged which causes the PCM to use its existing codec setting. The codec name is case insensitive; so for example aptX, aptx, and APTX are all accepted. If the specified codec is not available the plugin issues a warning and uses the default value instead. BlueALSA does not support changing the HFP codec from a HFP-HF node, only the HFP-AG node can change the HFP codec.

oFono does not permit the audio agent to select the codec, so this parameter has no effect when BlueALSA is used with oFono for HFP support.

For the A2DP profile it is possible to also specify a "configuration" for the codec by appending the configuration as a hex string separated from the codec name by a colon. The bits responsible for the number of channels and the sampling frequency are set by the plugin with the respect to options provided by the user (channel mode and sampling frequency bits act as a mask). For example:

```
CODEC=SBC:FC450240
```

This SBC configuration limits the channel mode options to mono and dual channel. So, in case of 2 channel audio stream, the plugin will negotiate the dual channel mode instead of default (if supported) joint stereo mode.

VOL

Specifies the initial volume for the PCM when opened. The default value is unchanged which causes the PCM to use its existing volume setting. The value is an integer percentage of the maximum volume [0-100]. The mute status can also be set by appending the character '-' to mute the sound or '+' to unmute it. The volume is not restored to its original value when the PCM is closed. For example to set the initial volume to 80% and ensure that mute is disabled for this PCM:

```
VOL=80+
```

SOFTVOL

Enables or disables BlueALSA's software volume feature for this PCM. See the bluealsa(8) manual page for more information on software volume. This is a boolean option (values on or off), but also accepts the special value unchanged which causes the PCM to use its existing softvol value. The default value is unchanged.

DELAY

An integer number which is added to the reported delay (latency) value in order to manually adjust the audio synchronization. It is not normally required and defaults to 0. See the EXT parameter of the CTL plugin in the CTL Parameters section below for a more flexible and convenient method of manually adjusting the reported delay by using a mixer control.

SRV

The D-Bus service name of the BlueALSA daemon. Defaults to org.bluealsa. See bluealsa(8) for more information. Not normally required.

### Setting Different Defaults
The defaults can be overridden by defining the ones you want to change in your own configuration (e.g. in ~/.asoundrc.conf) for example:

```
defaults.bluealsa.device "00:11:22:33:44:55"
defaults.bluealsa.profile "sco"
defaults.bluealsa.codec "cvsd"
defaults.bluealsa.volume "50+"
defaults.bluealsa.softvol off
defaults.bluealsa.delay 5000
defaults.bluealsa.service "org.bluealsa.source"
```

Note that volume takes a string value and so the default must be enclosed in quotation marks.

### Positional Parameters
ALSA permits arguments to be given as positional parameters as an alternative to explicitly naming them. When using positional parameters it is important that the values are given in the correct sequence - DEV, PROFILE, CODEC, VOL, SOFTVOL, DELAY, SRV. For example:

```
bluealsa:01:23:45:67:89:AB,a2dp,unchanged,unchanged,unchanged,0,org.bluealsa
```

When using positional parameters defaults can only be implied at the end of the id string, so

```
bluealsa:01:23:45:67:89:AB
```

is equivalent to the full form above, but

```
bluealsa:01:23:45:67:89:AB,a2dp,,80+
```

is not permitted.

### Defining BlueALSA PCMs
You can define your own ALSA PCM in the ALSA configuration. To do this, create an ALSA configuration node defining a PCM with type bluealsa. The configuration node has the following fields:

```
pcm.name {

  type bluealsa     # Bluetooth PCM

  device STR        # Device address in format XX:XX:XX:XX:XX:XX

  profile STR       # Profile type (a2dp or sco)

  [codec STR]       # Preferred codec

  [volume STR]      # Initial volume for this PCM

  [softvol BOOLEAN] # Enable/disable BlueALSA's software volume

  [delay INT]       # Extra delay (frames) to be reported (default 0)

  [service STR]     # DBus name of service (default org.bluealsa)
}
```

The device and profile fields must be specified so that the plugin can select the correct Bluetooth transport; the other fields are optional. Note that the default values for the optional fields are not overridden automatically by the configuration defaults.bluealsa.* in a PCM defined this way; however the configuration defaults can be referenced by use of @func refer (see the ALSA configuration file syntax documentation for more information).

When choosing a name for your PCM definition, the name pcm.bluealsa is predefined by the bluez-alsa installation (see section The Predefined bluealsa PCM above), so it should not be used as a name for your own PCM devices as doing so will most likely have unexpected or undesirable results.

Note that the volume field is of type string, so the value must be enclosed in double-quotes. See the PCM Parameters section above for more information on each field.

Do not confuse the PCM type bluealsa with the PCM named bluealsa. The type does not perform any audio conversions, you will have to wrap your own defined PCMs with type plug to achieve that; whereas the predefined PCM pcm.bluealsa is of type plug.

### Name Hints
Applications that follow ALSA guidelines will obtain the list of defined PCMs by using the alsa-lib namehints API. To make BlueALSA PCMs visible via that API it is necessary to add a "hint" section to the ALSA configuration. If you have defined a new PCM, then the hint goes into the PCM configuration entry as follows:

```
pcm.bt-headphones {

    type plug

    slave.pcm {

        type bluealsa

        device "00:11:22:33:44:55"

        profile "a2dp"

    }

    hint {

        show on

        description "My Bluetooth headphones"

    }
}
```

Now using aplay -L will include the following in its output:

```
# aplay -L
bt-headphones

    My Bluetooth headphones
#
```

If you are using the predefined bluealsa PCM, then you can create a "namehint" entry in your ~/.asoundrc file like this:

```
namehint.pcm {

    mybluealsadevice "bluealsa:DEV=00:11:22:33:44:55,PROFILE=a2dp|My Bluetooth headphones"
}
```

Then aplay -L shows

```
# aplay -L
bluealsa:DEV=00:11:22:33:44:55,PROFILE=a2dp

    My Bluetooth headphones
```

For alsa-lib versions before v1.2.3.2, a bug in the namehint parser means that a namehint.pcm entry has to be written as

```
namehint.pcm {

    mybluealsadevice "bluealsa:DEV=00:11:22:33:44:55,PROFILE=a2dp|DESCMy Bluetooth headphones"
}
```

(note the keyword DESC after the pipe symbol and before the description text.)

With that hint in place, the PCM will be listed as both a Capture and Playback device. So arecord -L will also list it. That is generally OK for HFP/HSP devices, but an A2DP device most often offers only Capture (e.g. a mobile phone) or only Playback (e.g. a Bluetooth speaker). It is possible to use the hint description to limit the listing to only one direction using an undocumented syntax of ALSA configuration files.

If the hint.description value ends with |IOIDInput the PCM will only show in listings of Capture devices; if it ends with |IOIDOutput the PCM will only show in listings of Playback devices.

So we can modify our example above to:

```
pcm.bt-headphones {

    type plug

    slave.pcm {

        type bluealsa

        device "00:11:22:33:44:55"

        profile "a2dp"

    }

    hint {

        show on

        description "My Bluetooth headphones|IOIDOutput"

    }
}
```

or

```
namehint.pcm {

    mybluealsadevice "bluealsa:DEV=00:11:22:33:44:55,PROFILE=a2dp|My Bluetooth headphones|IOIDOutput"
}
```

Now the aplay -L output will be exactly the same as before, but arecord -L will not include bt-headphones in its output.

When using the namehint.pcm method, the key (mybluealsadevice in the above example) must be unique but otherwise is not used. The first part of the value string, before the pipe | symbol, is the string that is to be passed to ALSA applications to identify the PCM (e.g. with aplay -D ...). The next section, after the pipe symbol, is the description that will be presented to the user. The optional |IOID section is not included in the description given to the application.

## CTL PLUGIN
The BlueALSA ALSA CTL plugin can be used to define ALSA CTLs (mixer devices) in your own configuration file (e.g. ~/.asoundrc), or you can use the predefined configuration that is included in the bluez-alsa project.

A BlueALSA CTL device has no associated soundcard, so alsamixer will not list it in its F6 menu. It can be selected either by starting alsamixer with

```
alsamixer -D bluealsa
```

or by selecting "enter device name .." on the F6 menu then typing out "bluealsa" in the "Device Name" box.

The CTL has two operating modes, Default mode and Single Device mode.

### Default Mode
In this mode when a device connects, the mixer will create new controls for it, and when a device disconnects, the mixer will remove its controls. alsamixer(1) will show these changes dynamically.

Control names are constructed by combining the device Bluetooth alias with either the profile type ('A2DP' or 'SCO') of the controlled PCM or the word "Battery" for battery level indicators. If two or more connected devices have the same alias then an index number is added to the name to make it unique.

The Bluetooth "alias" of a device is by default the same as its "name". The name is a string defined by the device manufacturer and embedded in its firmware. Typically two identical devices will have identical names. The "alias" is created by BlueZ and stored locally on the host computer. So the alias can be changed using a tool such as bluetoothctl(1) to make it unique if desired. As manufacturers tend to use long names for their devices the alias can also be useful to give a short "nickname" to a device.

Although this default mode works well with alsamixer, there are some limitations that may make it unsuitable for some applications. In particular:

- If device aliases are not unique then the index number associated with each is not easily predictable in advance; so it can be difficult to programmatically associate a PCM with its volume control.

- A consequence of the alsa-lib implementation of controls is that when one Bluetooth device connects or disconnects it is necessary to remove all controls from all devices in the mixer and create a new set. This invalidates pointers held by applications and can cause application crashes. (Hardware sound cards do not have randomly appearing and disappearing controls, so many, or even most, applications are not programmed correctly to deal with it.)

### Single Device Mode
The BlueALSA CTL also implements an alternative mode that presents controls only for one specified device. In this case the control names are simply the profile type of the controlled PCM ('A2DP' or 'SCO') or the word "Battery". There is never any need for index suffixes or device alias. Immediately this overcomes the two main issues of the default mode.

Single device mode is achieved by including the device Bluetooth address as an argument to the ALSA device id, for example:

```
alsamixer -D bluealsa:00:11:22:33:44:55
```

A notable difference between single-device mode and the default mode is in the cases of the device not being connected when the mixer is opened, and when the device disconnects while the mixer is open.

For the default mode, the mixer will still open, even if no devices are connected, but will display no controls. In single device mode the open request will fail with an error message.

Similarly, in default mode when a device disconnects the mixer remains open but removes the set of controls and creates a new control set without the disconnected device. That new set will be empty if no devices remain. If the device then re-connects the mixer will again create a new set of controls with the newly connected device included.

In single device mode when its device disconnects then the mixer will close. The alsamixer application will continue running with no associated device or controls, but will not automatically re-open the mixer if the device re-connects. The user can use F6 to open a new device.

As a special case, a single device mixer can be opened with the address 00:00:00:00:00:00. This will create a mixer with controls for the most recently connected device at the time the mixer is opened. Once created, that mixer behaves the same as if it had been opened with the actual address of the device: it does not change to a new device if another is subsequently connected.

### The Predefined bluealsa CTL
The bluealsa CTL has parameters DEV, EXT, BTT, DYN, and SRV. All the parameters have defaults.

### CTL Parameters
DEV

The device Bluetooth address in the form XX:XX:XX:XX:XX:XX. Device names or aliases are not valid here. The default value is FF:FF:FF:FF:FF:FF which selects controls from all connected devices (see Default Mode above). Also accepts the special address 00:00:00:00:00:00 which selects the most recently connected device.

EXT

Causes the plugin to include extra controls. These are the controls for Bluetooth codec selection, volume mode selection, delay adjustment (sync) and/or battery level indicator. If the value is yes then all of these additional controls are included; if the value is no then none of them are included. The default is no. This parameter can also select individual controls by using a colon (':') separated list of control names. The control names are codec, mode, sync and battery. For example:

```
EXT=codec
EXT=mode:battery
```

See Codec switching in the NOTES section below for more information on the codec selection control.

The volume mode controls take values "software" and "pass-through"; the playback control has index 0 and capture control has index 1. See the Volume control section in the bluealsa(8) for more information on the software volume setting.

The delay adjustment controls are called "Sync". They can be used to apply a fixed adjustment to the delay reported by the associated PCM to the application, and may be useful with applications that need to synchronize the bluetooth audio stream with some some other stream, such as a video. The values are in milliseconds from -3275 ms to +3275 ms in steps of 25 ms. The playback control has index 0 and the capture control has index 1. Each codec supported by a PCM has its own delay adjustment value. Note that this control changes only the delay value reported to the application by ALSA, it does not affect the actual delay (latency) of the PCM stream. Values set by this control type are saved in the BlueALSA persistent state files, and so are remembered and automatically applied each time the PCM is used.

The read-only battery level indicator will be shown only if the device supports battery level reporting.

BTT

Appends Bluetooth transport type (e.g. "-SNK" or "-HFP-AG") to the control element names. When using with the Default Mode this will reduce the number of available characters for Bluetooth device name, so the default value is no. In some rare circumstances, when more than one A2DP or HFP/HSP profile is connected with a single Bluetooth device, it might happen that the control element names for such device will not be unique. This might be problematic for control applications which use ALSA High Level Control Interface, e.g. amixer or alsamixer. Such applications will report error or simply crash. This can be avoided by setting the BTT parameter to yes.

DYN

Enables "dynamic" operation. The plugin will add and remove controls as profiles are connected or disconnected. This is the normal behavior, so the default value is "yes". This argument is ignored in default mode; in that mode operation is always dynamic. There are some applications that are not programmed to handle dynamic addition or removal of controls, and can fail when such events occur. Setting this argument to no in single device mode with such applications can protect them from such failures. When dynamic operation is disabled, the plugin never adds or removes any controls. If a single profile is disconnected, then its associated volume control is put into an inactive state, i.e.: read-only with its value and playback/capture switch set to 0.

SRV

The D-Bus service name of the BlueALSA daemon. Defaults to org.bluealsa. See bluealsa(8) for more information.

The default values can be overridden in the ALSA configuration, for example:

```
defaults.bluealsa.ctl.device "00:11:22:33:44:55"
defaults.bluealsa.ctl.bttransport "no"
defaults.bluealsa.ctl.dynamic "yes"
defaults.bluealsa.ctl.extended "no"
```

### Defining BlueALSA CTLs
You can define your own ALSA CTL in the ALSA configuration. To do this, create an ALSA configuration node defining a CTL with type bluealsa. The configuration node has the following fields:

```
ctl.name {

  type bluealsa     # Bluetooth PCM

  [device STR]      # Device address (default "FF:FF:FF:FF:FF:FF")

  [extended STR]    # Include additional controls (default no)

  [bttransport STR] # Append BT transport to element names (yes/no, default no)

  [dynamic STR]     # Enable dynamic operation (yes/no, default yes)

  [service STR]     # D-Bus name of service (default "org.bluealsa")
}
```

All the fields (except type) are optional. See the CTL Parameters section above for more information on each field. As for PCM definitions above, the default values for the optional fields are hard-coded into the plugin; they are not overridden by the configuration defaults.bluealsa. settings.

## NOTES

### Codec selection
When used on a HFP gateway node, there may be a brief delay with HFP PCMs after connection until the codec is selected. This delay is typically less than two seconds. During this time interval it is not possible to open the PCM plugin, it will fail with "Resource temporarily unavailable" (EAGAIN).

### Codec switching
Changing the codec used by a BlueALSA transport causes the PCM(s) running on that transport to terminate. Therefore using a Codec control can have undesirable consequences. Unfortunately the alsamixer(1) UI does not present a separate pick-list for enumerated types, so merely browsing the list of codecs using this control actually issues a Codec change request every time a different codec is displayed. This is not ideal, so the use of this control type with alsamixer(1) is not recommended. The control type does however work well with other mixer applications such as amixer(1).

Note that BlueALSA does not support changing the HFP codec from a HFP-HF node, only the HFP-AG node can change the HFP codec.

### Transport acquisition
The audio connection of a profile is not established immediately that a device connects. The A2DP source device, or HFP/HSP gateway device, must first "acquire" the profile transport.

When the BlueALSA PCM plugin is used on a source A2DP or gateway HFP/HSP node, then bluealsa(8) will automatically acquire the transport and begin audio transfer when the plugin starts the PCM.

When used on an A2DP sink or HFP/HSP HF/HS node then bluealsa(8) must wait for the remote device to acquire the transport. During this waiting time the PCM plugin behaves as if the device "clock" is stopped, it does not generate any poll() events, and the application will be blocked when writing or reading to/from the PCM. For applications playing audio from a file or recording audio to a file this is not normally an issue; but when streaming between some other device and a BlueALSA device this may lead to very large latency (delay) or trigger underruns or overruns in the other device.

### PCM drain and non-blocking operation
The BlueALSA PCM plugin does not support draining of capture PCMs. For a capture PCM snd_pcm_drain() has the same effect as snd_pcm_drop(). This is a limitation of the ALSA ioplug external plugin API.

For playback PCMs, BlueALSA has support for the drain operation in both blocking and non-blocking modes. In blocking mode the drain operation will wait until the BlueALSA server has played out the final audio frame. In non-blocking mode the plugin will inform the application of drain completion as soon as the ALSA ring buffer has been flushed; this means that some audio frames at the end of the stream may be lost in non-blocking mode as the PCM may stop before the server has had time to encode and play out all the frames.

## FILES
/etc/alsa/conf.d/20-bluealsa.conf

BlueALSA device configuration file. ALSA additional configuration, defines the bluealsa PCM and CTL devices.

## COPYRIGHT
Copyright (c) 2016-2023 Arkadiusz Bokowy.

The bluez-alsa project is licensed under the terms of the MIT license.

## SEE ALSO
alsamixer(1), amixer(1), aplay(1), bluetoothctl(1), bluealsa(8), bluetoothd(8)

Project web site

<https://github.com/arkq/bluez-alsa>

ALSA configuration file syntax

<https://www.alsa-project.org/alsa-doc/alsa-lib/conf.html>

ALSA built-in PCM plugins reference

<https://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html>


title: org.bluealsa.Manager1(7)

summary: Bluetooth Audio Manager D-Bus API

text:
# org.bluealsa.Manager1(7)

## Name
org.bluealsa.Manager1 - Bluetooth Audio Manager D-Bus API

## SYNOPSIS
Service

org.bluealsa[.unique ID]

Interface

org.bluealsa.Manager1

Object path

[variable prefix]/

## DESCRIPTION
This page describes the D-Bus Manager interface of the bluealsa(8) service. The Manager interface exposes some of the run-time properties of the service daemon.

### Properties
string Version [readonly]

Version of BlueALSA service.

array{string} Adapters [readonly]

Used HCI adapters. The device names ("hci0", etc.) of Bluetooth adapters that the BlueALSA service is using.

array{string} Profiles [readonly]

Used (enabled) Bluetooth profiles.

array{string} Codecs [readonly]

Used (enabled) Bluetooth audio codecs. The Bluetooth audio codec names are in the format: "<profile-name>:<codec-name>"

## COPYRIGHT
Copyright (c) 2016-2023 Arkadiusz Bokowy.

The bluez-alsa project is licensed under the terms of the MIT license.

## SEE ALSO
bluealsa-cli(1), bluealsa(8)

Project web site

<https://github.com/arkq/bluez-alsa>


title: org.bluealsa.PCM1(7)

summary: Bluetooth Audio PCM D-Bus API

text:
# org.bluealsa.PCM1(7)

## Name
org.bluealsa.PCM1 - Bluetooth Audio PCM D-Bus API

## SYNOPSIS
Service

org.bluealsa[.unique ID]

Interface

org.bluealsa.PCM1

Object path

[variable prefix]/{hci0,...}/dev_XX_XX_XX_XX_XX_XX/[type]/[mode]

## DESCRIPTION
This page describes the D-Bus PCM interface of the bluealsa(8) service. The PCM interface gives access to individual PCM objects created by this service.

### Methods
fd, fd Open()

Open BlueALSA PCM stream. This method returns two file descriptors, respectively PCM stream PIPE and PCM controller SEQPACKET socket. Controller socket commands: "Drain", "Drop", "Pause", "Resume"

Possible Errors:

```
dbus.Error.InvalidArguments
dbus.Error.NotSupported
dbus.Error.Failed
```

array{string, dict} GetCodecs()

Return the array of additional PCM codecs. Client can switch to one of these codecs with the SelectCodec() D-Bus method call. The dictionary may contain the following properties:

array{byte} Capabilities

A2DP codec capabilities blob.

array{byte} SupportedChannels

List of supported number of audio channels.

array{uint32} SupportedSampling

List of supported sampling frequency.

void SelectCodec(string codec, dict props)

Select PCM codec. This call shall be made before PCM stream opening for given transport type, otherwise the ongoing stream (or PCM counterpart: sink, source) will be terminated. For A2DP codecs, client can override built-in logic for selecting codec configuration by providing the configuration blob via the "Configuration" property. Provided configuration must be valid for given codec in respect to BlueALSA and peer device capabilities. Otherwise, the call will fail. It is possible to override this validation by setting the "NonConformant" property to true.

In case of codecs which support different number of audio channels or sampling frequencies, client can select the desired configuration by providing the "Channels" and "Sampling" properties respectively. These properties take precedence over the provided codec configuration.

Possible Errors:

```
dbus.Error.InvalidArguments
dbus.Error.NotSupported
dbus.Error.Failed
```

void SetDelayAdjustment(string codec, int16 adjustment)

Set an arbitrary adjustment (+/-) to the reported Delay in 1/10 of millisecond for a specific codec. This adjustment is applied to the Delay property when that codec is selected, and can be used to compensate for devices that do not report accurate Delay values. Possible Errors:

```
dbus.Error.InvalidArguments
```

array{string, int16} GetDelayAdjustments()

Return the array of currently set delay adjustments. Each entry of the array gives the name of a codec and the adjustment that the PCM will apply to the Delay property when that codec is selected.

### Properties
object Device [readonly]

BlueZ device object path.

uint32 Sequence [readonly]

This property indicates the sequence in which devices connected. The larger the value, the later the device was connected.

string Transport [readonly]

Underlying Bluetooth transport type. Possible values:

```
"A2DP-sink"
"A2DP-source"
"HFP-AG"
"HFP-HF"
"HSP-AG"
"HSP-HS"
```

string Mode [readonly]

PCM stream operation mode (direction). Possible values:

```
"sink"
"source"
```

boolean Running [readonly]

This property is true when the Bluetooth transport for this PCM is acquired and able to transfer audio samples.

uint16 Format [readonly]

Stream format identifier. The highest two bits of the 16-bit identifier determine the signedness and the endianness. Next 6 bits determine the physical width of a sample in bytes. The lowest 8 bits are used to store the actual sample bit-width. Examples:

```
0x4210 - unsigned 16-bit 2 bytes big-endian
0x8418 - signed 24-bit 4 bytes little-endian
```

byte Channels [readonly]

Number of audio channels.

uint32 Sampling [readonly]

Sampling frequency.

string Codec [readonly]

Bluetooth transport codec. This property is available only when transport codec is selected.

array{byte} CodecConfiguration [readonly]

Optional. Bluetooth transport codec configuration blob. This property is available only for transports which support codec configuration (e.g. A2DP).

uint16 Delay [readonly]

Approximate PCM delay in 1/10 of millisecond.

int16 DelayAdjustment [readonly]

An adjustment (+/-) included within the reported Delay in 1/10 of millisecond to compensate for devices that do not report accurate delay values.

boolean SoftVolume [readwrite]

This property determines whether BlueALSA will make volume control internally or will delegate this task to BlueALSA PCM client or connected Bluetooth device respectively for PCM sink or PCM source.

uint16 Volume [readwrite]

This property holds volume (loudness) value and mute information for channel 1 (left) and 2 (right). Data for channel 1 is stored in the upper byte, channel 2 is stored in the lower byte. The highest bit of both bytes determines whether channel is muted. Possible values:

```
A2DP: 0-127
SCO:  0-15
```

## COPYRIGHT
Copyright (c) 2016-2023 Arkadiusz Bokowy.

The bluez-alsa project is licensed under the terms of the MIT license.

## SEE ALSO
bluealsa-cli(1), bluealsa-plugins(5), bluealsa(8)

Project web site

<https://github.com/arkq/bluez-alsa>


title: org.bluealsa.RFCOMM1(7)

summary: Bluetooth Audio RFCOMM D-Bus API

text:
# org.bluealsa.RFCOMM1(7)

## Name
org.bluealsa.RFCOMM1 - Bluetooth Audio RFCOMM D-Bus API

## SYNOPSIS
Service

org.bluealsa[.unique ID]

Interface

org.bluealsa.RFCOMM1

Object path

[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/rfcomm

## DESCRIPTION
This page describes the D-Bus RFCOMM interface of the bluealsa(8) service. The RFCOMM interface gives access to the RFCOMM terminal objects created by this service.

### Methods
fd Open()

Open RFCOMM socket for dispatching AT commands not handled internally by BlueALSA. This method returns a SEQPACKET socket. Possible Errors:

```
dbus.Error.NotSupported
dbus.Error.Failed
```

### Properties
string Transport [readonly]

HFP/HSP transport type. Possible values: "HFP-AG", "HFP-HF", "HSP-AG" or "HSP-HS"

array{string} Features [readonly]

List of features supported by the remote device.

byte Battery [readonly]

Remote device battery level. Possible values: 0-100 or -1

## COPYRIGHT
Copyright (c) 2016-2023 Arkadiusz Bokowy.

The bluez-alsa project is licensed under the terms of the MIT license.

## SEE ALSO
bluealsa-rfcomm(1), bluealsa(8)

Project web site

<https://github.com/arkq/bluez-alsa>


bobcat

package: bobcat-doc

title: bobcat(7)

text:
# bobcat(7)

## NAME
Bobcat - Overview of classes in the Bobcat library

## DESCRIPTION
The classes of the Bobcat library may be used after including bobcat/classname in sources.

Generally, programs using the Bobcat library must be at least linked against the Bobcat library. Refer to section LINKING for more informatin about linking programs to required libraries.

All classes and other elements are defined in the FBB namespace. For some classes manipulators are available, which are defined in the FBB namespace. An overview of all manipulators defined in the FBB namespace is provided by man -e bobcat manipulators.

Beyond this section the section CATEGORIES groups classes that somehow belong together in various categories.

The following classes and functions are available:

FBB::Align: Specifies Table(Buf) column and element alignments.

(Manpage: man -e bobcat align)

FBB::Arg: Interfaces the command line arguments, allowing for short- and long options. The class is implemented as a Singleton.

(Manpage: man -e bobcat arg)

FBB::ArgConfig: Inherits from Arg and ConfigFile allowing for options to be specified as command line options and/or configuration file options. The class is implemented as a Singleton.

(Manpage: man -e bobcat argconfig)

FBB::A2x: Ascii-to-x conversions of any type supporting extractions from i[string]stream objects. (Manpage: man -e bobcat a2x)

FBB::BigInt: Wrapper class around the openssl BN_ functions for unlimited integer precision arithmetic.

(Manpage: man -e bobcat bigint)

FBB::binary_search: A modification of the STL binary_search algorithm returning the location of the searched value in a sorted series of values.

(Manpage: man -e bobcat binarysearch)

FBB::BinOps: A series of function templates implementing binary operators for classes that implement the matching binary assignment operators themselves.

(Manpage: man -e bobcat binops)

FBB::BinOpsBase: A class template implementing binary operators and compound assignment operators for classes that themselves implement swap members and members implementing the basic binary operation on objects of their class types themselves.

(Manpage: man -e bobcat binopsbase)

FBB::CerrExtractor: Executes child processes not expecting input but maybe writing its standard error stream.

(Manpage: man -e bobcat cerrextractor)

FBB::CGI: a class implementing the facilities accessing the data made available through the Common Gateway Interface.

(Manpage: man -e bobcat cgi)

FBB::Cidr: a class testing whether IP4 Internet addresses belong to address ranges defined by Classless Inter-Domain Routing (CIDR) address block specifications.

(Manpage: man -e bobcat cidr)

FBB::CinInserter: Executes child processes expecting input but not producing standard output.

(Manpage: man -e bobcat cininserter)

FBB::ClientSocket: a socket for tcp-communication with a server.

(Manpage: man -e bobcat clientsocket)

FBB::CmdFinder: Command-function associations.

(Manpage: man -e bobcat cmdfinder)

FBB::CmdFinderBase: Base class for CmdFinder.

(Manpage: man -e bobcat cmdfinderbase)

FBB::Config: Processing standard configuration files.

(Manpage: man -e bobcat config)

FBB::ConfigFile: Processing standard configuration files (deprecated, use Config).

(Manpage: man -e bobcat configfile)

FBB::CoutExtractor: Executes child processes not expecting input but maybe producing standard output.

(Manpage: man -e bobcat coutextractor)

FBB::CSVTable: Construct tables row-by-row.

(Manpage: man -e bobcat csvtable)

FBB::CSV4180: Objects of this class allow for easy handling of comma-separated values (implements RFC 4180).

(Manpage: man -e bobcat csv4180)

FBB::DateTime: Manipulations with date and time values.

(Manpage: man -e bobcat datetime)

FBB::DiffieHellman: Computing shared keys using the Diffie-Hellman algorithm.

(Manpage: man -e bobcat diffiehellman)

FBB::DigestBuf: Computing message digests.

(Manpage: man -e bobcat digestbuf)

FBB::ECDH: Computing shared keys using the elliptic curve based Diffie-Hellman algorithm.

(Manpage: man -e bobcat ecdh)

FBB::Eoi: std::streambuf offering the eoi manipulator.

(Manpage: man -e bobcat eoi)

FBB::Eoi: std::streambuf offering the eoi manipulator.

(Manpage: man -e bobcat eoi)

FBB::EoiBuf: std::streambuf offering the eoi manipulator and a configurable stream buffer.

(Manpage: man -e bobcat eoibuf)

FBB::Exception: objects of this class accept ostream insertions, and are also std::exception objects.

(Manpage: man -e bobcat exception)

FBB::Exec: Executes child processes not expecting input and not producing standard output.

(Manpage: man -e bobcat exec)

FBB::Field: class template retrieving and modifying position based fields in numbers using configurable number systems.

(Manpage: man -e bobcat field)

FBB::Flock: (Un)Locks access to a file allowing multiple programs to synchronize the use of the same data.

(Manpage: man -e bobcat flock)

FBB::Fork: Defines fork(2) as part of a Template Algorithm Design Pattern.

(Manpage: man -e bobcat fork)

FBB::GetHostent: Obtains hostent struct from hostname or -address.

(Manpage: man -e bobcat gethostent)

FBB::Glob: Obtain a list of files matching a certain pattern.

(Manpage: man -e bobcat glob)

FBB::HmacBuf: Computing HMAC message digests.

(Manpage: man -e bobcat hmacbuf)

FBB::Hostname: Derived from Hostent, allows the initialization from a std::string, or from an FBB::InetAddrress.

(Manpage: man -e bobcat hostname)

FBB::IBase64Stream: stream implementing base64 encoding and decoding, using a FBB::Base64Streambuf stream buffer.

(Manpage: man -e bobcat ibase64stream)

FBB::IBase64Buf: FBB::IFilterBuf specialization implementing base64 encoding and decoding.

(Manpage: man -e bobcat ibase64buf)

FBB::IFdStream/FBB::IFdStreamS: stream extracting information from a device whose file descriptor is available.

(Manpage: man -e bobcat ifdstream)

FBB::IFdBuf/FBB::IFdBufS: Input stream buffer initialized by a file descriptor.

(Manpage: man -e bobcat ifdbuf)

FBB::IFilterBuf: std::streambuf specialization implementing an std::istream filtering design pattern.

(Manpage: man -e bobcat ifilterbuf)

FBB::ImmapStream: stream extracting information from a file using mmap(2) to load the file’s data into memory.

(Manpage: man -e bobcat immapstream)

FBB::IOmmapStream: stream extracting information from and/or writing information to a file using mmap(2) to load the file’s data into memory.

(Manpage: man -e bobcat iommapstream)

FBB::Indent: Class and manipulators performing text indentation.

(Manpage: man -e bobcat indent)

FBB::InetAddress: Base class (no public constructor) for objects representing an internet address as used with sockets. Contains address and portnumbers.

(Manpage: man -e bobcat inetaddress)

FBB::IOStream: class combining std::istream and std::ostream features.

(Manpage: man -e bobcat iostream)

FBB::IOBuf: std::streambuf specialization allowing combined input and output operations.

(Manpage: man -e bobcat iobuf)

FBB::IQuotedPrintableStream: stream implementing quoted printable encoding and decoding, using a FBB::IQuotedPrintableBuf stream buffer.

(Manpage: man -e bobcat iquotedprintablestream)

FBB::IQuotedPrintableBuf: FBB::IFilterBuf specialization implementing quoted printable encoding and decoding.

(Manpage: man -e bobcat iquotedprintablebuf)

FBB::IRandStream: stream to extract random numbers from.

(Manpage: man -e bobcat irandstream)

FBB::ISymCryptStream: stream implementing symmetric encryption and decryption, using a FBB::ISymCryptStreambuf stream buffer.

(Manpage: man -e bobcat isymcryptstream)

FBB::ISymCryptStreambuf: FBB::IFilterBuf specialization implementing symmetric cryptography.

(Manpage: man -e bobcat isymcryptstreambuf)

FBB::Iterator: a class template creating a bidirectional iterator returning values of a specified type.

(Manpage: man -e bobcat iterator)

FBB::Hash...: Various class templates implementing mapping containers using hashing.

(Manpage: man -e bobcat hash)

FBB::Hostent: Wrapper around the hostent struct.

(Manpage: man -e bobcat hostent)

FBB::LDC: Large Digital Converter converts (large) values for various radices.

(Manpage: man -e bobcat ldc)

FBB::level: Manipulator setting the log-level of FBB::Log objects.

(Manpage: man -e bobcat level)

FBB::LinearMap: a class template container implementing a map using a linear search algorithm.

(Manpage: man -e bobcat linearmap)

FBB::lm: Manipulator setting the left margin of FBB::OFoldStream objects.

(Manpage: man -e bobcat lm)

FBB::LocalClientSocket: a Unix domain socket for tcp-communication with a Unix domain (local) server.

(Manpage: man -e bobcat localclientsocket)

FBB::LocalServerSocket: defines a Unix domain socket to which clients on the local host can connect.

(Manpage: man -e bobcat localserversocket)

FBB::LocalSocketBase: Base class for LocalClientSocket and LocalServerSocket.

(Manpage: man -e bobcat localsocketbase)

FBB::Log: std::ostream handling log messages.

(Manpage: man -e bobcat log)

FBB::LogBuf: std::streambuf handling log messages.

(Manpage: man -e bobcat logbuf)

FBB::MailHeaders: extracts mail headers from SMTP-email.

(Manpage: man -e bobcat mailheaders)

FBB::Manipulators: manipulators defined in the namespace FBB.

(Manpage: man -e bobcat manipulators)

FBB::Mbuf: std::streambuf specialization for inserting messages, mainly used by FBB::Mstream objects.

(Manpage: man -e bobcat mbuf)

FBB::Milter: interfaces the sendmail mail filter facilities.

(Manpage: man -e bobcat milter)

FBB::mlm: Manipulator modifying the left margin of FBB::OFoldStream objects.

(Manpage: man -e bobcat mlm)

FBB::MmapBuf: std::streambuf using mmap(2) to load the file’s data into memory.

(Manpage: man -e bobcat mmapbuf)

FBB::OmmapStream: stream writing information to a file using mmap(2) to load the file’s data into memory.

(Manpage: man -e bobcat ommapstream)

FBB::Mstream: Inserts messages into streams.

(Manpage: man -e bobcat mstream)

FBB::MultiBuf: std::streambuf specializations performing insertions to multiple std::ostream objects.

(Manpage: man -e bobcat multibuf)

FBB::OFdStream: stream inserting information into a device whose file descriptor is available.

(Manpage: man -e bobcat ofdstream)

FBB::OFdBuf: Output stream buffer initialized by a file descriptor.

(Manpage: man -e bobcat ofdbuf)

FBB::OFilterBuf: std::streambuf specialization implementing an std::ostream filtering design pattern.

(Manpage: man -e bobcat ofilterbuf)

FBB::OFoldStream: std::ostream using an OFoldBuf as its streambuf.

(Manpage: man -e bobcat ofoldstream)

FBB::OFoldBuf: OFilterBuf (std::streambuf) specialization folding text lines between left and right margins.

(Manpage: man -e bobcat ofoldbuf)

FBB::OHexBuf: OHexBuf (std::streambuf) specialization inserting characters into a stream by their hex values.

(Manpage: man -e bobcat ohexbuf)

FBB::OmmapStream: stream writing information to a file using mmap(2) to load the file’s data into memory.

(Manpage: man -e bobcat ommapstream)

FBB::OMutexStream: Mutex protected std::ostream.

(Manpage: man -e bobcat mxstream)

FBB::OneKey: Single keystroke input, not requiring `Return’.

(Manpage: man -e bobcat onekey)

FBB::OSymCryptStream: stream implementing symmetric encryption and decryption, using a FBB::OSymCryptStreambuf stream buffer.

(Manpage: man -e bobcat osymcryptstream)

FBB::OSymCryptStreambuf: streambuf derived from FBB::EoiBuf implementing symmetric cryptography.

(Manpage: man -e bobcat osymcryptstreambuf)

FBB::Pattern: Regular expression pattern matching.

(Manpage: man -e bobcat pattern)

FBB::Pipe: Defines a system level pipe.

(Manpage: man -e bobcat pipe)

FBB::PrimeFactors: Prime-number factorization of (BigInt) values.

(Manpage: man -e bobcat primefactors)

FBB::Process: Runs child processes, defining pipes between parents and child processes.

(Manpage: man -e bobcat process)

FBB::PtrIter: Input iterator whose dereferenced value returns a pointer rather than a reference to an element. Also offers: a ptrIter function template.

(Manpage: man -e bobcat ptriter)

FBB::RandBuf: implements a streambuf generating random numbers.

(Manpage: man -e bobcat randbuf)

FBB::RandomMt: class template generating random numbers.

(Manpage: man -e bobcat randommt)

FBB::Ranger: a class template creating ranges that are accepted by range-based for-loops. Also offered: a ranger function template.

(Manpage: man -e bobcat ranger)

FBB::ReadLineBuf: implements a streambuf using the Gnu readline library to allow editing an std::istream’s content.

(Manpage: man -e bobcat readlinebuf)

FBB::ReadLineHistory: provides access to the history of lines read from a ReadLineBuf.

(Manpage: man -e bobcat readlinehistory)

FBB::ReadLineStream: std::istream class using a ReadLineBuf for its std::streambuf.

(Manpage: man -e bobcat readlinestream)

FBB::Redirector: Defines system level file redirection.

(Manpage: man -e bobcat redirector)

FBB::repeat: Two short extensions of the STL for_each generic algorithm.

(Manpage: man -e bobcat repeat)

FBB::Reverse: a class template creating a reverse iterator returning values of a specified type.

(Manpage: man -e bobcat reverse)

FBB::Selector: Offers timed delays and multiple file I/O.

(Manpage: man -e bobcat selector)

FBB::Semaphore: Dijkstra’s (1962) Semaphore data type.

(Manpage: man -e bobcat semaphore)

FBB::ServerSocket: defines a socket to which clients can connect.

(Manpage: man -e bobcat serversocket)

FBB::Signal: Defines signals, allowing signal handlers to use object’s data members c.q. to call object’s members functions.

(Manpage: man -e bobcat signal)

FBB::SocketBase: Base class for ClientSocket and ServerSocket.

(Manpage: man -e bobcat socketbase)

FBB::Stat: Determines file characteristics.

(Manpage: man -e bobcat stat)

FBB::StdExtractor: Executes child processes not expecting input but maybe writing their standard output and error streams.

(Manpage: man -e bobcat stdextractor)

FBB::String: Offers extended std::string functionality.

(Manpage: man -e bobcat string)

FBB::StringLine: Offers operator>> extracting lines from std::istream objects.

(Manpage: man -e bobcat stringline)

FBB::SyslogBuf: streambuf to Buffer generating syslog(3) messages.

(Manpage: man -e bobcat syslogbuf)

FBB::SyslogStream: stream to Output stream inserting syslog(3) messages.

(Manpage: man -e bobcat syslogstream)

FBB::fswap: templates implementing memory bytes based swap functionality

(Manpage: man -e bobcat fswap)

FBB::Table: Display tables row- or column-wise.

(Manpage: man -e bobcat table)

FBB::TableBuf: Display tables row- or column-wise.

(Manpage: man -e bobcat tablebuf)

FBB::TableLines: Support class for the class Table(Buf).

(Manpage: man -e bobcat tablelines)

FBB::TableSupport: Support class for the class Table(Buf).

(Manpage: man -e bobcat tablesupport)

FBB::TempStream: Temporary fstream.

(Manpage: man -e bobcat tempstream)

FBB::Tty: Controls echoing of characters entered at the terminal.

(Manpage: man -e bobcat tty)

FBB::TypeTrait: Traits class template to determine various characteristics of types.

(Manpage: man -e bobcat typetrait)

FBB::User: Determines the current user’s parameters from /etc/passwd.

(Manpage: man -e bobcat user)

FBB::Xpointer: sets and retrieves the X-windows pointer.

(Manpage: man -e bobcat xpointer)

FBB::X2a: x-to-Ascii conversions of any type supporting insertions into o[string]stream objects.

(Manpage: man -e bobcat x2a)

## CATEGORIES
This section groups classes that somehow belong together. The following categories are offered:

o

COMMAND LINE INTERFACE AND CONFIGURATION FILES

o

CONVERSIONS

o

DATE AND TIME

o

ERRORS AND MESSAGE HANDLING

o

GENERIC ALGORITHM EXTENSIONS

o

INTERNET / NETWORKING

o

OPENSSL AND ENCRYPTION

o

PATTERN MATCHING

o

PROCESSES, SIGNALS, THREADS

o

STREAMS AND FILES

o

SHARED MEMORY

o

TABLES

o

VARIOUS TEMPLATES

o

VARIOUS OTHER CLASSES

o

COMMAND LINE INTERFACE AND CONFIGURATION FILES

FBB::Arg: Interfaces the command line arguments, allowing for short- and long options. The class is implemented as a Singleton.

(Manpage: man -e bobcat arg)

FBB::ArgConfig: Inherits from Arg and ConfigFile allowing for options to be specified as command line options and/or configuration file options. The class is implemented as a Singleton.

(Manpage: man -e bobcat argconfig)

FBB::CmdFinder: Command-function associations.

(Manpage: man -e bobcat cmdfinder)

FBB::CmdFinderBase: Base class for CmdFinder.

(Manpage: man -e bobcat cmdfinderbase)

FBB::Config: Processing standard configuration files.

(Manpage: man -e bobcat configfile)

FBB::ConfigFile: Processing standard configuration files (deprecated, use Config).

(Manpage: man -e bobcat configfile)

o

CONVERSIONS

FBB::A2x: Ascii-to-x conversions of any type supporting extractions from i[string]stream objects. (Manpage: man -e bobcat a2x)

FBB::BigInt: Wrapper class around the openssl BN_ functions for unlimited integer precision arithmetic.

(Manpage: man -e bobcat bigint)

FBB::CSV4180: Objects of this class allow easy handling of comma-separated values (implements RFC 4180).

(Manpage: man -e bobcat csv)

FBB::IBase64Stream: stream implementing base64 encoding and decoding, using a FBB::Base64Streambuf stream buffer.

(Manpage: man -e bobcat ibase64stream)

FBB::IBase64Buf: FBB::IFilterBuf specialization implementing base64 encoding and decoding.

(Manpage: man -e bobcat ibase64buf)

FBB::IQuotedPrintableStream: stream implementing quoted printable encoding and decoding, using a FBB::IQuotedPrintableBuf stream buffer.

(Manpage: man -e bobcat iquotedprintablestream)

FBB::IQuotedPrintableBuf: FBB::IFilterBuf specialization implementing quoted printable encoding and decoding.

(Manpage: man -e bobcat iquotedprintablebuf)

FBB::LDC: Large Digital Converter converts (large) values for various radices.

(Manpage: man -e bobcat ldc)

FBB::X2a: x-to-Ascii conversions of any type supporting insertions into o[string]stream objects.

(Manpage: man -e bobcat x2a)

o

DATE AND TIME

FBB::DateTime: Manipulations with date and time values.

(Manpage: man -e bobcat datetime)

o

ERRORS AND MESSAGE HANDLING

FBB::Exception: objects of this class accept ostream insertions, and are also std::exception objects.

(Manpage: man -e bobcat exception)

FBB::level: Manipulator setting the log-level of FBB::Log objects.

(Manpage: man -e bobcat level)

FBB::Log: std::ostream handling log messages.

(Manpage: man -e bobcat log)

FBB::LogBuf: std::streambuf handling log messages.

(Manpage: man -e bobcat logbuf)

FBB::SyslogBuf: streambuf to Buffer generating syslog(3) messages.

(Manpage: man -e bobcat syslogbuf)

FBB::SyslogStream: stream to Output stream inserting syslog(3) messages.

(Manpage: man -e bobcat syslogstream)

o

GENERIC ALGORITHM EXTENSIONS

FBB::binary_search: A modification of the STL binary_search algorithm returning the location of the searched value in a sorted series of values.

(Manpage: man -e bobcat binarysearch)

FBB::LinearMap: a class template container implementing a map using a linear search algorithm.

(Manpage: man -e bobcat linearmap)

FBB::repeat: Two short extensions of the STL for_each generic algorithm.

(Manpage: man -e bobcat repeat)

o

INTERNET / NETWORKING

FBB::CGI: a class implementing the facilities accessing the data made available through the Common Gateway Interface.

(Manpage: man -e bobcat cgi)

FBB::Cidr: a class testing whether IP4 Internet addresses belong to address ranges defined by Classless Inter-Domain Routing (CIDR) address block specifications.

(Manpage: man -e bobcat cidr)

FBB::ClientSocket: a socket for tcp-communication with a server.

(Manpage: man -e bobcat clientsocket)

FBB::GetHostent: Obtains hostent struct from hostname or -address.

(Manpage: man -e bobcat gethostent)

FBB::Hostname: Derived from Hostent, allows the initialization from a std::string, or from an FBB::InetAddrress.

(Manpage: man -e bobcat hostname)

FBB::InetAddress: Base class (no public constructor) for objects representing an internet address as used with sockets. Contains address and portnumbers.

(Manpage: man -e bobcat inetaddress)

FBB::Hostent: Wrapper around the hostent struct.

(Manpage: man -e bobcat hostent)

FBB::LocalClientSocket: a Unix domain socket for tcp-communication with a Unix domain (local) server.

(Manpage: man -e bobcat localclientsocket)

FBB::LocalServerSocket: defines a Unix domain socket to which clients on the local host can connect.

(Manpage: man -e bobcat localserversocket)

FBB::LocalSocketBase: Base class for LocalClientSocket and LocalServerSocket.

(Manpage: man -e bobcat localsocketbase)

FBB::MailHeaders: extracts mail headers from SMTP-email.

(Manpage: man -e bobcat mailheaders)

FBB::Milter: interfaces the sendmail mail filter facilities.

(Manpage: man -e bobcat milter)

FBB::ServerSocket: defines a socket to which clients can connect.

(Manpage: man -e bobcat serversocket)

FBB::SocketBase: Base class for ClientSocket and ServerSocket.

(Manpage: man -e bobcat socketbase)

o

OPENSSL AND ENCRYPTION

FBB::BigInt: Wrapper class around the openssl BN_ functions for unlimited integer precision arithmetic.

(Manpage: man -e bobcat bigint)

FBB::DiffieHellman: Computing shared keys using the Diffie-Hellman algorithm.

(Manpage: man -e bobcat diffiehellman)

FBB::DigestBuf: Computing message digests.

(Manpage: man -e bobcat digestbuf)

FBB::ECDH: Computing shared keys using the elliptic curve based Diffie-Hellman algorithm.

(Manpage: man -e bobcat ecdh)

FBB::HmacBuf: Computing HMAC message digests.

(Manpage: man -e bobcat hmacbuf)

FBB::ISymCryptStream: stream implementing symmetric encryption and decryption, using a FBB::ISymCryptStreambuf stream buffer.

(Manpage: man -e bobcat isymcryptstream)

FBB::ISymCryptStreambuf: FBB::IFilterBuf specialization implementing symmetric cryptography.

(Manpage: man -e bobcat isymcryptstreambuf)

FBB::OSymCryptStream: stream implementing symmetric encryption and decryption, using a FBB::OSymCryptStreambuf stream buffer.

(Manpage: man -e bobcat osymcryptstream)

FBB::OSymCryptStreambuf: streambuf derived from FBB::EoiBuf implementing symmetric cryptography.

(Manpage: man -e bobcat osymcryptstreambuf)

o

PATTERN MATCHING

FBB::Glob: Obtain a list of files matching a certain pattern.

(Manpage: man -e bobcat glob)

FBB::Pattern: Regular expression pattern matching.

(Manpage: man -e bobcat pattern)

o

PROCESSES, SIGNALS, THREADS

FBB::Exec: Executes child processes not expecting input and not producing standard output.

(Manpage: man -e bobcat exec)

FBB::CerrExtractor: Executes child processes not expecting input but maybe writing its standard error stream.

(Manpage: man -e bobcat cerrextractor)

FBB::CoutExtractor: Executes child processes not expecting input but maybe producing standard output.

(Manpage: man -e bobcat coutextractor)

FBB::Fork: Defines fork(2) as part of a Template Algorithm Design Pattern.

(Manpage: man -e bobcat fork)

FBB::CinInserter: Executes child processes expecting input but not producing standard output.

(Manpage: man -e bobcat cininserter)

FBB::Process: Runs child processes, defining pipes between parents and child processes.

(Manpage: man -e bobcat process)

FBB::Semaphore: Dijkstra’s (1962) Semaphore data type.

(Manpage: man -e bobcat semaphore)

FBB::Signal: Defines signals, allowing signal handlers to use object’s data members c.q. to call object’s members functions.

(Manpage: man -e bobcat signal)

FBB::StdExtractor: Executes child processes not expecting input but maybe writing their standard output and error streams.

(Manpage: man -e bobcat stdextractor)

o

STREAMS AND FILES

FBB::DigestBuf: Computing message digests.

(Manpage: man -e bobcat digestbuf)

FBB::Eoi: std::streambuf offering the eoi manipulator.

(Manpage: man -e bobcat eoi)

FBB::EoiBuf: std::streambuf offering the eoi manipulator and a configurable stream buffer.

(Manpage: man -e bobcat eoibuf)

FBB::Flock: (Un)Locks access to a file allowing multiple programs to synchronize the use of the same data.

(Manpage: man -e bobcat flock)

FBB::IFdStream/FBB::IFdStreamS: stream extracting information from a device whose file descriptor is available.

(Manpage: man -e bobcat ifdstream)

FBB::IFdBuf/FBB::IFdBufS: Input stream buffer initialized by a file descriptor.

(Manpage: man -e bobcat ifdbuf)

FBB::IFilterBuf: std::streambuf specialization implementing an std::istream filtering design pattern.

(Manpage: man -e bobcat ifilterbuf)

FBB::ImmapStream: stream extracting information from a file using mmap(2) to load the file’s data into memory.

(Manpage: man -e bobcat immapstream)

FBB::IOmmapStream: stream extracting information from and/or writing information to a file using mmap(2) to load the file’s data into memory.

(Manpage: man -e bobcat iommapstream)

FBB::IOStream: class combining std::istream and std::ostream features.

(Manpage: man -e bobcat iostream)

FBB::IOBuf: std::streambuf specialization allowing combined input and output operations.

(Manpage: man -e bobcat iobuf)

FBB::IRandStream: stream to extract random numbers from.

((Manpage: man -e bobcat irandstream))

FBB::lm: Manipulator setting the left margin of FBB::OFoldStream objects.

(Manpage: man -e bobcat lm)

FBB::Mbuf: std::streambuf specialization for inserting messages, mainly used by FBB::Mstream objects.

(Manpage: man -e bobcat mbuf)

FBB::MemoryAccess: Accesses shared memory data blocks.

(Manpage: man -e bobcat memoryaccess)

FBB::MemoryBridge: Pimpl/bridge Interface to shared memory data.

(Manpage: man -e bobcat memorybridge)

FBB::MemoryBuf: A std::streambuf specialization accessing bobcat’s shared memory data.

(Manpage: man -e bobcat memorybuf)

FBB::MemoryReadme: Overview of bobcat’s shared memory classes.

(Manpage: man -e bobcat memoryreadme)

FBB::MemoryStream: A std::ifstream specialization accessing bobcat’s shared memory data.

.

(Manpage: man -e bobcat memorystream)

FBB::mlm: Manipulator modifying the left margin of FBB::OFoldStream objects.

(Manpage: man -e bobcat mlm)

FBB::MmapBuf: std::streambuf using mmap(2) to load the file’s data into memory.

(Manpage: man -e bobcat mmapbuf)

FBB::Mstream: Inserts messages into streams.

(Manpage: man -e bobcat mstream)

FBB::MultiBuf: std::streambuf specializations performing insertions to multiple std::ostream objects.

(Manpage: man -e bobcat multibuf)

FBB::OFdStream: stream inserting information into a device whose file descriptor is available.

(Manpage: man -e bobcat ofdstream)

FBB::OFdBuf: Output stream buffer initialized by a file descriptor.

(Manpage: man -e bobcat ofdbuf)

FBB::OFilterBuf: std::streambuf specialization implementing an std::ostream filtering design pattern.

(Manpage: man -e bobcat ofilterbuf)

FBB::OFoldStream: std::ostream using an OFoldBuf as its streambuf.

(Manpage: man -e bobcat ofoldstream)

FBB::OFoldBuf: OFilterBuf (std::streambuf) specialization folding text lines between left and right margins.

(Manpage: man -e bobcat ofoldbuf)

FBB::OHexBuf: OHexBuf (std::streambuf) specialization inserting characters into a stream by their hex values.

(Manpage: man -e bobcat ohexbuf)

FBB::OmmapStream: stream writing information to a file using mmap(2) to load the file’s data into memory.

FBB::OMutexStream: Mutex protected std::ostream.

(Manpage: man -e bobcat mxstream)

FBB::Pipe: Defines a system level pipe.

(Manpage: man -e bobcat pipe)

FBB::RandBuf: implements a streambuf generating random numbers.

(Manpage: man -e bobcat randbuf)

FBB::RandomMt: class template generating random numbers.

(Manpage: man -e bobcat randommt)

FBB::ReadLineBuf: implements a streambuf using the Gnu readline library to allow editing an std::istream’s content.

(Manpage: man -e bobcat readlinebuf)

FBB::ReadLineHistory: provides access to the history of lines read from a ReadLineBuf.

(Manpage: man -e bobcat readlinehistory)

FBB::ReadLineStream: std::istream class using a ReadLineBuf for its std::streambuf.

(Manpage: man -e bobcat readlinestream)

FBB::Redirector: Defines system level file redirection.

(Manpage: man -e bobcat redirector)

FBB::Selector: Offers timed delays and multiple file I/O.

(Manpage: man -e bobcat selector)

FBB::Stat: Determines file characteristics.

(Manpage: man -e bobcat stat)

FBB::TempStream: Temporary fstream.

(Manpage: man -e bobcat tempstream)

o

SHARED MEMORY

FBB::MemoryAccess: Accesses shared memory data blocks.

(Manpage: man -e bobcat memoryaccess)

FBB::MemoryBridge: Pimpl/bridge Interface to shared memory data.

(Manpage: man -e bobcat memorybridge)

FBB::MemoryBuf: A std::streambuf specialization accessing bobcat’s shared memory data.

(Manpage: man -e bobcat memorybuf)

FBB::MemoryReadme: Overview of bobcat’s shared memory classes.

(Manpage: man -e bobcat memoryreadme)

FBB::MemoryStream: A std::ifstream specialization accessing bobcat’s shared memory data.

.

(Manpage: man -e bobcat memorystream)

o

TABLES

FBB::Align: Specifies Table(Buf) column and element alignments.

(Manpage: man -e bobcat align)

FBB::CSVTable: Construct tables row-by-row.

(Manpage: man -e bobcat csvtable)

FBB::Table: Display tables row- or column-wise.

(Manpage: man -e bobcat table)

FBB::TableBuf: Display tables row- or column-wise.

(Manpage: man -e bobcat tablebuf)

FBB::TableLines: Support class for the class Table(Buf).

(Manpage: man -e bobcat tablelines)

FBB::TableSupport: Support class for the class Table(Buf).

(Manpage: man -e bobcat tablesupport)

o

VARIOUS TEMPLATES

FBB::binary_search: A modification of the STL binary_search algorithm returning the location of the searched value in a sorted series of values.

(Manpage: man -e bobcat binarysearch)

FBB::BinOps: A series of function templates implementing binary operators for classes that implement the matching binary assignment operators themselves.

(Manpage: man -e bobcat binops)

FBB::BinOpsBase: A class template implementing binary operators and compound assignment operators for classes that themselves implement swap members and members implementing the basic binary operation on objects of their class types themselves.

(Manpage: man -e bobcat binopsbase)

FBB::Field: class template retrieving and modifying position based fields in numbers using configurable number systems.

(Manpage: man -e bobcat field)

FBB::fswap: templates implementing memory bytes based swap functionality

(Manpage: man -e bobcat fswap)

FBB::Hash...: Various class templates implementing mapping containers using hashing.

(Manpage: man -e bobcat hash)

FBB::Iterator: a class template creating a bidirectional iterator returning values of a specified type.

(Manpage: man -e bobcat iterator)

FBB::LinearMap: a class template container implementing a map using a linear search algorithm.

(Manpage: man -e bobcat linearmap)

FBB::PtrIter: Input iterator whose dereferenced value returns a pointer rather than a reference to an element. Also offers: a ptrIter function template.

(Manpage: man -e bobcat ptriter)

FBB::Ranger: a class template creating ranges that are accepted by range-based for-loops. Also offered: a ranger function template.

(Manpage: man -e bobcat ranger)

FBB::repeat: Two short extensions of the STL for_each generic algorithm.

(Manpage: man -e bobcat repeat)

FBB::Reverse: a class template creating a reverse iterator returning values of a specified type.

(Manpage: man -e bobcat reverse)

FBB::TypeTrait: Traits class template to determine various characteristics of types.

(Manpage: man -e bobcat typetrait)

o

VARIOUS OTHER CLASSES

FBB::CSV: Objects of this class allow easy handling of comma-separated values.

(Manpage: man -e bobcat csv)

FBB::Indent: Class and manipulators performing text indentation.

(Manpage: man -e bobcat indent)

FBB::Manipulators: manipulators defined in the namespace FBB.

(Manpage: man -e bobcat manipulators)

FBB::OneKey: Single keystroke input, not requiring `Return’.

(Manpage: man -e bobcat onekey)

FBB::PrimeFactors: Pprime-number factorization of (BigInt) values.

(Manpage: man -e bobcat primefactors)

FBB::String: Offers extended std::string functionality.

(Manpage: man -e bobcat string)

FBB::StringLine: Offers operator>> extracting lines from std::istream objects.

(Manpage: man -e bobcat stringline)

FBB::Tty: Controls echoing of characters entered at the terminal.

(Manpage: man -e bobcat tty)

FBB::User: Determines the current user’s parameters from /etc/passwd.

(Manpage: man -e bobcat user)

FBB::Xpointer: sets and retrieves the X-windows pointer.

(Manpage: man -e bobcat xpointer)

## LINKING
To link programs against the shared Bobcat library (e.g., libbobcat6.so) it is usually sufficient to merely specify -lbobcat. E.g.,

```
    g++ --std=c++2a main.cc -lbobcat

```

Note: libraries that are indirectly required are no longer automatically linked to your program. With some classes (e.g., BigInt) the libcrypto library must also be specified, and programs using such classes must be linked against bobcat and crypto:

```
    g++ --std=c++2a main.cc -lbobcat -lcrypto

```

Man-pages of classes requiring additional libraries mention these additional libraries in their SYNOPSIS sections. When using static linking, the situation is slightly more problematic, and no general rule can be provided here. To create a statically linked program the flag -static must be provided, but in addition the -pthread flag must often be specified as well. If, when statically linking your program, undefined references to pthread_... identifiers are reported, then that is a sure sign that you need to provide the -pthread flag as well.

When using static linking additional libraries, not specified at the man-pages, may also be required. E.g., when using the Xpointer class and using static linking, the command becomes:

```
    g++  main.cc -static -pthread -lbobcat -lX11 -lxcb  -lXdmcp -lXau

```

When encountering undefined references when using static linking missing libraries may be suggested by the linker or by its error messages. Alternatively, the missing libraries may be found by searching the Internet.

## FILES
o

/usr/include/bobcat/<classname>:

o

/usr/lib/libbobcat.*:

(shared, static libraries)

## SEE ALSO
The individual bobcat/3<class> header files, with man-pages accessible using man -e bobcat class (all lowercase names)

## BUGS
No Reported Bugs.

## BOBCAT PROJECT FILES
o

https://fbb-git.gitlab.io/bobcat/: gitlab project page;

Debian Bobcat project files:

o

libbobcat6: debian package containing the shared library, changelog and copyright note;

o

libbobcat-dev: debian package containing the static library, headers, manual pages, and developer info;

## BOBCAT
Bobcat is an acronym of `Brokken’s Own Base Classes And Templates’.

## COPYRIGHT
This is free software, distributed under the terms of the GNU General Public License (GPL).

## AUTHOR
Frank B. Brokken (f.b.brokken@rug.nl).


memoryreadme

title: memoryreadme(7bobcat)

summary: Bobcat\(cqs classes accessing memory segments

text:
# memoryreadme(7bobcat)

## NAME
MemoryREADME - Bobcat’s classes accessing memory segments

## DESCRIPTION
The following classes accessing memory segments are available:

o

MemoryAccess(3bobcat)

The class MemoryAccess(3bobcat) defines an object interfacing to a shared memory segment (cf. shmget(2)). If offers functionality to set and retrieve its id, and write and read bytes from its shared memory segment. MemoryAccess objects are used by MemoryBridge(3bobcat) objects keeping track of which segments actually contain the data bytes.

MemoryAccess objects are used by MemoryBridge and are normally not directly constructed by user programs.

o

MemoryBridge(3bobcat)

The class MemoryBridge (cf. figure images/sharedsegment1.jpg) interfaces to shared memory using MemoryAccess objects. Its main member function is the static member create, returning a pointer to a newly allocated MemoryMemory object.

The member create receives as its input parameters the number of blocks, the size of the segments allocated by MemoryBridge, and the segment’s access mode (as used by, e.g., chmod(1)). It returns a pointer to the allocated MemoryBridge, and its ID (set using a pointer to an int, passed as its first parameter).

Although the MemoryBridge class defines an array of a single MemoryAccess(3bobcat) object, in fact it will contain d_nAccesss MemoryAccess objects. The member create first allocates a block of raw memory of the required total size. Next it initializes the first part of this raw, shared memory, using the MemoryBridge constructor and placement new. Next, the remaining amount of raw shared memory is initialized with d_nAccesss - 1 MemoryAccess objects, again using placement new (cf. figure images/sharedsegment2.jpg in the source distribution).

Following read/write operations the offset is updated accordingly. There’s only one offset, which is used by [IO]?MemoryStream objects when requesting or updating offsets. a MemoryMemory object offers safeguards against inappropriate use. E.g., if no memory has been allocated yet it may thow exceptions. Also, offsets can never exceed the MemoryMemory’s maximum possible offset.

o

MemoryBuf(3bobcat)

The class MemoryBuf implements a std::streambuf specialization interfacing to a MemoryMemory object. In addition to a default constructor which is an empty stub the class offers constructors which immediately interface to a MemoryBridge object.

o

MemoryStream(3bobcat)

The MemoryStream class offers stream-facilities operating on shared memory maintained by a MemoryBuf object.

An overview of currently defined shared memory segments is shown by the command ipcs -ma. To erase a defined shared memory segment the command ipcrm -m <id> can be used, where <id> is the shared memory segment’s ID.

## EXAMPLE
See the memorystream(3bobcat) man page.

## FILES
Images referred to in this man-page are located in the source distribution in bobcat/documents/images, or they can be found in the standard location of documentation files in your distribution (e.g., they are located in /usr/share/doc/libbobcat6/images).

## SEE ALSO
bobcat(7), ipcs(1), ipcrm(1), memoryaccess(3bobcat), memorybridge(3bobcat), memorybuf(3bobcat), memorystream(3bobcat)

## BUGS
None Reported.

## BOBCAT PROJECT FILES
o

https://fbb-git.gitlab.io/bobcat/: gitlab project page;

Debian Bobcat project files:

o

libbobcat6: debian package containing the shared library, changelog and copyright note;

o

libbobcat-dev: debian package containing the static library, headers, manual pages, and developer info;

## BOBCAT
Bobcat is an acronym of `Brokken’s Own Base Classes And Templates’.

## COPYRIGHT
This is free software, distributed under the terms of the GNU General Public License (GPL).

## AUTHOR
Frank B. Brokken (f.b.brokken@rug.nl).


calf

package: calf

title: calf(7)

summary: audio plugin library

text:
# calf(7)

## NAME
Calf_Studio_Gear - audio plugin library

## SYNOPSIS
calfjackhost plugin ! [ plugin ! ] [...]

## DESCRIPTION
The Calf project aims at providing a set of high quality open source audio plugins for musicians which can be used as LV2 plug-ins or standalone.

Currently available plugins:

* Instruments and Tone Generators:

Organ, Monosynth, Fluidsynth, Wavetable

* Modulation Effects:

Multi Chorus, Phaser, Flanger, Rotary Speaker, Pulsator, Ring Modulator

* Delay Effects:

Reverb, Vintage Delay, Compensation Delay Line, Reverse Delay (experimental)

* Dynamic Processors:

Compressor, Sidechain Compressor, Multiband Compressor, Deesser, Gate, Sidechain Gate, Multiband Gate, Limiter, Multiband Limiter, Sidechain Limiter, Transient Designer

* Filters and Equalizers:

Filter, Filterclavier, Envelope Filter, Emphasis, Vocoder, Equalizer 5 Band, Equalizer 8 Band, Equalizer 12 Band, Equalizer 30 Band

* Distortion and Enhancement:

Saturator, Exciter, Bass Enhancer, Tape Simulator, Vinyl, Crusher

* Tools:

Mono Input, Stereo Tools, Bass Stereo Enhancer, Multi Spread, X-Over 2 Band, X-Over 3 Band, X-Over 4 Band

## OPTIONS
How to use Calf plugins:

* LV2 plugins

Calf is installed as calf.lv2 library in your LV2 directory (typically /usr/lib/lv2). It means that typical LV2 hosts should be able to find Calf's plugins.

* JACK client application

You can also use Calf plugins as one or more separate applications, connecting to other applications using JACK Audio Connection Kit (version 0.103 or newer is required). To run the client, type:

calfjackhost monosynth !

(! means "connect", last "!" means "connect to output")

Other examples:

calfjackhost monosynth ! vintagedelay ! flanger !

(runs monosynth into vintagedelay and vintagedelay into flanger, then to output)

calfjackhost ! reverb !

(takes signal from system:capture_1 and _2, puts it through reverb, and then sends to system:playback_1 and _2)

## SEE ALSO
calfjackhost(1)

## AUTHOR
Krzysztof Foltman, Markus Schmidt, Christian Holschuh, Thor Harald Johansen, Damien Zammit, Tom Szilagyi, Hans Baier and others

Website: http://calf.sourceforge.net/


ccze-plugin

package: ccze

title: ccze-plugin(7)

text:
# ccze-plugin(7)

## NAME
ccze - A robust log colorizer, plugin infrastructure

## SYNOPSIS
\#include <ccze.h>

/* Plugin support */

typedef void (*ccze_plugin_startup_t) (void);

typedef void (*ccze_plugin_shutdown_t) (void);

typedef int (*ccze_plugin_handle_t) (const char *str, size_t length, char **rest);

CCZE_DEFINE_PLUGIN (name, type, desc);

CCZE_DEFINE_PLUGINS (plugins...);

/* Display */

void ccze_addstr (ccze_color_t col, const char *str);

void ccze_newline (void);

void ccze_space (void);

void ccze_wordcolor_process_one (char *word, int slookup);

/* Helpers */

ccze_color_t ccze_http_action (const char *method);

void ccze_print_date (const char *date);

/* Command line */

char **ccze_plugin_argv_get (const char *name);

const char *ccze_plugin_name_get (void);

## DESCRIPTION
This manual page attempts to outline the internals of CCZE plugins: how they work, how they are implemented, and how to add new ones.

There are four required entry points in a plugin: a startup, a shutdown and a handler routine (more on these later), and an informational structure.

The startup function must be of type ccze_plugin_startup_t. This is called right after the module is loaded. Its purpose is to initialise all kinds of module-specific global variables, such as the regular expressions.

The shutdown function is its counterpart: this is used to deallocate any memory reserved by the startup code.

The core part of a plugin is the handler, of type ccze_plugin_handle_t. This does the actual coloring. The string to process is passed in the str argument, its length in length. The third argument, rest is a pointer to a string. Unlike the first two, this argument is used only for output.

When a handler processed a string, it must return a non-zero value, in case it could not process it, the handler must return with zero. If the string could be processed only partially, the part which was deemed unknown by the handler must be passed back in the rest variable.

The fourth part, although the smallest part, is the most important. Without this, the module is useless, it cannot be loaded. This part tells CCZE what the startup, shutdown and handler functions are called.

To encourage good style, the little details of this structure will not be disclosed in this manual page. Instead, the helper macro, CCZE_DEFINE_PLUGIN will be explained.

CCZE_DEFINE_PLUGIN is the macro to use if one wants to make the plugin loadable. Its first argument is an unquoted string: the name of the plugin. The second part is the type of the plugin, it can be FULL, PARTIAL or ANY. The last argument is a short description of the plugin.

It is assumed that the three functions mentioned earlier are called ccze_name_setup, ccze_name_shutdown and ccze_name_handle, respectively.

A FULL plugin is one that accepts raw input, untouched by any other plugin before, and processes it. On the other hand, a PARTIAL plugin relies on previous ones preprocessing the input. For example, syslog is a full plugin, on which ulogd, a partial plugin relies. The syslog plugin processes the raw input from the logfile, adds colour to most of it, save the actual message sent by a process, that is left to subsequent plugins, like ulogd. An ANY plugin is one can act as both other types.

With CCZE_DEFINE_PLUGINS one can place more than one plugin into one shared object.

There are two other helper functions, ccze_plugin_argv_get and ccze_plugin_name_get. One can pass arguments to CCZE plugins, and these is the function to retrieve them. While ccze_plugin_name_get returns the name of the current plugin, ccze_plugin_argv_get returns a NULL-terminated array, with each entry containing an argument.

## DISPLAY METHODS
The so-called display methods are the only supported interface to emit something to the display. These handle both the normal, ncurses-based, and the HTML output. This is a kind of abstraction so plugins will not have to worry about the differences between the output formats.

The most important one is ccze_addstr, which takes a color (see ccze.h for a list of supported color tags) and a string, and displays it appropriately. The ccze_space and ccze_newline functions emit a space and a newline, respectively.

Our last function, ccze_wordcolor_process_one passes word to the word colourising engine. If the second argument, slookup is non-zero, the engine will perform service lookups (like getent and friends).

## HELPER METHODS
We only have two helper methods: ccze_print_date, which simply prints out the date in the appropriate colour, and ccze_http_action, which given a HTTP method, returns the associated colour, in a format suitable for ccze_addstr.

## EXAMPLE

```
#include <ccze.h>
#include <stddef.h>
#include <string.h>
static char **ccze_foo_argv;
static int
ccze_foo_handle (const char *str, size_t length, char **rest)
{

  int i = 1;

  if (strstr (str, "foo"))

    {

      ccze_addstr (CCZE_COLOR_GOODWORD, str);

      return 1;

    }

  while (ccze_foo_argv[i])

    {

      if (strstr (str, ccze_foo_argv[i]))

        {

          ccze_addstr (CCZE_COLOR_GOODWORD, str);

          return 1;

        }

      i++;

    }

  return 0;
}
static void
ccze_foo_startup (void)
{

  ccze_foo_argv = ccze_plugin_argv_get (ccze_plugin_name_get ());
}
static void
ccze_foo_shutdown (void)
{
}
CCZE_DEFINE_PLUGIN (foo, PARTIAL, "Partial FOO coloriser.");
```

## SEE ALSO
ccze(1)

## AUTHOR
ccze was written by Gergely Nagy <algernon@bonehunter.rulez.org>, based on colorize by Istvan Karaszi <colorize@spam.raszi.hu>.