Hi, On Mon, Nov 30, 2020 at 06:21:38AM +0900, Susie B. wrote: > Now I've installed snd-firewire-ctl-services finally with kernel 5.4, > though I have two problems with its running and I'd like to be given help > about them. > > First of all I must apologize to Sakamoto-san for the time he took in > dealing with the 4.x kernel. With 4.9 or 4.19 kernels, I got some > warnings on MOTU/TASCAM in the build of libhinawa and failed the build > of snd-firewire-ctl-services. Seemingly they were caused by the short > of MOTU/TASCAM support in the source of these kernels. So I had to move > to the 5.4 kernel. If it is helpful with the development of libhinawa > or snd-firewire-ctl-services, I'll make another post about the failure. I'm sorry to be careless about kernel version dependency of libhinawa. Yes, libhinawa is not buildable for older kernels due to dependency of UAPI of Linux kernel v4.4 or before, as the same reason that you failed to build alsa-gobject. It should be better to create new libhinawa release including. > I would like to move on to my problems. > > Though there were some warnings, I could install snd-firewire-ctl-services: > > root@darkstar:/tmp/snd-firewire-ctl-services-master# cargo build > warning: variant is never constructed: `DisplayClear` > --> libs/oxfw/src/apogee_proto.rs:26:5 > | > 26 | DisplayClear, > | ^^^^^^^^^^^^ > | > = note: `#[warn(dead_code)]` on by default > > warning: 1 warning emitted > > warning: field is never read: `firmware_version` > --> libs/motu/src/model.rs:17:5 > | > 17 | firmware_version: u32, > | ^^^^^^^^^^^^^^^^^^^^^ > | > = note: `#[warn(dead_code)]` on by default > > warning: 1 warning emitted > > Compiling snd-firewire-ctl-services v0.1.0 (/tmp/snd-firewire-ctl-services-master/services) > Finished dev [unoptimized + debuginfo] target(s) in 9.65s The build command looks to finish successfully, so you can find the executable binary of 'snd-fireworks-ctl-service' under 'target/debug' directory (/tmp/snd-firewire-ctl-services-master/target/debug/snd-fireworks-ctl-service). It's not installed yet in your system, but it's enough to start testing via cargo, or run directly. Your current working directory should be '/tmp/snd-firewire-ctl-services' so that 'cargo' command can find the executable binary when working with cargo, therefore: > So I started testing it, and got the first problem. > I mean that Only root user in login shell can start it with "cargo run" > command in its build directory. > > At first, I tried "snd-fireworks-ctl-service" and "cargo --run ..." command as a non-root user; > > [~]$ snd-fireworks-ctl-service 2 > bash: snd-fireworks-ctl-service: command not found > > [~]$ cargo run --bin snd-fireworks-ctl-service 2 > error: could not find `Cargo.toml` in `/home/of_mine` or any parent directory They are not appropriate operations. > next "cargo --run" again in its build directory; > > [snd-firewire-ctl-services-master]$ cargo run --bin snd-fireworks-ctl-service 2 > error: failed to open: /tmp/snd-firewire-ctl-services-master/target/debug/.cargo-lock > > Caused by: > Permission denied (os error 13) This is appropriate, however access permission is not expected. I guess two reasons: 1. the .cargo-lock have already created by super user. 2. mount option for /tmp is strict, depending on Linux distribution. It's better to look for and resolve the cause, instead of trials and errors. I think it better to clone repository in your home directory instead of /tmp. > with sudo; > > [snd-firewire-ctl-services-master]$ sudo cargo run --bin snd-fireworks-ctl-service 2 > ... > --- stderr > `"pkg-config" "--libs" "--cflags" "alsatimer" "alsatimer >= 0.0"` did not exit successfully: exit code: 1 > --- stderr The pkg-config[1] helps to get information easily about shared library installed in system according to pkg-config files (*.pc). Many libraries supports it and the libraries in alsa-gobject/libhinawa supports it as well. When pkg-config command failed to find the file, the file is missing by priviledge to run the command, or places in unexpected directory. [1] https://people.freedesktop.org/~dbn/pkg-config-guide.html > and finally as root in login shell, I could start it: > > [snd-firewire-ctl-services-master]$ sudo su -l > ... > root@darkstar:/tmp/snd-firewire-ctl-services-master# cargo run --bin snd-fireworks-ctl-service 2 > Compiling snd-firewire-ctl-services v0.1.0 (/tmp/snd-firewire-ctl-services-master/services) > ... > Finished dev [unoptimized + debuginfo] target(s) in 2m 38s > Running `target/debug/snd-fireworks-ctl-service 2` > > But It is time-consuming for my poor cpu to execute the build process in every start. > I'd like to start the service with "snd-fireworks-ctl-service" command as a > non-root user without runtime build at any other place than its build directory, if I can. Hm. I designed that the service programs can run in normal user priviledge as long as the user can access ALSA and firewire character devices (/dev/snd/* and /dev/fw*). Furthermore, cargo is brilliant tool so that rebuild doesn't run as long as sources are not changed. I guess that the cause to run rebuild is update of dependent crates. For example, one week before I released alsa-gobject-rs v0.2.0[2]. [2] https://github.com/alsa-project/alsa-gobject-rs/releases/tag/v0.2.0 > Anyway next I tried to operate my AudioFire4. > I could see its control sets: > > [~]$ amixer -c 2 info > ... > [~]$ amixer -c 2 scontrols > Simple mixer control 'enable-mixer',0 > ... > Simple mixer control 'stream-playback-routing',0 > > But I only could set 'phantom-powering'. I guess that the bug issued at PR#23[2] causes your issue. I carelessly added the bug that any change for control element with multiple values is not operated appropriately, and now it's fixed. [2] https://github.com/alsa-project/snd-firewire-ctl-services/pull/23 > Additionaly with the QasMixer, a GUI mixer app, I could see the input/output meter > indicated the signal level, but that was all. This is the second problem. > > Have I made any mistakes in above steps? Or were there other things which I should > have done? I think my AF4's hardware is not the problem because it works well with > ffado (,but which I wouldn't like to use for several reason. Of course I had > uninstalled the libffado before the operation test.) > I'd appreciate any advice or information to solve these problems. I suggest some points: 1. clone the repository by normal user into your home directory instead of /tmp 2. run cargo build by the normal user 3. check access permission to /dev/snd/* and /dev/fw* before running the executable binary 4. run cargo run in the cloned directory or run the executable directly by the normal user The service programs are not so special, usual programs. No priviledge is required to run the programs as long as the user has enough access permission to ALSA and firewire character devices. > I'd like to post the install log of alsa-gobject and libhinawa ,if it is also needed. > (I didn't put them in this post because I afraid they make this post far too long.) If you'd like to install libhinawa in Linux kernel v5.3 or former, we need to add changes to libhinawa and create new release. In the case, the log will be helpful for the work, but not planned yet. Thanks Takashi Sakamoto _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
