Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux file operation error: , Dependent information directory is missing #187

Open
TeamB12 opened this issue Jul 10, 2024 · 24 comments
Open
Assignees
Labels
bug Something isn't working

Comments

@TeamB12
Copy link

TeamB12 commented Jul 10, 2024

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.

@TeamB12 TeamB12 changed the title Tascam FW-1884 Linux file operation error: , Dependent information directory is missing Jul 10, 2024
@takaswie takaswie self-assigned this Jul 10, 2024
@takaswie
Copy link
Member

takaswie commented Jul 10, 2024

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 takaswie added the question Further information is requested label Jul 10, 2024
@takaswie
Copy link
Member

takaswie commented Jul 10, 2024

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
Copy link
Author

TeamB12 commented Jul 11, 2024

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

TeamB12 commented Jul 12, 2024

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

TeamB12 commented Jul 15, 2024

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�[0m�[2m=�[0mErr(Error { domain: g-file-error-quark, code: 6, message: "No flag detected: val: 0x000000e7 mask: 0x0000008c" })

@takaswie
Copy link
Member

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)?;

@takaswie takaswie added bug Something isn't working and removed question Further information is requested labels Jul 16, 2024
@TeamB12
Copy link
Author

TeamB12 commented Jul 19, 2024

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
Copy link
Member

if you need, I can send the error message.

Yes, please, with the log outputs.

@TeamB12
Copy link
Author

TeamB12 commented Jul 20, 2024

/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
Copy link
Author

TeamB12 commented Jul 20, 2024

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
Copy link
Member

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
Copy link
Author

TeamB12 commented Jul 21, 2024

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
Copy link
Member

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
Copy link
Author

TeamB12 commented Jul 21, 2024

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
Copy link
Author

TeamB12 commented Jul 21, 2024

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
Copy link
Member

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
Copy link
Author

TeamB12 commented Jul 22, 2024

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
Copy link
Member

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
Copy link
Author

TeamB12 commented Jul 28, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants