waaromzomoeilijk/rpi-audio

rpi-audio's Issues

Storage

Bootup: SSD boot would be out of scope for now since it occupies another USB port (which I'd prefer to a hub)
Future exception (just as an idea) is to let the standard format of all inserted USB drives to be a minimal installation plus data drive; then in the event the SD Card is unreadable, the USB boot can proceed. Note that this is probably way out of scope of the project and may more likely apply to an Alpine Linux Extended (RAM) boot architecture. Also in the future case, relying upon RAID/LVM mirror may provide a failsafe against data loss or read errors
ZFS: would consider entirely out of scope
Protection from heavy I/O
May look to writing log file entries in a sparse way, like only a minute at a time, or keeping log chatter at a minimum for non-audio entries. Anyhow not too big of an issue
Free space: I'd say that 5% free space is sufficient

ZFS

ZFS best practice is on 64bit RPI distributions, we are using 32 bit, check if we can use 64bit without any issues in regards to audio/drivers/kernel.

Automated External Storage

Augment the storage subsystem to determine all connected USB sticks, and then once those sticks or mount points are tallied, tee any recordings to all of them. Be reluctant to format the stick, but if it's inserted and has no partition table, or appears to be empty (like, factory formatted), then consider this as a sign that the stick is unused as of yet and then format it accordingly (perhaps xfs). If there's an error with the stick, you can include the single beep for warning and then skip that USB stick (logging the error)

• Let the pipe be augmented briefly, too. Not only to encode the input stream via Opus (opusenc) but also to encrypt to a fixed GPG public key and then to add parity (vdmfec or rsbep), followed by a "split" to write a new file, say for example every 4MB (that way, if there's a disk corruption or unexpected powerout, partial stream is still available even if the last file is corrupted). For overkill, after a stream file is written you can consider the par2 command which processes a whole file and not a stream; it can add for example an additional 10% redundancy for recovery. Because of the compression and encryption, not losing a bit is important because the stream could be corrupted if there is a lost bit

UPS

Work on the UPS subsystem in order to have the supposed "power loss" event (unplugging the whole unit) trigger the end of the recording. Confirm that this works as intended. Work on the most straightforward or least invasive signal to be sent to the recording process (so that it's not an abrupt termination). Add shutdown directives, including a clean ending, a sync, an unmount, a wall command with a quick warning, followed by a halt

Include a brief diversion into potential hardware that you're aware of to support a UPS (battery backup) function, since I'd like unplugging the unit to eventually signify the elegant ending of recording. Ideally a model with a high capacity battery (for the scope of other projects) and one that also includes full housing for the battery and Pi itself.

Could you check into when PiJuice intends to offer a case that houses their very biggest UP battery?

Robustness

Attempt to do something graceful when USB drives are removed and reinserted even in the middle of the recording
Write the very next split file into any USB mount points that are considered active
Attempt to remove mount points that correspond to stale devices
Note that a flaky USB that may accidentally remove itself and reinsert could be a problem or a cause to this removal. It's considered too complicated to try to find out if it's the same drive as before, but an rsync/unison of some kind may help other drives catch up
Handle the case when the system has a stale mount that hangs around. Like umount -l perhaps
Ensure uniqueness of new mount point used. Can still consider leveraging the OS's built-in triggers to auto-mount. It's just that you may want to look into a few safe workarounds and enhancements to that

Configuration

Time zone can be expressed sufficiently well as Universal time
Does DietPi setup keep running daemons and listening ports / services at a minimum? Does it skip running X and a display manager? Does it skip auto-login? May find text mode to be sufficient for now
Execution
Lots going on in some of those calculations, like determining root drive. Might consider that a config file could have spaces or tabs (like /etc/fstab). Could look into root device perhaps with df -k / or stat / of some kind

Audio

Intend to include multi-channel when present, especially since one audio I/O device might not be the one the user intends.
I'd prefer to record them all, since space is ample.

Suppose an accidental HDMI connection creates an audio interface to go with it. Or maybe they'd want that. Multi-channel likely implies running more than one example script at the same time, unless there's a known command line application that ingests simultaneous input and turns it into a single multichannel stream.

Audio calibration: definitely take note of working mixer settings in a file. This could be remotely entered by an administrator or could be hard-coded or could be auto-generated. Consider having this setting come with a "weight" of how much to pull settings toward this value compared to a calibrated value. Higher weight means the hard-coded setting is more likely to be right compared to the calibration result, and a lower weight means entrust the calibration more

For calibration, consider taking a sample of generated audio upon original startup (1), during the first eight seconds of recording (2), and then during the first 32 seconds of recording (3)
Noting that audio might actually be a little quieter than usual (the person might not yet be talking), the first calibration point can accept that and let its bias include that assumption
The calibration points for (2) and (3) can happen while the recording itself is happening. There must be a tool that examines average, max, and weighted maximum volume level during a snippet. This would be very tricky to get exactly right since it might need to discard accidental spikes from the user moving a microphone. In the end a rough 80% might be reasonable but these are some enhancements
At point (3) another run through of what's recorded can then consider further adjusting
Anyhow feel free to look into what seems approachable and easy here
See if there's any advantage of pipewire

Automated mixer lvl & recording

As a preliminary demonstration, using the proposed architecture, have the system adjust mixer level and start recording (to compress to Opus) upon power on. Determine the basic security for that. Should the process start as an administrator that's able to sudo? Or would sudo not be needed if that user happens to have (read?) access to the audio device? Would this be a systemd service or a modern equivalent of rc.local? Note that it doesn't need to be fancy here but should still work predictably and in the right order. Note that later inclusion of ZeroTier or a LTE connection suggests that the startup may need to summon a root-level script. This initial step can store the recording locally (on the SD card)

Find out a way to ensure that the mixer level is set to the right value assuming the microphone level will usually be the same - not too high of a level since it may over-saturate, and not too low since it would lose information potentially. Also ensure that the recording input is definitely referencing the right audio input. In pulseaudio I sometimes found it hard to parse the command line input but there must be standard conventions to do so. I want to make sure not to record the wrong thing, or to record noise or an empty sound. Put together a means for minor system update for security patches (some apt-get update && apt-get dist-upgrade equivalent or something that follows the provisioning conventions)

Failsafe sanity checking

Add some failsafe sanity checking. Ensure that an external USB microphone is attached, and stub out a check for an LTE modem (later step). Check for at least one external USB storage media. If something appears to be missing, look into warning the user. Does the BEL character (^G) cause a system beep of some kind? Perhaps one beep for warning, two beeps for full stop error

ZeroTier

Provisioning

Idempotent, orthogonal, and modular installation
Augment /etc/rc.local itself to point to any number of executable entries in /usr/local/etc/rc.local.d/ and then run any such one by one
Then ensure that running /etc/rc.local is part of bootup; make rc.local executable
The real content would live in one of those rc.local.d/ entries (executable, like 00-project-audio-recording-bootstrap.sh)
A later native package installation/update is unlikely to overwrite /etc/rc.local itself but if it were to do so accidentally, then at least the real content would still be there in /usr/local/etc/
Network assumptions
Might be useful to consider that network may not always be available, especially when it's already been deployed. But it's still okay to try in a non-blocking way

RPI distribution

Preferrably text-based, minimal, and a 32-bit kernel (for compatibility, based upon my understanding, and future scoped for other text-based projects). You can feel free to suggest one or two other alternatives that would have been reasonable options as well, just so that I can understand good options. I usually prefer not to use systemd but I'm not entirely against it. And the hardware to target should include the Rasperry Pi 4 B (8GB) which I have but could also work on other models

USB MIC

Also note that for an external USB microphone I happened to get this https://www.amazon.com/gp/product/B004L9KLT6 you're able to show that an equivalent (Blue) microphone would work fine for your testing you can start with that

Enclosure

LTE modem

Now look into the connectivity of the LTE modem. Ensure the network is brought up upon start, and include one warning beep if there's an issue. Attempt to connect a few times just in case. Include a basic ZeroTier installation, and have the demo Pi join a network. Then bring up SSH configured in a way to listen only on the ZeroTier interface. You can configure this as such and/or add one or two basic firewall rules. Consider some demo SSH public key to be used for connectivity so that password login is disabled for SSH

For a USB 4G LTE adapter I got https://www.thinkpenguin.com/gnu-linux/usb-4g-lte-advanced-modem-gnulinux-tpe-usb4glte but i

Would encourage checking into the LTE modem (the quoted model), if you don't have it already. Note ZeroTier atop this isn't too difficult
A future scope would still use the LTE modem as primary, but may "try out" WiFi locally to see if this is an alternate network. Both passwordless networks (tried one at a time) and those in some local database of encrypted networks (perhaps provided remotely). Since WiFi can fail, let WiFi connection be secondary

Error conditions bell output

Is there a BEL audio output of any kind? How easy is it to add this on?
I'd suggest two classes of errors. One being a "warning", like a BEL that happens once upon boot. Just once, even if there is more than one warning.
The other kind of error is an "error", something that would result in a double BEL (two BELs in a row) every 60 seconds or so, even during recording. This would happen when something severe is going on that would really get in the way of recording and the BEL is the sign to stop the recording or turn off the unit for its replacement
The repair model is twofold. One, if the system is being maintained remotely by someone tech savvy, then the actual errors ought to be in the log file. Or if the unit is swapped, then the log files would show. But two, the model for the user who isn't in touch with a tech savvy person is to have them replace the entire Raspberry Pi and then simply just move the USB storage disks and USB microphone over to the new unit. Perhaps the old one is sent in the mail and one unit is always on reserve
It would be essential to confirm a working microphone attached and at least one USB storage medium with sufficient free space, and no fatal errors encountered in the process
Warnings can be triggered more readily but not just because something's just out of the ordinary. Well it's a fine line

Scripting design

Aim to place most commonly used or commonly changed defines at the top, perhaps in one separate script. Then derived quantities or less frequently changed values can appear further down
Absolute security isn't absolutely critical here. Maybe the main user is considered a sudo/admin and so automatically has access to a device, say for example in the audio group. However, using groups for permissions instead of root can help

Hardening

Method of deployment.

If deploying, installing, provisioning, or updating involves some standard process (like building an image on an independent Linux server with qemu), feel free to hint at an external guide or web page that explains the process so that I'm familiar. I don't imagine many updates would be necessary ultimately, but it will be good information for the initial install and for future projects. Perhaps some distributions keep configuration orthogonal to the binaries and libraries, or a distribution may run from RAM. Basically in this step, speak to what's needed to install the final product. Will the end scripts be untarred somewhere? Provisioned with something like salt? Will it live in a basic container like podman?