I won't refer you to specific projects, but I will list a number of keywords, as those should help anyone willing to contribute to explore these ideas further in journal articles, although it seems you already know relevant terms I didn't mention (like "tamper-resistant", although you may have more success with "security envelope").

Specifically regarding bullet detection, you may wish to consult ballistic software which takes into account air friction. Once you can generate random trajectories in air for a representative distribution of initial bullet speeds, it should be relatively simple to transform these to relative pulse arrival times at a 3D array of microphone locations.

For precise pulse arrival times one may wish to look at "constant fraction discriminaors", so that for rising pressures of the pulse, the timing is independent of pulse strength.

For decentralized analysis, and compatibility with the courts it would be best if it didn't output a "Holy Answer", but instead computes an interpretation of the recordings and why it believes in the trajectory it heard, so that at all times an alternative interpretation with a better fit can be proposed, and algorithms improved. This would require the decentralized code to effectively run a formal verifier on the audio evidence backed proof. Reimplementing the metamath verifier on a decentralized blockchain should work.

The devices themselves would best be constructed by and for the population, with individuals selected at random, trained to understand how the device works, and then implementing it and its security envelope.

It would be best if the protocol allowed new concerned citizen to continuously join the protocol, to use threshold cryptography so that the police can only consult the recordings with permission of civilian population, keeping an eye on how often they request to check for a bullet when there was none (some should be tolerated, but bulk collection denied).

The devices should store candidate recordings in a rotating buffer overwriting older / less probable bullet recordings, but always encrypted towards the group by treshold cryptography. These on-device recordings should be considered a backup failsafe only in case internet connectivity disappears. The usual operation is to (immediatly) send the encrypted shards to the group of civilians running the protocol (for time stamping purposes). Individuals or small groups can not decode the recordings on their own, only with sufficient ( K out of N ) civilians agreeing the recordings should be published can they be published, in which case that recording is public for all (including the police). Either everyone gets to hear the shots fired, or no one. Regarding the agreement procedure: that too would use formal verification, the rules and conditions when civilians are supposed to agree should fall under democratic control, and the user agent (software client) the civilians run automatically release or withhold according to these rules. Unreliable citizens that refuse to release their share of the secret when they are supposed to, or leak their share of the secret when they are not supposed to are temporarily banned from participating in the protocol (and will for such duration no longer be remunerated for their participation). This means you don't get cliques of interested parties joining up in large numbers amid a disinterested and unincentivized population cherry picking when to release a recording or not (by modifying the source code of their local client in order to cherry pick against due process when to release the recordings).