rustyvibes <volume> <soundpack_path>

Maybe need to update the readme too? Either update the source in cargo or instruction to build it locally.

I tried to install rustyvibes on my Ubuntu 21.10 system with cargo install rustyvibes but the installation failed with the warning and error messages: warning: build failed, waiting for other jobs to finish... error: failed to compile `rustyvibes v1.0.8`, intermediate artifacts can be found at `/tmp/cargo-installgSvcr6`

Any fixes to this? (Entire installation error screenshot attached)

I wanted to put a draft PR up since this has bigger changes in functionality, and will require pre-processing of soundpacks in order to support the new format.

What this PR does:

• Introduces a new utility script to iterate through a soundpack, analyze the ogg files, split them into the key-up and key-down portions, trim silent whitespace off the front edge (to further reduce delay), and then save out as wav files.
• Modify the main rustyvibes driver to play the appropriate key down and key up sounds at the right time.

Gaps/deficiencies in this current PR

• Rust ogg encoder crates are few and far between, so here for simplicity I'm writing out to wav instead.
• I need to clean up and improve the conversion script to also modify the config.json as well, and delete the original ogg files.
• The usage of up.wav extension is a bit of a hack, but avoids me from having to do more major surgery to the config schema.

I'd like to know if this is a direction I should keep pursuing before continuing though. So what do you think?

In trying it out, I think it's pretty flippin' sweet to hear an accurate key down and key up sound at the right times. Really makes it feel realistic. But that's just my $0.02.

I installed the CLI via brew, followed the usage instructions writing it like this rustyvibes /Users/.../Downloads/Soundpacks/cherrymx-black-abs which is where the sound files are located, the program started running but no sound is working, the first time I ran it it asked for permissions on accesability I clicked open accesibility preferences but nothing appeared, so i searched for the rustyvibes executable which was found in /usr/local/bin/rustyvibes and I dropped it on the accesibility panel, even then it still didnt work, any ideas on how to get it to work? I downloaded MechVibes just to check it out and I enjoy it BUT its really resource intensive

By using a threadpool, we can reduce thread startup times (minimal impact) and more importantly: cache rodio OutputStream creation which costs about 10-20ms per keypress. And all around reduce allocation.

We also cache file reading in a global hashmap.

Ironically, this caching seems to reduce memory usage in my testing (MacOSX looking at private and total).

Changes

• clap library is used to parse commands instead of manually parsing.
• volume support is added by sending the filename and the volume value to the worker.

which makes most soundpacks fail to work because of the wav error

https://github.com/kb24x7/rustyvibes/blob/38b6b9e16a8085f2c6e14dd29ad4347b56dba600/Cargo.toml#L19

This is the error my terminal showed when doing cargo install rustyvibes:

❯ cargo install rustyvibes
    Updating crates.io index
  Installing rustyvibes v1.0.9
   Compiling libc v0.2.139
   Compiling proc-macro2 v1.0.49
   Compiling quote v1.0.23
   Compiling unicode-ident v1.0.6
   Compiling syn v1.0.107
   Compiling autocfg v1.1.0
   Compiling pkg-config v0.3.26
   Compiling cfg-if v1.0.0
   Compiling version_check v0.9.4
   Compiling bitflags v1.3.2
   Compiling scopeguard v1.1.0
   Compiling thiserror v1.0.38
   Compiling lock_api v0.4.9
   Compiling memoffset v0.6.5
   Compiling proc-macro-error-attr v1.0.4
   Compiling io-lifetimes v1.0.3
   Compiling alsa-sys v0.3.1
   Compiling parking_lot_core v0.8.6
error: failed to run custom build command for `alsa-sys v0.3.1`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installj00Po2/release/build/alsa-sys-4ca086f333ea3780/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=ALSA_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=ALSA_STATIC
  cargo:rerun-if-env-changed=ALSA_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at '`"pkg-config" "--libs" "--cflags" "alsa"` did not exit successfully: exit status: 1
  error: could not find system library 'alsa' required by the 'alsa-sys' crate

  --- stderr
  Package alsa was not found in the pkg-config search path.
  Perhaps you should add the directory containing `alsa.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'alsa' found
  ', /home/fsevenm/.cargo/registry/src/github.com-1ecc6299db9ec823/alsa-sys-0.3.1/build.rs:13:18
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `rustyvibes v1.0.9`, intermediate artifacts can be found at `/tmp/cargo-installj00Po2`

I have alsa installed.

❯ which alsa
/usr/sbin/alsa

I figured out where the extra CPU was coming from in my previous PR (#10) with threadpools: an active rodio::OutputStream will constantly service callback requests for data from CoreAudio, and the more threads that have an active context, the more CPU usage we'll use. So to tackle that:

1. I found that the threadpool (with more than one thread) was unnecessary in the first place, because using rodio::Sinks enables queuing up multiple sounds on a single OutputStream.
2. In addition, because CoreAudio itself uses a lot of CPU when you have any contexts open at a single time, then I implemented logic to terminate the worker thread (and discard it's rodio context) after 20 seconds of inactivity and start it up again fresh the next time the user pushes a key.

Issue: Some keys such as "ControlRight", "PageDown" , "PageUp" and "media controls" are not given a key-code. The code that handles the "None" branch will cause the spawned thread to panic and no sound will be played.

Solution: To keep the user immersed, un-mapped Keys will fallback to "a".

Additional refactoring: Removed code duplication

Later, I want to actually split the audio file into the downward key press and the release, and then play them separately, but this will at least prevent repeated sounds while holding down a key.

Hello! I tried Rustyvibes on Arch Linux with Wayland (SwayWM) and for first time when I ran in terminal (of course after compiling from source code) I thought sound doesn't work, but when I switched to Discord window I heard sounds. I just didn't hear anything in terminal, I heard sounds only in Discord window.