dxd - dynax driver framework 3.0.1f223
cross platform open source driver development framework
Loading...
Searching...
No Matches
Class Hierarchy

Go to the graphical class hierarchy

This inheritance list is sorted roughly, but not completely, alphabetically:
[detail level 123456]
C__map
C__number
C_desc_t
C_device_t
C_preference
C_super_device_t
CASIOTime
CAudioObjectPropertyAddress
CAudioServerPlugInDriverInterface
Cbase_t
Cbus_t
 Ccf::__string< cf_object_t >::lessOrdering a ::CFStringRef key needs in an std::map - comparing the strings, not the pointers
 Ccf::_preference::property
 Ccf::array< cf_array_t, cf_basetype_t >
Ccf::array<::CFArrayRef, ::CFMutableArrayRef >
 Ccf::dictionary< cf_dictionary_t, cf_basetype_t >Key value pair store
Ccf::dictionary<::CFDictionaryRef, ::CFMutableDictionaryRef >
 Ccf::interface< interface_t >COM style IOKit plugin interface: QueryInterface on the plugin (or on an io_object_t, which is opened as a plugin first) and the release at the end of the object's life - every IOUSBLib and IOCFPlugIn interface is reached through one
 Ccf::interface<::IOCFPlugInInterface >
Ccf::interface<::IOUSBDeviceInterface650 >
Ccf::interface<::IOUSBInterfaceInterface650 >
Ccf::reference< cf_object_t >
Ccf::reference< ::CFMutableStringRef >
Ccf::reference< ::CFStringRef >
Ccf::reference< ::CFTypeRef >
Ccf::reference< item_t >
Ccf::reference<::CFBundleRef >
Ccf::reference<::CFDataRef >
Ccf::reference<::CFErrorRef >
Ccf::reference<::CFPropertyListRef >
Ccf::reference<::CFReadStreamRef >
Ccf::reference<::CFRunLoopSourceRef >
Ccf::reference<::CFTypeRef >
Ccf::reference<::CFURLRef >
Ccf::reference<::CFUUIDRef >
Ccf::reference<::SCPreferencesRef >
Ccf::reference<::SecCertificateRef >
Ccf::reference<::SecRequirementRef >
Ccf::reference<::SecTrustRef >
 Ccf::tree< derived_t >Dx::key_value_tree<derived_t> contract (dxd/interface/dx_key_value_tree.h), implemented once for every CF-backed preference store (cf::_preference, sc::_preference, dx::coreaudio::server::_preference) - inherit from this (CRTP: class _preference: public cf::tree<_preference>) instead of reimplementing it
Ccf::tree< _preference >
 Ccf::type< type_t, enable_t >
 Ccf::type< bool >Boolean is no ::CFNumber but one of the two ::kCFBoolean singletons, so this one carries no reference of its own
Ccontrol< object< device< desc, preference, stream > > >
Ccontrol< object< device_t > >
Ccrypt::certificateCryptoAPI certificate context, reference counted
 Ccrypt::storeSystem certificate store by name and location, read only
CCUnknown
Cdesc_t
Cdevice::desc::stream::desc
Cdevice_t
Cdevice_t::desc::stream::desc
Cdevice_t::desc::stream::pin::desc
Cdevice_t::ring
Cdriver_t
Cdx::abstract::eventCounting event every scope implements: a signal raises the count, a wait takes one (or resets the count where the waiter serves them all at once)
 Cdx::aggregate< types >Forwards a braced argument list into a type with no matching constructor - the conversion builds it from the stored tuple, so an aggregate can be returned or passed where its own members would not deduce
 Cdx::ansiSGR/OSC control sequence, written only where it is read: every sink below drops it unless stderr is a terminal
 Cdx::apartment< object_t, model >COM apartment of one object - a device or a whole driver: its thread creates the object, runs its steps and releases it
 Cdx::asio::client::_device< desc_t, preference_t, stream_t, group_t >::asioSDK driver this device is, opened off a list of its own: its id holds however the registry moves
Cdx::asio::client::callbacksWhat an ASIO driver calls back into its host: the buffer switch and the driver's own notifications. The comments are the SDK's own description of the contract
 Cdx::asio::client::driver< device_t, devices >::property
 Cdx::asio::client::targetASIO stream's whole hardware identity: its direction - an ASIO driver offers one input and one output side, whatever the device behind it has
 Cdx::asio::driver< device_t, driver_t >::pauseSession stopped for the scope and started again at its end, where a host's request needs the driver still
 Cdx::asio::driver< device_t, driver_t >::property
Cdx::circularKernel/user space shared circular buffer
 Cdx::circular::[struct].cycle
 Cdx::circular::channel< dst_t, src_t >Copy/mix channel converters
 Cdx::circular::channel< dst_t, src_t >Same width, or floating point on both sides: the sample moves as it stands
 Cdx::circular::interlocked< dst_t >Compare-exchange returning the prior value regardless of outcome (WIN32 Interlocked* semantics)
 Cdx::coreaudio::__targetSame layout with named members, so a target can be written with designated initializers
 Cdx::coreaudio::driver< device_t >::propertyThis bus's name in the device tree and the preference store
 Cdx::coreaudio::property::device
 Cdx::coreaudio::property::device::setting
 Cdx::coreaudio::property::plugin
 Cdx::coreaudio::property::pod
 Cdx::coreaudio::property::pod::stream
 Cdx::coreaudio::property::qualifierQualifier a HAL property takes beside its address, where the selector asks for one
 Cdx::coreaudio::property::virtuelDxd's own selectors on a plugin: what neither the HAL nor a device knows - creating and removing a virtual device, the pod's stream and session notifications, and the plugin's own settings. A four character code each, as every HAL selector is
 Cdx::coreaudio::property::virtuel::device
 Cdx::coreaudio::server::controlControls a pin publishes beyond the encoders: clock source and its settings, the S/PDIF flag and the stream's source selector - numbered past dx::stream::encoder::index so one target field carries both
 Cdx::coreaudio::server::control::property
 Cdx::coreaudio::server::control::property::clock
 Cdx::coreaudio::server::control::property::spdif
 Cdx::coreaudio::server::device< pin_t >::clientOne process the HAL opened this device for: its bundle identifier, the HAL's client ids and the streams it holds - what a client leaves behind is released with it
Cdx::coreaudio::server::host
 Cdx::coreaudio::server::pin::[struct].cache
 Cdx::coreaudio::server::pin::[struct].cache.linesize
 Cdx::coreaudio::server::pin::[struct].cache.sync
 Cdx::coreaudio::server::pin< stream_pin_t >::entry< format_t >
 Cdx::coreaudio::targetWhat an ::AudioObjectID of this plugin addresses: the device, its pin and, inside that pin, the control - the plugin derives the object from the id alone, so no lookup table stands between the HAL and the device tree
 Cdx::coreaudio::target::dx_packed
 Cdx::coreaudio::target::dx_packed::dx_packed
 Cdx::coreaudio::target::dx_packed::dx_packed::dx_packed
 Cdx::coremidi::driver< device_t >::propertyWhat this driver calls its framework, as every dxd driver states it
Cdx::coremidi::propertyCoremidi::property
 Cdx::coremidi::targetCoreMIDI stream's hardware identity: the entity it belongs to and its direction - a source or a destination of that entity
 Cdx::crypto::rsaRSA public key of up to 4096 bits: the signature verification of RSASSA-PKCS1-v1_5 (RFC 8017 8.2.2)
 Cdx::crypto::rsa::sha256_digestinfoSHA-256's DigestInfo for verify(): the DER prefix and the digest
 Cdx::crypto::sha256SHA-256 (FIPS 180-4): update() over any run of bytes, digest() ends the message
 Cdx::daemon::appLaunchd daemon capturing the product's USB devices for its peers: a request names a registry entry, the capture holds while any requesting peer's connection stands
 Cdx::der::tlvOne element: its tag, content, the element behind it and its own start (begin..next is the whole element, what a signature covers)
 Cdx::driver< device_id_t, preference_t >::disconnectExclusive access to a device a host driver already holds: the scope shuts that driver down and boots it again at its end (dx::coreaudio::driver asks its installed plugin to release the device)
Cdx::driver_settings< promoted_t >Abstract base driver interface class This is the abstract base interface to a driver
Cdx::driver_settings< dx::promoted< dx::log >::preference< cf::preference > >
Cdx::driver_settings< dx::promoted< dx::log >::preference< decltype(_device_t::preference) > >
Cdx::driver_settings< dx::promoted< dx::log >::preference< decltype(device<>::preference) > >
Cdx::driver_settings< dx::promoted< dx::log >::preference< dx::preference > >
Cdx::driver_settings< dx::promoted< dx::log >::preference< preference > >
Cdx::driver_settings< dx::promoted< dx::log >::preference< preference_t > >
Cdx::event< scope_t >
Cdx::event< dx::kernel >
Cdx::event< dx::user >
 Cdx::fenceMemory ordering plain shared state needs on weakly ordered CPUs, in user mode and the kernel alike
 Cdx::gui::controlOne control of an outline row: what it shows and, where it may change something, how - a toolkit renders it, nothing else
 Cdx::gui::describeOutline of a struct that names its members (dx_serialize.h: visit): a line per member, as its kind says - a power of two, a bitmap of named bits, a choice among the options its struct allows as it stands -, a nested struct a branch of its own or, where all its members are switches, one line of toggles; an array a branch whose count is chosen, its elements beneath it. Every edit commits and tells changed, so every control asks its value and its options anew: what one member allows follows another. extend() adds a caller's lines to an array's element
 Cdx::gui::looknfeelDx::gui::looknfeel Approximates the juce interface's dark/light colour scheme on the containers wx lets us recolour (frame/panel/splitter backgrounds, the tree, and - via colour inheritance - future field labels) without fighting native control rendering. Buttons, combo boxes, checkboxes and text fields are deliberately left to render as the platform normally would: recolouring native controls fights macOS's own dark-mode appearance, whereas juce draws every control itself and so can commit to one look on every platform
 Cdx::gui::model< device_t >Device's outline: its line with icon and name, its identity, its desc (dx::gui::describe) - the clock's rate, source and sync reference and a stream's source among its lines -, its I/O size, its transport and its clients
 Cdx::gui::nodeOne line of the outline: its controls and the lines beneath it, those refilled as watch tells
 Cdx::int24Packed 24 bit integer, little endian: its low 16 bits and its high byte accessed as such - the two accesses clang makes of a packed 24 bit field -, sign extended
 Cdx::int24bePacked 24 bit integer stored big endian: converts from and to the native int on every access, so the ring converters take it like int24
 Cdx::iobridge< type_t >Ioctl bridge for 32/64bit user mode/kernel space big/little endian interface
 Cdx::iterator< container_t >Range-for support shared by every dxd type whose elements aren't already kept in an STL container of their own (dx::key_value_tree, cf::data, cf::dictionary, cf::array): a derived_t populates container_t however it needs to - a single existing conversion, or an explicit per-element loop - in its own constructor, then calls seed() once population is complete; operator++()/operator!=() forward to container_t's own iterator from then on. operator*() stays derived_t's own: what it should return (a plain element, const or not) differs per user, from cf::data's read-only bytes to dx::key_value_tree's mutable, further-navigable child node
Cdx::iterator< container >
Cdx::iterator< std::vector< key_value_tree > >
Cdx::iterator< std::vector<::SP_DEVINFO_DATA > >
 Cdx::launch< object_t >RAII object launcher
 Cdx::listener< listen_t >Balanced listener client into servers listeners map used from the client side to manage its subscription into the server listeners map
 Cdx::logWhole log setting in one 32 bit word: a dx::log::level per dx::log::scope per dx::log::module, four bits each. The word is what a driver, a kernel and a host exchange and compare; the named members are the same bits, and to/from name them for a preference, a command line or a property. The serialization macro hands the member list to the tree sink of dx_serialize.h, so a store - the plugin property's dictionary as a cf::store among them - holds the log resolved rather than the word
 Cdx::log::[struct].__unnamed0__
 Cdx::log::from
 Cdx::log::moduleParts of a driver a message is attributed to, each with its own dx::log::scope
 Cdx::log::module::from
 Cdx::log::module::to
 Cdx::log::scopePhases a module is logged apart in - a device's setup may be traced while its operation stays quiet
 Cdx::log::scope::from
 Cdx::log::scope::to
 Cdx::log::to
 Cdx::map::driver< _device_t, holder_t >::view::iterator< super_iterator >::pointer
 Cdx::map::driver< _device_t, holder_t >::view::value_type
 Cdx::midi::services::driver< device_t >::propertyThis bus's name in the device tree and the preference store
 Cdx::midi::services::targetStream of an endpoint: the direction, the index in the device
 Cdx::midi::ump::packetOne packet with its moment: the dx::timestamp() it arrived at or is due at, the words of the packet, words() how many of them the message takes
Cdx::objectFramework's object lifecycle: launch() once mounted, conclude() before removal, both reached through the try_ pair alone, which elects the single caller that runs them. Neither is a constructor's or destructor's job: an object is constructed long before its resources exist (a device ahead of its bus arrival) and outlives their release. The destructor's try_conclude() is the backstop for an object never concluded by its owner
 Cdx::open< object_t >RAII manage balanced object open/(close)
 Cdx::os_eventKernel/user space shared event representation
Cdx::parserCmd line parser
 Cdx::parser::dispatchOne command: what it runs, how it reads in the help, and the commands nested under it. A word of parameter consumes the arguments that follow it before this one's own function runs, which is what makes the CLI hierarchical
 Cdx::parser::dispatch::[struct].flags
 Cdx::pciPhysical PCI stream descriptor
 Cdx::pci::dmaPhysical DMA stream descriptor
 Cdx::pipe< rcv_t >::accessHow a client opens the pipe where the caller names nothing: read and write, overlapped
 Cdx::pipe< rcv_t >::server< instance_t, arg_t >Server - accepts multiple concurrent pipe client connections Each accepted connection is served by its own pipe::server::instance, running on a dedicated read thread. run() keeps exactly one instance listening for the next client at all times: once ConnectNamedPipe() accepts a connection, that instance's own thread calls server::run() again - reaping already-concluded instances and spawning the next listener - before servicing its own connection. A concluded instance (client disconnected) therefore joins only at the start of the next run(), on a different thread: a std::jthread cannot join itself, so reaping cannot happen from within the concluding instance's own read thread. An otherwise idle server thus keeps its most recently used instance around until either the next connection or stop(), which unconditionally joins every instance - connected or not - synchronously before returning
 Cdx::pipe< rcv_t >::server< instance_t, arg_t >::accessHow the pipe is created where the caller names nothing: a duplex message pipe, overlapped
Cdx::power::acOne processor power setting while on mains, set for the object's life and restored at its end - unless something else changed it meanwhile, which keeps that change
Cdx::power::dcSame setting while on battery
Cdx::power::schemeMachine's active power scheme, whose settings the classes above write
 Cdx::power::throttlingProcess power throttling opt-out: Windows 11 ignores timer resolution requests of windowless (service/background) processes unless the process excludes itself from that throttling policy
 Cdx::present::bitmap< names_t >Bits each named: names() the (name, bit) pairs
 Cdx::present::choice< options_t >One of options(): the (name, value) pairs the struct allows as it stands
 Cdx::present::power2Power of two, and the half-way values, from min to max
 Cdx::process::mmcssMmcss | thread priority/process priority class
Cdx::promoted< _value_t >::chainServer that keeps the one it replaces: a derived class prepends its own step (the device's request to the hardware) and hands the rest to the server its base installed
 Cdx::promoted< _value_t >::preference< preference_t, preference_value_t >
 Cdx::proxy::device< preference_t >::softwareSoftware Device API instance
 Cdx::proxy::driver< device_t >::notificationDevice notifications this driver's window is subscribed to: one per interface class it matches, and one per open handle whose removal it must hear about
 Cdx::proxy::driver< device_t >::notification::device
 Cdx::proxy::driver< device_t >::propertyThis bus's name in the device tree and the preference store
 Cdx::proxy::driver< device_t >::setup::devicesDevices of a hardware id and the set's class - its own or its parent's, a composite device's function - the present ones unless all are asked for, what a range-for over setup(hwid) walks
Cdx::proxy::driver< device< pin_t > >
 Cdx::proxy::stream::_device< desc_t, preference_t, stream_t, group_t, super_device_t >::monitorDriver's clock monitor, mapped on demand and handed back at the end of the scope; a driver that does not keep one answers not_implemented and the monitor stays empty
 Cdx::proxy::stream::_device< desc_t, preference_t, stream_t, group_t, super_device_t >::monitor::header
 Cdx::redirect::cerr
 Cdx::redirect::clog
 Cdx::redirect::coutEvent log entry kind each standard stream is written as - the three below are what dx::redirect::eventlog is instantiated with
 Cdx::redirect::fileStream into a file, beside its other sinks: instances naming one path share its buffer - one per ASIO client, left in any order - and each line is written once
Cdx::redirect::indentOne nesting level on a stream carrying an dx::redirect::indent::streambuf, taken for the object's scope: every line written inside it is prefixed. Levels nest LIFO per thread
 Cdx::redirect::indent::dflt
 Cdx::redirect::joinBuffer as a sink of a stream for the object's life - a sink's last member, so it leaves before the sink's own members go
 Cdx::reference< object_t >RAII manage balanced object open/(close)
 Cdx::registry::property
Cdx::resource< invalid_t >Windows handle class bill wasn't sure wether an invalid handle is a nullptr or -1. Hence the invalid_t template parameter. (Usually its -1, but i.e. for file mappings its nullptr, etc.)
Cdx::resource< nullptr >
 Cdx::service::accept
 Cdx::service::accept::to
 Cdx::service::client::driver< device_t >::property
 Cdx::service::client::targetService client stream's whole hardware identity: its direction - the device behind the service names its own
 Cdx::service::device< preference_t >::promotedService::device::chain handle request to/from device::promoted and pipe
 Cdx::service::driver< driver_t >::propertyThis bus's name in the device tree and the preference store
Cdx::service::managerService as the control manager sees it: installed, started, stopped and removed from here, its state followed by the promoted below
 Cdx::service::request< data_t >One message on the service's pipe: what is asked, what came back and the value it carries. Every setting a hosted device mirrors has its own id here, so a client's promoted reaches the service's device with one round trip
 Cdx::service::start_type
 Cdx::service::start_type::from
 Cdx::service::start_type::to
 Cdx::service::stateService states, start types and accepted controls by their SDK names - what a status is printed and a command line argument read as
 Cdx::service::state::to
 Cdx::shared::guard< object_t >Synchronize write/shared read access/destruction
Cdx::shared::guard< listeners< listener_t > >
Cdx::shared::guard< listeners< std::function< void(class dx::pipe::server::instance &, const rcv_t &)> > >
Cdx::shared::guard< listeners< std::function< void(const double &)> > >
Cdx::shared::guard< listeners< std::function< void(const dx::service::request< service::stream::data< desc > > &)> > >
Cdx::shared::guard< listeners< std::function< void(const dx::service::request< service::stream::data< desc_t > > &)> > >
Cdx::shared::guard< listeners< std::function< void(const dx::service::request< service::stream::data< typename device_t::desc_t > > &)> > >
Cdx::shared::guard< listeners< std::function< void(const rcv_t &)> > >
Cdx::shared::guard< listeners< std::function< void(const request_t &)> > >
Cdx::shared::guard< listeners< std::function< void(const uint32_t &)> > >
Cdx::shared::guard< listeners< std::function< void(const value_t &)> > >
 Cdx::shared::lockfree::list< entry_t >Entries a real time walk visits without a lock, in user mode and the kernel alike
 Cdx::shared::memory< buffer_t >::headerWhat every shared segment carries ahead of its payload: the version the host wrote it with and its size, so an attaching process refuses a segment of another build
 Cdx::shared::memory::header::[struct].shared
Cdx::source< _event_t, _clock_t >Clock source base: the only thing that may signal a tick - itself the event driven source (hw clock fan-out)
 Cdx::stream::channel::controlKernel streaming client's own header beside its channel buffers: the frame counter and the last two buffer switch timestamps, from which a client derives where the hardware stands
 Cdx::stream::channel::open< bus_t, max_channels >Generic stream open request
 Cdx::stream::channel::opened< data_t, channels >Generic streaming channel buffer description
 Cdx::stream::clockSelect/get stream sample rate/iosize
 Cdx::stream::clock::consumerOne clock consumer's share of the domain: its buffer switch is due every iosize samples
 Cdx::stream::clock::monitorPerformance monitor shared memory
 Cdx::stream::clock::monitor::[struct].performance
 Cdx::stream::clock_valueValue asked of, or answered by, one clock domain (sample rate, clock source)
 Cdx::stream::control< object_t >::pauseSession held open across a change that needs it stopped: the counted shares are taken out for the scope and handed back at its end, so clients starting or stopping meanwhile keep their own
 Cdx::stream::cursorClient's own place in a ring and the margin it keeps to the transport
Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >Device streaming interface descriptor
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::clockClock domain of the device: its sources, the rates it serves and everything the streams of that domain are timed by
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::clock::defaultsWhat the device asks for where nothing was stored yet - every one of them a preference's default
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::clock::defaults::iosizeBuffer sizes offered to applications, in clock ticks: what a host may ask for and what the ring is sized from
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::clock::defaults::sync
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::clock::settingOne clock source of this domain: internal, or an external one the device locks to
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::clock::setting::external
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::configurationDevice's configuration, the value the promoted configuration holds: the bus entity selecting it and, per stream, the index of its active stream configuration - one past the stream's configurations: the stream is off
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::firmwareDevice's own: what the bus reports (USB: bcdDevice, iSerialNumber) unless a product knows a vendor way; the serial number is what a license binds to (DSN)
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::name_idName with the bus entity's own id behind it - what a vendor, a model or a selectable source is called and how the bus addresses it
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::streamDx::desc::stream interface descriptor
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::clock
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::clock::sync
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::configDx::desc::stream::config interface descriptor
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::config::clock
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::options
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::options::quirkWhere the device departs from its class: what it does is the opposite of what its class descriptors state
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::options::spdif
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::pinPin of the stream: the channels a host attaches to as one entity, their format and what they are wired to. A stream's channels may be split into several pins, and a hidden one is not offered to the host
 Cdx::stream::desc< target_t, max_streams, max_pins, max_clock_settings, max_clocks, max_configurations, max_sources >::stream::transactionWhat one transfer on the bus carries where it is not simply a run of sample frames: a granularity the bus enforces, or a vendor's own payload size
Cdx::stream::desc< target, 2, 2 >
 Cdx::stream::device::[struct].hw
 Cdx::stream::device::[struct]registration.hw.__unnamed0__Consumer's registration: its event, its own iosize and sample counter - the counter the tick's alone, a reset asked of it
 Cdx::stream::device< _super_device_t, _desc_t, _stream_t, _group_t >::pauseRAII: pauses every one of this device's groups (remembered count, force-stopped) across a streams structure mutation, restarts all on destruction
 Cdx::stream::device< _super_device_t, _desc_t, _stream_t, _group_t >::propertyPreference keys of this device's settings, named once - the store's layout is these words, and a host's own property names never reach the store
 Cdx::stream::device< _super_device_t, _desc_t, _stream_t, _group_t >::property::sync
 Cdx::stream::device< _super_device_t, _desc_t, _stream_t, _group_t >::property::sync::cycle
 Cdx::stream::device< _super_device_t, _desc_t, _stream_t, _group_t >::property::sync::strategy
Cdx::stream::device< dx::stream::control< dx::device< std::string, preference_t > >, desc_t, stream_t, group_t >::property
 Cdx::stream::encoderPer channel controls a stream carries; what a device does not have is emulated where it has the gain, and the host publishes one control per bit
 Cdx::stream::encoder::[struct].__unnamed0__
 Cdx::stream::encoder::index
 Cdx::stream::engine::consumer< group_t, io_t, circular_t >App's consumer group for a bus device's group_t slot: engine::group over the bus's own group and the device's audio pin
 Cdx::stream::engine::group::[struct].cache
 Cdx::stream::engine::group::[struct].cache.sync
 Cdx::stream::engine::group::[struct].cache.sync.io
 Cdx::stream::engine::group::[struct].cache.sync.io.pin
 Cdx::stream::engine::group< group_t, _pin_t, _io_t, circular_t >::converter
 Cdx::stream::engine::group< group_t, _pin_t, _io_t, circular_t >::entry< sample_t >
 Cdx::stream::formatWhat one sample frame looks like, container and content apart: the resolution inside the container's size, its alignment there and its endianness. operator == is a match against a wish, not an identity: a member left at zero in the asked format matches anything, which is how a pin states audio alone and a ring adopts the one format its participants agree on (dx::stream::format::align). The named constants below are the formats the converters of dx_circular.h move - dx::stream::sample keys them
 Cdx::stream::iosizeClient's share of a clock domain: the samples between its buffer switches and the event the clock signals it on
 Cdx::stream::opened< object_t >Generic shared streaming buffer description
Cdx::stream::settings< device_t, store >Group's settings per side of its ring: the side's wait strategy on the clock and its lead per direction. The owner keeps them in its store, keyed and defaulted by role; a hosted device (device_t::hosted) mirrors the transport's through its mirror type, each born with the transport that asks the host
Cdx::stream::settings< device_t, !device_t::hosted >
 Cdx::stream::settings_promoted< device_t, store >
 Cdx::stream::settings_promoted< device_t, false >Hosted device's, born with the transport to its host (dx_value.h: no promoted is born empty)
Cdx::stream::shared::stream< device_t, dx::circular, dx::stream::control< dx::stream::object< device_t > >, dx::shared::event >
 Cdx::stream::start< object_t >RAII object start/stop balancer
 Cdx::stream::stream::[struct].cache
Cdx::stream::stream< device_t, circular_t, dx::stream::control< dx::stream::object< device_t > >, dx::shared::event >
Cdx::stream::stream< device_t, dx::circular, dx::stream::control< dx::stream::object< device_t > >, dx::shared::event >
 Cdx::stringFixed size name that crosses a process or kernel boundary by value, where a std::string cannot: the platform's file name length, always terminated, converting to and from std::string
 Cdx::test::device< super_device_t, _engine_t >::impulseOne impulse test: what an analog loop keeps is its timing alone
 Cdx::test::device::impulse::[struct].phase
 Cdx::test::device< super_device_t, _engine_t >::maskChannels a monitor's callback works on: one word per direction, plus the mix target
 Cdx::test::device< super_device_t, _engine_t >::sineOne generator tone: the channels it feeds and its phase, carried between callbacks
 Cdx::test::driver< super_device_t, device_t, driver_t >::match_helper< matching_t >
 Cdx::test::driver< super_device_t, device_t, driver_t >::match_helper< std::set< std::string > >
Cdx::test::driver< super_device_t, dx::test::device< super_device_t >, dx::proxy::driver< dx::test::device< super_device_t > > >
Cdx::test::driver< super_device_t, dx::test::device< super_device_t >, dx::virtuel::driver< dx::test::device< super_device_t > > >
Cdx::test::driver< super_device_t, dx::test::midi::device< super_device_t >, dx::proxy::driver< dx::test::midi::device< super_device_t > > >
 Cdx::test::loadLoad scenario the streaming monitor runs its session under: threads of the named kind for the object's lifetime
 Cdx::test::surprise::asynchronous< driver_t >Concurrently drives synchronous conclude()/launch() cycles (device tree arrival/removal) against whatever else is using the driver, on its own thread
 Cdx::test::surprise::synchronous< driver_t >Single, synchronous mid-operation conclude()/launch() cycle - a device that reenumerates leaves the bus and comes back instead, its drivers taking a surprise removal -, resuming streaming (if it was active) at its prior sample rate once the device is back
 Cdx::themed
 Cdx::thread::prioThread::prio
 Cdx::thread::workgroupApple audio workgroup: a realtime thread of a driver's own joins the workgroup of the device it serves, so the scheduler treats them as one deadline group (macOS 11)
 Cdx::thread::workgroup::intervalOne work interval of the group: started with its deadline and moved on by update() at every tick
 Cdx::thread::workgroup::joinThis thread's membership, held for the scope
Cdx::trace::receipt$ trace's entry and exit lines for one scope, the exit carrying the time spent - debug builds alone
 Cdx::ttyTerminal behind a file descriptor: its presence, its raw mode and its background colour
 Cdx::uint24Packed 24 bit unsigned integer, little endian: its low 16 bits and its high byte accessed as such
Cdx::usb::__::endpoint
Cdx::usb::__::interface
Cdx::usb::__request_typeStandard USB control request definitions
 Cdx::usb::audio::descriptorUSB audio class descriptors
 Cdx::usb::audio::descriptor::endpoint
 Cdx::usb::audio::descriptor::endpoint::midi
 Cdx::usb::audio::descriptor::endpoint::streaming
 Cdx::usb::audio::descriptor::endpoint::subtype
Cdx::usb::audio::descriptor::head
 Cdx::usb::audio::descriptor::interfaceUSB audio class interface descriptors
 Cdx::usb::audio::descriptor::interface::controlUSB audio class control interface descriptors
 Cdx::usb::audio::descriptor::interface::control::input_terminal
 Cdx::usb::audio::descriptor::interface::control::mixer_unit< pins >
 Cdx::usb::audio::descriptor::interface::control::output_terminal
 Cdx::usb::audio::descriptor::interface::control::subtype
 Cdx::usb::audio::descriptor::interface::control::v1Every control entity as Audio Device Class 1.0 lays it out; v2 below is the same set in 2.0 - the header's bcdADC says which a device speaks, and dxd configures ADC1 devices
 Cdx::usb::audio::descriptor::interface::control::v1::mixer_unit< pins >
Cdx::usb::audio::descriptor::interface::control::v1::mixer_unit< 1 >
 Cdx::usb::audio::descriptor::interface::control::v2
 Cdx::usb::audio::descriptor::interface::control::v2::mixer_unit< pins >
Cdx::usb::audio::descriptor::interface::control::v2::mixer_unit< 1 >
 Cdx::usb::audio::descriptor::interface::midi
 Cdx::usb::audio::descriptor::interface::midi::jack
 Cdx::usb::audio::descriptor::interface::midi::subtype
 Cdx::usb::audio::descriptor::interface::streamingUSB audio class streaming interface descriptors
 Cdx::usb::audio::descriptor::interface::streaming::format
 Cdx::usb::audio::descriptor::interface::streaming::format::ex
 Cdx::usb::audio::descriptor::interface::streaming::format::type1
 Cdx::usb::audio::descriptor::interface::streaming::format::type2
 Cdx::usb::audio::descriptor::interface::streaming::format::v1
 Cdx::usb::audio::descriptor::interface::streaming::format::v2
 Cdx::usb::audio::descriptor::interface::streaming::format::v2::ex
 Cdx::usb::audio::descriptor::interface::streaming::general
 Cdx::usb::audio::descriptor::interface::streaming::subtype
 Cdx::usb::audio::descriptor::interface::streaming::v1
 Cdx::usb::audio::descriptor::interface::streaming::v2
 Cdx::usb::audio::descriptor::type
 Cdx::usb::audio::isocIsochronous cycle of one pipe: the slots a session rotates through, each carrying the bus frame it is scheduled for, its request size and the lines its micro frames hold
Cdx::usb::audio::isoc::cycle
 Cdx::usb::audio::isoc::cycle::tick
 Cdx::usb::audio::isoc::cycle::tick::[struct].delivered
 Cdx::usb::audio::isoc::cycle::tick::[struct].detected
 Cdx::usb::audio::range< ranges_t >ADC2 control's answer: subranges of minimum, maximum and resolution
 Cdx::usb::audio::subclass
 Cdx::usb::audio::to::[struct].analog_connectorWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].communication_speakerWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].da_streamWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].desktop_microphoneWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].desktop_speakerWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].digitalWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].digital_interfaceWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].down_line_phoneWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].dv_streamWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].echo_cancelingWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].echo_suppressingWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].handsetWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].head_mountedWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].headphonesWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].headsetWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].legacy_connectorWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].lfeWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].lfe_speakerWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].lineWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].line_connectorWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].microphoneWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].microphone_arrayWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].omni_microphoneWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].personal_microphoneWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].phone_lineWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].processing_microphoneWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].room_speakerWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].spdifWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].speakerWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].speakerphoneWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].synthWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].synthesizerWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].telephoneWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].ttyWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::audio::to::[struct].usb_streamingWhat such a terminal is as a plug of a pin: what the two vocabularies share - a terminal the list leaves out keeps its number, since no word of dx::stream::plug names it
 Cdx::usb::captureIOUSBHost framework's device capture, its class reached through the Objective-C runtime: the class driver's clients are terminated, the device stays configured and open to other processes' interface clients, the drivers match again with the release
 Cdx::usb::clock::frameChrono conforming bus frame clock: frames since bus start; now() maps the OS timestamp onto the frame counter via the tick thread's correlation
 Cdx::usb::descriptorStandard descriptors over the platform's own declarations: one spelling for the walkers of dx_usb_audio.h, whatever SDK the build takes them from
 Cdx::usb::descriptor::stringString descriptor at its largest, the same on every platform: UTF-16LE, its length device supplied and untrusted; inside it head is its base's injected class name, so the union's member is named qualified
 Cdx::usb::descriptor::type
 Cdx::usb::endpointUSB specific errors
 Cdx::usb::endpoint::attributesEndpoint's bmAttributes: the transfer type, how an isochronous endpoint synchronizes, and whether it carries data or the feedback for another endpoint
 Cdx::usb::ezusb::an21Chip's CPU control register (bit 0: reset) and where its internal RAM ends
 Cdx::usb::ezusb::fx2
 Cdx::usb::hub::portPort's connection: the device's descriptor, speed and open pipes
 Cdx::usb::isoc::correlationBus frame clock's correlation with the timestamp clock, the same in every environment: which frame the tick serves, where the wire is now, when a frame starts
 Cdx::usb::isoc::correlation::[struct].correlated
 Cdx::usb::isoc::frameOne frame of a request: what was asked for, what the controller delivered and its status - laid over the platform's own frame structure, so a request is filled once and submitted as it stands
 Cdx::usb::isoc::pipeline::[struct].cache
 Cdx::usb::isoc::pipeline::[struct].sync
 Cdx::usb::isoc::resultCompleted asynchronous isoc request, as pulled by a platform pipe's poll()
 Cdx::usb::isoc::session< group_t >Streaming session's tick over a group's pipelines, the same in every environment
 Cdx::usb::midi< buffer_t >::msgUSB MIDI endpoint element types: defining the element size for a single USB MIDI pipe request
 Cdx::usb::platform::device< preference_t >::void_struct
 Cdx::usb::platform::pipe< device_t, interface_t >::isocWhat an isochronous pipe needs beside its requests: the micro frames a packet is spread over and the registered buffer they are served from
 Cdx::usb::platform::pipe< device_t, interface_t >::isoc::buffer
 Cdx::usb::stream::_device::[struct].adc
 Cdx::usb::stream::_device::[struct].adc.__unnamed0__.v2
 Cdx::usb::stream::_device::[struct].adc.__unnamed0__.v2.clock
 Cdx::usb::stream::_device::[struct].adc.__unnamed0__.v2.clock.selector
 Cdx::usb::stream::_device::[struct].adc.__unnamed0__.v2.clock.source
 Cdx::usb::stream::_device::[union].adc.__unnamed0__
 Cdx::usb::stream::pipe< device_t, circular_t, stream_t >::cacheWhat the tick reads instead of asking a promoted: the derived transaction sizes, the encoder stages and the in slot's sentinel - none of them may block or lock
 Cdx::usb::stream::pipe::cache::[struct].transaction_size
 Cdx::usb::stream::pipe< device_t, circular_t, stream_t >::cache::encoder
 Cdx::usb::stream::pipe< device_t, circular_t, stream_t >::isocWhat this pipe's session needs beside its own requests: the feedback ring of lines per frame, and an explicit feedback endpoint's own slots
 Cdx::virtuel::driver< device_t >::propertyThis bus's own preference keys: the store's subtree the device tree lives in
 Cdx::virtuel::stream::targetVirtual stream's whole hardware identity: its direction, since there is no bus to address
 Cdx::void_structEmpty stand-in where a template needs a type but nothing is carried - it streams nothing
 Cdx::wasapi::client::driver< device_t >::propertyThis bus's name in the device tree and the preference store
 Cdx::wasapi::client::targetWASAPI stream's hardware identity: the endpoint it belongs to, by the MMDevice id, and its index within the device - one endpoint per direction and channel pair, several of them making up one device
 Cdx::wasapi::reference< object_t >COM interface reference
 Cdx::wasapi::task_memory< type_t >CoTaskMemAlloc'd out parameter
 Cdx::window< driver_t >Message only window on a thread of its own: WM_DEVICECHANGE and WM_POWERBROADCAST are what Windows delivers device arrival, removal and sleep through, and there is no window less way to take them
 Cdx::x509::certificate
Cdx::xpc::connectionClient's connection to a launchd mach service: a request is one number under the request's name, answered with a status
 Cdx::xpc::listenerLaunchd mach service: every peer's requests run the handler on the queue, a peer's end runs the closure there
 Cdxd::__atomic_pointer< type_t >Atomic pointer operations
Cdxd::__atomic_pointer< type_t * >
 Cdxd::__atomic_scalar< size, type_t >
 Cdxd::__atomic_scalar< 4, type_t >32bit atomic operations
 Cdxd::__atomic_scalar< 8, type_t >64bit atomic operations
Cdxd::__atomic_scalar< sizeof(event *), event * >
Cdxd::__atomic_scalar< sizeof(int), int >
Cdxd::__atomic_scalar< sizeof(item_t *), item_t * >
Cdxd::__atomic_scalar< sizeof(link *), link * >
Cdxd::__atomic_scalar< sizeof(long), long >
Cdxd::__atomic_scalar< sizeof(type_t), type_t >
Cdxd::abstract::eventAbstract::event: base clase to event<dx::user> and event<dx::kernel> to allow mixed user/kernel broadcast signalization
 Cdxd::adjust< endian_t >
 Cdxd::adjust< host >
 Cdxd::adjust< swap >
 Cdxd::array< vm_t >Array owned the same way, sized once and freed with the object
 Cdxd::busWDM BUS class
 Cdxd::bus::descDevice description for bus class
 Cdxd::bus::desc::[struct].matching
 Cdxd::bus::desc::[struct].node
Cdxd::clientUser client: one per control open, created by device::client_create()
 Cdxd::decay< type_t >No array/function decay - not needed here
Cdxd::devicePlain WDM device, one per FDO
Cdxd::event< scope_t >WDK event
Cdxd::event< scope >
 Cdxd::fourchar_stringFour character code as a string on the stack: the kernel has no allocation free formatting, so the code is unpacked into this and printed as s
 Cdxd::fw::addressAddress range this driver publishes on the bus: a peer writing into it hands its data over through the FIFO entries below
 Cdxd::fw::phy
 Cdxd::kmdf::clientUser client
 Cdxd::kmdf::driver_creatorDummy WDF interface class
Cdxd::linked::item< item_t >Singly linked list item
Cdxd::linked::item< event >
Cdxd::linked::item< link >
 Cdxd::lock< lock_t >
 Cdxd::map< scope_t, vm_t >One mapping of a buffer, into the driver itself or into the client that asked for it - the scope says which address space the address belongs to
Cdxd::map< dx::kernel, channel_t >
Cdxd::map< dx::kernel, dx::circular >
Cdxd::map< dx::kernel, dx::stream::clock::monitor >
Cdxd::map< dx::kernel, unsigned int >
Cdxd::map< dx::user, dx::circular >
Cdxd::memory< scope_t, io_memory_descriptor_t >Virtual DriverKit memory description
Cdxd::memory< dx::kernel, ::IOBufferMemoryDescriptor >
 Cdxd::multichannel::stream::[struct].control
 Cdxd::multichannel::stream::umap::[struct].cache
Cdxd::mutexMutex
 Cdxd::open< object_t, service_t >
 Cdxd::pci::dbg
 Cdxd::pci::resourcesPCI windows this device was assigned, mapped for the driver's life: each one its virtual and physical address, its length and its mask
 Cdxd::pci::resources::memory
 Cdxd::pci::scatter_gather< limit_t, alignment_t, page_size_t >
 Cdxd::portMiniport creation helper
 Cdxd::port::reference< object_t >COM reference held for the object's life - the PortCls interfaces are reference counted and a miniport that keeps one raw outlives it
 Cdxd::reference< object_t >Reference holder for object based reference counter
Cdxd::referencedReference counting base class
 Cdxd::remove_reference< type_t >
 Cdxd::remove_reference< type_t & >
 Cdxd::remove_reference< type_t && >
 Cdxd::scoped< object_t >Object owned for the scope, freed at its end and at every assignment - the kernel's own unique_ptr, with the conversions an OS call's out parameter needs
 Cdxd::scoped<::URB >
Cdxd::spinlockWDK spinlock
 Cdxd::stream::opened< packetizer_t >Generic streaming interface description
 Cdxd::streaming::channels< channel_t >One client's planar channel double buffers for one pin
 Cdxd::streaming::clock::[struct].controlBuffer switch bookkeeping every pin the client attached follows: both directions switch together
 Cdxd::streaming::configuration_server< device_t >Device's configuration: the device's alignment of the wish - a bus device narrows it to what its bus carries - and the value it stands at while a stream is started; every ring whose stream configuration changes binds to its new one ahead of the commit, a ring that cannot stands and the wish is aligned around it (desc::bound())
 Cdxd::streaming::converter
 Cdxd::streaming::domainClock domain every client rides on: the DAW clock
 Cdxd::streaming::entry< sample_t >
 Cdxd::streaming::iosize_server< device_t >Buffer size a client asks for: aligned to the clock's granularity and the desc's limits, and left where it stands while the device streams
 Cdxd::streaming::offset_server< device_t >Client side safety offset in clock ticks: it is committed and then handed to the domain's registered clients as a margin in bytes, which their cursors take at the next seat
 Cdxd::streaming::samplerate_server< device_t >Server functors of device's promoted values
Cdxd::streaming::switchingOne client's share of a clock domain: its buffer switch event and iosize, and the channel buffers that switch
 Cdxd::streaming::transport_server< device_t >Transport's settings in the dx::stream::setting order - its wait strategy, its lead out and in - the desc's defaults until a client sets them, committed and handed to the bus running the transport
 Cdxd::string< char_t, length >Formatted string of a fixed length on the stack: the kernel has no std::string, and a driver's names and log lines need no allocation
 Cdxd::usb::stream::clock_server< base_t, desc_t >Runs the group while streams are started, from within started's promoted server
 Cdxd::wavert::stream< stream_desc_t >::row< ext_t >::entry< circular_t >
 Cdxd::wdm::device_interfaceEnabled device interface: registered and enabled by initialize(), disabled by conclude() - or on destruction, when no remove came
 Cdxd::wdm::fileFile class
Cdxd::wdm::registryRegistry key in the kernel: the driver's parameters and, for the license, the machine's certificate store - read at PASSIVE_LEVEL alone
 Cdxd::wdm::workitemWDM workitem helper
 Cdxd::wmiWMI data block's instances, read as a consumer (IoWMIOpenBlock, IoWMIQueryAllData) at PASSIVE_LEVEL
Cgroup_t
CGUID
CIASIO
CIMiniportWaveRT
CIMiniportWaveRTStreamNotification
CIMMNotificationClient
CIMXF
Cinstance_t
 Cio::iterator::serviceIteration state of a range-for over an IOKit iterator: the service in hand and the iterator handing out the next
 Cio::powerSystem power notification receiver to get notifications: inherit and connect to runloop
 Cio::reference< io_object_t >IOKit object's retain and release, the counterpart of cf::reference for the io_object_t family
Cio::reference<::io_iterator_t >
Cio::reference<::io_registry_entry_t >
Cjuce::Button::Listener
Cjuce::ComboBox
Cjuce::ComboBox::Listener
Cjuce::Component
Cjuce::FileBasedDocument
Cjuce::ImageComponent
Cjuce::JUCEApplication
Cjuce::Label
Cjuce::MenuBarModel
Cjuce::RecentlyOpenedFilesList
Cjuce::TextButton
Cjuce::ToggleButton
Cjuce::TreeView
Cjuce::TreeViewItem
CKSDATARANGE_AUDIO
CMIDIDriverInterface
Cobject_t
COVERLAPPED
Cpin_t::device_t
CPROCESS_INFORMATION
Cproxy::driver< device< stream_pin_t > >
Cpublic::CUnknown
Cpublic::IMiniportDMus
Cpublic::KEVENT
Cpublic::PCPIN_DESCRIPTOR
Crequest_t
 Csc::_preference::lockSystem configuration store's write lock, held for the scope - a store several processes write needs it around a change
 Csec::code< item_t >
CSECURITY_ATTRIBUTES
CSECURITY_DESCRIPTOR
CSERVICE_NOTIFYA
CSERVICE_STATUS
Csource_t
CSTARTUPINFOA
Cstd::basic_string< Char >STL class
Cstd::bool_constant
Cstd::condition_variable
Cstd::deque< T >STL class
Cstd::enable_shared_from_this
Cstd::exceptionSTL class
Cstd::false_type
Cstd::ios_baseSTL class
Cstd::jthreadSTL class
Cstd::list< T >STL class
Cstd::map< K, T >STL class
Cstd::mutexSTL class
Cstd::recursive_mutexSTL class
Cstd::shared_ptr< T >STL class
Cstd::streambuf
Cstd::threadSTL class
Cstd::true_type
Cstd::tuple
Cstream_desc_t
Cstream_pin_t
Cstream_pin_t::device_t
Cstream_t::stream_desc
Cstreaming_device_t
Cstruct desc_t::stream
Csuper_device_t
Csuper_iterator
Csuper_stream_t
Cthread_time_constraint_policy_data_t
Ctree_t
Ctypename stream_t::stream_desc
CUNICODE_STRING
CUSBD_PIPE_INFORMATION
CwxApp
CwxButton
CwxCheckBox
CwxComboBox
CwxDialog
CwxPanel
CwxScrolledWindow
CwxStaticBitmap
CwxStaticText
CwxTextCtrl