Struct ResolvedSettings 

pub struct ResolvedSettings<'a> { /* private fields */ }

The settings an audio system is about to be built with, as validate_settings sees them.

A borrowed view of the BelaInitSettings this crate holds at the point where every layer has had its say: Bela_defaultSettings() first — which on a board has already applied the CL= line from ~/.bela/belaconfig and whatever a Bela_userSettings() hook did — then Settings, then Bela’s standard command-line options where Bela::new_with_args was given any. Nothing writes to those settings afterwards, so what an accessor here reports is what Bela_initAudio will be called with.

What was asked for, not what the board will give

This is the request. What the hardware makes of it is SetupContext, and there is no way to have that any earlier: it does not exist until Bela_initAudio has run, which is the call this view exists to be consulted before.

The two differ wherever libbela reshapes a request rather than refusing it, and it does so often — --analog-channels snaps to 8, 4 or 2, --digital-channels clamps to 16, and a Bela Gem Stereo reports 0 analog output channels however many were asked for, because it has none (docs/board-facts.md). So a check written here answers “were these settings asked for”, never “is this what the codec gave”.

That is not a gap this crate can close. Asking the board and then declining means declining from setup, which runs inside Bela_initAudio with the audio hardware already up, and a refusal from there fails the initialisation and leaves the process unable to build another audio system — see Bela::new. Refusing the request costs nothing; refusing the result costs the process.

More than the C structure

Settings::cpu_monitoring is not a BelaInitSettings field — it is a separate C call the audio system makes just before Bela_initAudio — so it is carried here alongside the structure and reported by cpu_monitoring. Without it this view would be missing the one setting that decides whether BlockContext::cpu_usage answers at all, and an application built around that reading would have nothing to check.

What is not here

numAudioInChannels and numAudioOutChannels, which Bela.h marks [ignored]. Neither Settings nor any standard command-line option writes them, and libbela does not read them, so a comparison against one would be a comparison against a constant that says nothing about the audio system being built. How many audio channels there are is SetupContext::audio_in_channels and its output counterpart, after the fact.

as_sys reaches the whole C structure for anything else, including the fields this crate has no safe vocabulary for.

Implementations

impl<'a> ResolvedSettings<'a>

pub const fn as_sys(&self) -> &BelaInitSettings

Read access to the underlying BelaInitSettings.

Everything except cpu_monitoring, which libbela keeps nowhere in this structure.

pub const fn period_size(&self) -> i32

Requested number of audio frames per period (“block size”).

A C int, and reported as one: the resolved value is whatever survived Bela’s own parser, which reshapes rather than refuses — --period 0 arrives here as 1 — and this crate does not reshape it further. There is no period size to check against either: 2 runs on a Gem Stereo where 3 does not, and both failures move as soon as the analog configuration does (docs/board-facts.md).

pub const fn audio_sample_rate(&self) -> f32

Requested audio sample rate in Hz.

0 never reaches an application: it is what --sample-rate gives for anything atof cannot read, and it is refused with Error::SampleRate before this view is shown to anyone.

pub const fn use_analog(&self) -> bool

Whether the analog input and output were asked for.

pub const fn num_analog_in_channels(&self) -> i32

Requested number of analog input channels.

What the command line asked for after Bela’s parser snapped it to 8, 4 or 2, or what Settings::num_analog_in_channels set, which is passed on as it stands. 0 here is not “no analog inputs” — use_analog is.

pub const fn num_analog_out_channels(&self) -> i32

Requested number of analog output channels.

A Bela Gem Stereo has none, and reports 0 in the context whatever this says; see Settings::num_analog_out_channels.

pub const fn use_digital(&self) -> bool

Whether the programmable GPIOs were asked for.

pub const fn num_digital_channels(&self) -> i32

Requested number of digital (GPIO) channels.

pub const fn thread_count(&self) -> usize

How many threads render will be called on, which is how many RenderStates this audio system will build.

At least 1, for the same reason RenderContext::thread_count is: libbela spells one render thread as either 0 or 1, and this reports the number of threads that will render.

The resolved value — Bela’s defaults, whatever a Bela_userSettings() hook made of them, then Settings::thread_count. Bela’s standard command-line options cannot change it, unlike most of this view; what they can change is whether the rest of the configuration still suits the number. So an application that only works on one thread — or only on four — can say so here, and refusing costs nothing.

pub const fn uniform_sample_rate(&self) -> bool

Whether the analog channels were asked to be resampled to the audio sample rate; see Settings::uniform_sample_rate.

pub const fn high_performance_mode(&self) -> bool

Whether high-performance mode was asked for.

pub const fn detect_underruns(&self) -> bool

Whether underrun detection and logging were asked for.

pub const fn verbose(&self) -> bool

Whether libbela’s own verbose logging was asked for.

pub const fn enable_led(&self) -> bool

Whether libbela’s running and underrun LEDs were left on; see Settings::enable_led.

Worth reading rather than assuming: --disable-led is applied after Settings and clears the flag whatever the application asked for. So a program that must know whether the board will light up — to put its own indicator somewhere else, or to refuse the run — has to look at the resolved value here, not at the Settings it was built with.

pub const fn begin_muted(&self) -> bool

Whether the speaker amplifiers were asked to come up muted.

pub const fn cpu_monitoring(&self) -> Option<NonZeroU32>

The CPU monitoring acquisition cycle that was asked for, in measurements per cycle, or None when monitoring is off.

What Settings::cpu_monitoring said, and the one thing here that is not a BelaInitSettings field: monitoring is a separate C call, which the audio system makes immediately after this hook has accepted the configuration. Nothing else can change it — it has no command-line option — so unlike the rest of this view it is the application’s own setting read back, and it is here because an application that needs BlockContext::cpu_usage to answer has no other way to find out before setup.

A cycle that is here has already passed this crate’s checks: Error::CpuMonitoringCycle for a length libbela cannot take and Error::CpuMonitoringPeriodSize for a period size where the counters would not describe the thread that renders.

pub const fn stop_button_pin(&self) -> Option<u32>

Which GPIO pin is monitored for stopping the program, or None when nothing is.

The Option is libbela’s own spelling read back: a negative pin is how monitoring is turned off, which is what Settings::stop_button_pin passes None on as. A pin the board does not have is not refused anywhere and is reported here as the number it is; such a run carries on without a working stop button.

Trait Implementations

impl Debug for ResolvedSettings<'_>

The accessors, and not the whole C structure: BelaInitSettings has a Debug of its own, with the callback pointers and the 256 bytes of pruFilename in it, and as_sys is the way to it.

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.