Maybe I made a little discovery. Looking better in lspci, when the device is plugged-in, I noticed this specific string here below:
[xx:xx.x]Non-VGA unclassified device: Device 1d4b:a181 (rev 01)
(obviously, “xx:xx.x” it’s not meant to be the real physical address).
So, I thought in linux, thunderbolt is strictly linked to the “video side”, more than audio.
It’s like is expecting some video flux instead an audio one.
Maybe is something more complex than a “simple” (SIGH!) attempt to set ALSA/PipeWire/WirePlumber and so on.
But… I thought another thing too…
Some services, as Wireplumber seems to have no service (“systemctl status wireplumber” gives: Unit wireplumber.service could not be found.).
The same is for boltd: bash: boltd: command not found.
Restarting services is futile (indeed, no service found!).
Anyway, maybe I guess to have understood a little thing: in ALSA, I need to concentrate on the thunderbolt controller instead the device itself. Indeed, Pipewire shows a list of controller (but thunderbolt not yet) and then every ports “owned” by the controller itself.
I tried to reinstall the daemon for thunderbolt and to enable it but:
[user@hostname ~]$ sudo systemctl enable bolt
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.
Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Maybe I have to create a symlink for ALSA or Pipewire/wireplumber?
Still on this!
Being a noob, I’m discovery only now some (for me) new commands to admin the system.
So, after trying some EFI settings abour BAR and IOMMU without succes, I just tried to check if some dependencies could missing but I still have to say that for the system, everithing is running and working but can’t use the interface with thunderbolt connection (ALSA still can’t “see” it).
Anyway, here is the result for systemctl list-dependencies bolt.service:
[user@hostname ~]$ sudo systemctl list-dependencies bolt.service
[sudo] password di [user]:
bolt.service
● ├─-.mount
● ├─dbus.socket
● ├─system.slice
● ├─tmp.mount
● └─sysinit.target
● ├─dev-hugepages.mount
● ├─dev-mqueue.mount
● ├─kmod-static-nodes.service
○ ├─ldconfig.service
● ├─lvm2-lvmpolld.socket
● ├─lvm2-monitor.service
● ├─proc-sys-fs-binfmt_misc.automount
● ├─sys-fs-fuse-connections.mount
● ├─sys-kernel-config.mount
● ├─sys-kernel-debug.mount
● ├─sys-kernel-tracing.mount
● ├─systemd-ask-password-console.path
● ├─systemd-binfmt.service
○ ├─systemd-boot-random-seed.service
○ ├─systemd-firstboot.service
○ ├─systemd-hibernate-clear.service
○ ├─systemd-hwdb-update.service
○ ├─systemd-journal-catalog-update.service
● ├─systemd-journal-flush.service
● ├─systemd-journald.service
○ ├─systemd-machine-id-commit.service
● ├─systemd-modules-load.service
○ ├─systemd-pcrmachine.service
○ ├─systemd-pcrphase-sysinit.service
○ ├─systemd-pcrphase.service
● ├─systemd-random-seed.service
○ ├─systemd-repart.service
● ├─systemd-sysctl.service
○ ├─systemd-sysusers.service
● ├─systemd-timesyncd.service
● ├─systemd-tmpfiles-setup-dev-early.service
● ├─systemd-tmpfiles-setup-dev.service
● ├─systemd-tmpfiles-setup.service
○ ├─systemd-tpm2-setup-early.service
○ ├─systemd-tpm2-setup.service
● ├─systemd-udev-trigger.service
● ├─systemd-udevd.service
○ ├─systemd-update-done.service
● ├─systemd-update-utmp.service
● ├─cryptsetup.target
● │ └─systemd-cryptsetup@luks\x2dc8d52c84\x2da442\x2d4289\x2d84b6\x2d4c6403ebc97a.service
● ├─integritysetup.target
● ├─local-fs.target
● │ ├─-.mount
● │ ├─boot-efi.mount
● │ ├─home.mount
● │ ├─swap.mount
● │ ├─systemd-remount-fs.service
● │ ├─tmp.mount
● │ ├─var-cache.mount
● │ └─var-log.mount
● ├─swap.target
● │ └─swap-swapfile.swap
● └─veritysetup.target
I can’t fully understand what are referring those white dots…
Other command I tried is:
[user@hostname ~]$ boltctl config --describe xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
boltctl config: error: unknown class 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
Try "boltctl config --help" for more information.
Being not sure to have write correctly, I used parenthesys to write the device’s address and the result was this:
[user@hostname ~]$ boltctl config --describe [xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx]
boltctl config: error: unknown class '3'
Try "boltctl config --help" for more information.
Or maybe I need to set something between these:
[user@hostname ~]$ boltctl config --describe
r- global.version D-Bus API revision.
r- global.probing Is the daemon processing new devices?
r- global.default-policy Policy to use if none was specified.
r- global.security-level The global security level.
rw global.auth-mode Current authentication mode.
r- global.power-state Current force power state.
r- domain.uid The unique identifier.
r- domain.id The sysfs name.
r- domain.syspath Sysfs path of the udev device.
r- domain.security The security level set in the BIOS.
rw domain.bootacl Pre-boot access control list (uuids).
r- domain.iommu Is IOMMU based DMA protection active?
r- device.uid The unique identifier.
r- device.name Human readable device name.
r- device.vendor The name of the device vendor
r- device.generation The generation of the controller chip.
r- device.type The type, i.e. host or peripheral.
r- device.status The device status.
r- device.authflags Flags describing the authentication state.
r- device.parent Unique identifier of the parent.
r- device.syspath The sysfs path of the udev device.
r- device.domain Unique id of the corresponding domain.
r- device.conntime When was the device connected?
r- device.authtime When was the device authorized?
r- device.linkspeed The speed to the parent
r- device.stored Is the device recorded in the database?
rw device.policy What to do when the device is connected?
r- device.key State of the device key.
r- device.storetime When was the device stored?
rw device.label The name given by bolt or the user.
I found this topic on LinuxMusicians: https://linuxmusicians.com/viewtopic.php?t=21680
I have to get a little specific on how thunderbolt works on windows: being a a non-native thunderbolt connection (so, not directly integrated in the motherboard) being my interface connected im pci card, windows need a “bridge” to bring audio data from the device to the d.a.w.
So, I was thinking that Pipewire or Jack could do it. Then, I found this: https://github.com/rxrbln/thunderbolt-utils.
This involve vfio but it’s a little hard for me understand how to use it.
Someone is able to explain?