Linux file operation error: , Dependent information directory is missing

[TeamB12]

snd-oxfw-service is working great, I can control the Apogee audio interface. snd-firewire-tascam-cl-service not starting. Error message: Linux file operation error: , Dependent information directory is missing Is there any information how to package, install and use it? I just copied the service file first and then the service.d file. Which number exactly do I need to specify the audio interface? With snd-oxfw-service, I can get the number from aplay -l I understand, this is a user question, I do not know where to ask, then here - sorry.

[takaswie]

Hi,

I'm sorry for your inconvenience, and thank you to use this software.

snd-oxfw-service is working great, I can control the Apogee audio interface. snd-firewire-tascam-cl-service not starting. Error message: Linux file operation error: , Dependent information directory is missing Is there any information how to package, install and use it? I just copied the service file first and then the service.d file. Which number exactly do I need to specify the audio interface? With snd-oxfw-service, I can get the number from aplay -l I understand, this is a user question, I do not know where to ask, then here - sorry.

Hm. The error message implied that the command line argument is not what is expected. I think the service program parsed the identification information for the Apogee audio interface to which you addressed, not for TASCAM FW-1884.

Unlike snd-oxfw-ctl-service, the snd-firewire-tascam-ctl-service requires two arguments due to the support of TASCAM FE-8.

$ ./target/debug/snd-firewire-tascam-ctl-service -h
Usage: snd-firewire-tascam-ctl-service [OPTIONS] <SUBSYSTEM> <SYSNUM>

Arguments:
  <SUBSYSTEM>  The name of subsystem; 'snd' or 'fw'
  <SYSNUM>     The numeric identifier of sound card or firewire character device

Options:
  -l, --log-level <LOG_LEVEL>  The level to debug runtime, disabled as a default [possible values: debug]
  -h, --help                   Print help

With TASCAM FW-1884, the pair of snd and the numeric identifier of sound card in ALSA is required. Assuming snd-firewire-tascam module is loaded and your FW-1884 is registered as sound card 2, then the following command line is adequate:

$ ./target/debug/snd-firewire-tascam-ctl-service snd 2

You can see the numeric identifier as sound card in the following procfs node beforehand:

$ cat /proc/asound/cards
 0 [Generic        ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfcc88000 irq 130
 1 [Generic_1      ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfcc80000 irq 131
 2 [FireOne        ]: OXFW - FireOne
                      TASCAM FireOne (OXFW971 0105), GUID 00022e0200000007 at fw1.0, S400

My TASCAM FireOne is detected as sound card 2, just for example.

[takaswie]

Is there any information how to package, install and use it?

You can see the instruction in Install executables subsection of top-level README.md. In the case of snd-firewire-tascam-ctl-service, the following command installs the executable under ~/.cargo/bin:

$ cargo install --path runtime/tascam

The installed executable can be uninstalled by the following command:

$ cargo uninstall -p snd-firewire-tascam-ctl-service

They are the standard step given by cargo command. In detail, please refer to the manual of cargo command.

[TeamB12]

Thank you very much for your fast reply. I did as you said, now I have a new error message:

/usr/bin/snd-firewire-tascam-ctl-service snd 4

Linux file operation error: , No flag detected: val: 0x000000e7 mask: 0x0000008c Of course I know how to build and install, it is written in the readme. Problem is, that I am only installing with my package manager, so I am packaging libhinawa, libhitaki and the snd-firewire-services. In thr Arch Linux build script cargo install --path runtime/tascam is resulting in an empty Arch Linux binary package. So, I am installing my selfmade Arch package, that was build with the command: install -Dm0755 target/release/snd-firewire-tascam-ctl-service "${pkgdir}/usr/bin/snd-firewire-tascam-ctl-service"

install -Dm0755 target/release/snd-firewire-tascam-ctl-service.d "${pkgdir}/usr/bin/snd-firewire-tascam-ctl-service.d"

If I am wrong, I am sorry - the same Arch package that I made is working with the Apoggee Duet, so I guessed, my build scripts are ok and the Tascam-service is having some issues. Connecting the Tascam FW-1884 with jack server is not easy and a lil random: only -n3 -p256 is working FFADO is not supporting it, as it seems.

Again, thank you for your great work on the firewire stack. Here, I am using The TC Audio Konnekt24D, the Saffire 24, the Digi 002, and two Apogee Duetand of course the Tascam FW-1884. If you need some day some one to do some testing, I would do so if asked.

[takaswie]

Hi,

I did as you said, now I have a new error message:

/usr/bin/snd-firewire-tascam-ctl-service snd 4

Linux file operation error: , No flag detected: val: 0x000000e7 mask: 0x0000008c

Hm. It seems that the value of address offset at 0x'ffff'0000'022c is not expected. I guess that it relates to the configuration of optical interface for FW-1884 according to the output.

In snd-firewire-tascam-ctl-service program, the access to the address offset for the purpose is for struct TascamOpticalIfaceParameters data. Would I ask you to retrieve debug logs and check it? All of service programs have ---log-level command line option. At present, debug is available as a value of the option, like:

/usr/bin/snd-firewire-tascam-ctl-service --log-level=debug snd 4

[takaswie]

I'm not an user of Arch Linux, but I have some opinions.

Problem is, that I am only installing with my package manager, so I am packaging libhinawa, libhitaki and the snd-firewire-services. In thr Arch Linux build script cargo install --path runtime/tascam is resulting in an empty Arch Linux binary package.

Hm. The command, cargo install --path runtime/tascam, installs snd-firewire-tascam-ctl-service executable under ~/.cargo/bin directory. I think the addresses 'Arch Linux build script' requires the other destination to install it. If so, it is worth to investigate 'cargo install' command about the explicit option for it.

So, I am installing my selfmade Arch package, that was build with the command: install -Dm0755 target/release/snd-firewire-tascam-ctl-service "${pkgdir}/usr/bin/snd-firewire-tascam-ctl-service"

install -Dm0755 target/release/snd-firewire-tascam-ctl-service.d "${pkgdir}/usr/bin/snd-firewire-tascam-ctl-service.d"

If I am wrong, I am sorry - the same Arch package that I made is working with the Apoggee Duet, so I guessed, my build scripts are ok and the Tascam-service is having some issues.

I expect the snd-firewire-tascam-ctl-service executable does not dependent on snd-firewire-tascam-ctl-service.d, thus the first install(1) command would be enough.

[takaswie]

Connecting the Tascam FW-1884 with jack server is not easy and a lil random: only -n3 -p256 is working FFADO is not supporting it, as it seems.

I know that all of drivers in ALSA firewire stack including snd-firewire-tascam kernel module have some trouble with jackd(1) process since the part of jackd(1) to handle ALSA device is a bit old-fashioned. I've mainly used Pipewire to test them, but within next few years I work for them to improve jackd(1) affinity after working for Linux FireWire subsystem itself.

Here, I am using The TC Audio Konnekt24D, the Saffire 24, the Digi 002, and two Apogee Duetand of course the Tascam FW-1884. If you need some day some one to do some testing, I would do so if asked.

Thanks for your offer. I own all of them as test devices but double check is always preferable ;)

[TeamB12]

Yes, I will read about the cargo build system. Started with hinawa-utils maybe 3 years ago and switched to snd-firewire-services a year ago with v.0.10 Now I have updated to v0.20 - the package used was the git master zip file not the v0.20 from release section. First the debug version was built. so my build script is focusing on the normal no debug version - it seems much smaller: cargo build --release Will built and install the debug version, must wait for the night for the nightly build ;) Another audio interface is connected to the ADAT IN of the Tascam FW-1884. So, after I disconnected the other audio interface, now, there is another error message:

Linux file operation error: , Fail to generate seq devname

After trying again, the error message changed:

Unknown domain error: , no ack (The comma is no typo)

[takaswie]

Another audio interface is connected to the ADAT IN of the Tascam FW-1884.
So, after I disconnected the other audio interface, now, there is another error message:

Linux file operation error: , Fail to generate seq devname

After trying again, the error message changed:

Unknown domain error: , no ack
(The comma is no typo)

These messages are generated in runtime/core/src/cmdline.rs, but is not well formatted yet.

Nevertheless, the first error is a bit odd since it means that ALSA sequencer is not visible by udev mechanism. If just disconnecting devices, it does not usually occur. I have no idea about it...

The second message is Hinawa.FwRcode.NO_ACK. I think to encounter a quirk of FW_1884. The device sometimes corrupts its communication over IEEE 1394 bus when the bus configuration changes. In this situation, we need to power-off the device once, then power-on it to reboot its firmware.

[takaswie]

Now I have updated to v0.20 - the package used was the git master zip file not the v0.20 from release section.

The -l, --log-level option is specific to all of service programs, and provided since v0.2.0 release, so no need to rebuild it.

[TeamB12]

Got the "log", attached it to this message - the log is quite long and has much repeatings. debug.txt Maybe my FW-1884 is broken, it does not allways powers on reliable. There is again an error message about optical in, but I am quite sure, Ihave disconnected the optical cable upfront. The final line seems to be:

[3mres=Err(Error { domain: g-file-error-quark, code: 6, message: "No flag detected: val: 0x000000e7 mask: 0x0000008c" })

[takaswie]

2024-07-14T19:10:09.738007Z DEBUG cache: snd_firewire_tascam_ctl_service::isoch_ctls: params=TascamOpticalIfaceParameters { capture_source: Optical, output_source: StreamInputPairs } res=Err(Error { domain: g-file-error-quark, code: 6, message: "No flag detected: val: 0x000000e7 mask: 0x0000008c" })

As I guessed, the value read from 0x'ffff'0000'022c is not expected for the service program. The following values are what the program expects, however we got 0xe7.

• 0x00000080
• 0x00000004
• 0x00000088
• 0x00000008

https://github.com/alsa-project/snd-firewire-ctl-services/blob/master/protocols/tascam/src/isoch/fw1884.rs#L72

Tentatively, let us suppress the reading and parsing of the address offset. The service program would run successfully, then let us work for further debugging.

$ git diff
diff --git a/runtime/tascam/src/fw1884_model.rs b/runtime/tascam/src/fw1884_model.rs
index a236130e..5e6cd5a5 100644
--- a/runtime/tascam/src/fw1884_model.rs
+++ b/runtime/tascam/src/fw1884_model.rs
@@ -142,7 +142,7 @@ impl CtlModel<(SndTascam, FwNode)> for Fw1884Model {
             .cache(&mut self.req, node, TIMEOUT_MS)?;
         self.coax_output_ctl
             .cache(&mut self.req, node, TIMEOUT_MS)?;
-        self.opt_iface_ctl.cache(&mut self.req, node, TIMEOUT_MS)?;
+        //self.opt_iface_ctl.cache(&mut self.req, node, TIMEOUT_MS)?;
         self.specific_ctl.cache(&mut self.req, node, TIMEOUT_MS)?;
         self.console_ctl.cache(&mut self.req, node, TIMEOUT_MS)?;

[TeamB12]

The workaround is not helping here, neither. I did as you said: Git cloned, edited the one file and the build was sucsessfull. Still, not working here - if you need, I can send the error message. But I want to wait for the solution then working around it.

[takaswie]

if you need, I can send the error message.

Yes, please, with the log outputs.

[TeamB12]

/usr/bin/snd-firewire-tascam-ctl-service snd 4 -l debug is bringing the error message: Linux file operation error: , Fail to generate seq devname

[TeamB12]

Built again, this time the debug from git clone - and it is working now: The QasMixer is showing now all the ins and outs. Please - one last question: I can not find the isochronous mode switch. When going into the settings for the device in QasMixer, there are all the switches listed - but no isochronous mode switch.

[takaswie]

Linux file operation error: , Fail to generate seq devname

Hm. I expect the system has a character device of /dev/snd/seq added by 'snd-seq' kernel module. I guess that the kernel module is not loaded when facing the error?

[TeamB12]

Making music with midi here - jackmidi, bridged to alsa midi sequencer. I have not removed or blacklisted the snd-seq module and I never missed it, so I think it was there, when I tried.

modinfo snd-seq

filename: /lib/modules/6.7.0.6.realtime1-4-rt/kernel/sound/core/seq/snd-seq.ko.zst alias: devname:snd/seq

Can you please, let me know about isochronous mode - thank you!

[takaswie]

Making music with midi here - jackmidi, bridged to alsa midi sequencer. I have not removed or blacklisted the snd-seq module and I never missed it, so I think it was there, when I tried.

Hmm. It seems that we have the other causes to get the 'Fail to generate seq devname' issue, while I have no idea about it at present...

Can you please, let me know about isochronous mode

I'm sorry but I can not get to what the 'isochronous mode' points... Would I ask you to explain its functionality?

[TeamB12]

As I understood - on "hardware communication" level, the data stream of the Tascam can be split into control/midi data and pcm audio stream data. This can be done in Tascam's isochronous mode. This way, I hope to connect the Tascam FW-1884 by firewire and then I want to control my DAW audio midi sequencer software.

[TeamB12]

Update: the tascam service does not seem reliable here. Did some testing again and this time, the service did not start nor give a log message. After connecting with jack, the service starts and gives some debug messages, too.

[takaswie]

As I understood - on "hardware communication" level, the data stream of the Tascam can be split into control/midi data and pcm audio stream data. This can be done in Tascam's isochronous mode.

The snd-firewire-tascam-ctl-service is programmed to retrieve and process these status and control messages as well as MIDI messages from kernel space in a condition that the incoming isochronous packet has begun. Usually, the runtime of ALSA PCM substream is responsible for it. In your case, jackd(1) cannot start it successfully, thus the services are not available in your side.

I think it better to use either Pipewire or PulseAudio for your trial. Pipewire provides compatible API library for JACK applications. It is transparently enabled when adding system configuration for ld.

[TeamB12]

Thanks for all the info. Do you think, the "bug" that we are now working around, will be fixed, soon? I ve tried pipewire and also pulseaudio, and itseems, that pure jack or alsa are most stable . Running Jack clients here - I need jack. also, sometimes I need best possible latency and real time performance - pulseaudi and pipewire are not that efficient and fast, as it appeared to me. I am getting everything wrong: I thought pipewire (which is a great software for desktop users) is not well suited for lowlatency music projects because the buffersize is continously changing; variable bit rates ... You helped alot, thanks.

[takaswie]

Hi @TeamB12,

I'm investigating the cause of issue reported to this topic. Today I worked with my FW-1884 and found nothing specific related to the issue.

Would I ask you the firmware version installed in your device? When loading snd-firewire-tascam kernel module, the version information is exposed to user space via node of procfs, like:

$ cat /proc/asound/card2/firewire/firmware 
Register: 20 (0x00000014)
FPGA:     49 (0x00010031)
ARM:      183 (0x000100b7)
Hardware: 3 (0x00030000)

[TeamB12]

The Tascam device I am using might be broken: sometimes I can not start jack server, sometimes aplay -l is seeing it, but mixxx is not. Also jack can only connect in mromal mode, realtime is not working with the Tascam. Sometimes, after powering on (happened 2 times now), all lights are on and the device is in a locked state. Here is the firmware:

cat /proc/asound/card4/firewire/firmware Register: 20 (0x00000014) FPGA: 49 (0x00010031) ARM: 183 (0x000100b7) Hardware: 3 (0x00030000)

sama sama