(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:
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 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?
Another problem that logs show out is the codec not found (maybe a possible solution is described in the web page above, section “Codec-Probing Problem”) but I think this could be a little more complicated for me…
Edit: The arch wiki for me leaves a lot out and one has to try to decipher too many things that are unknown by even experienced arch users. I’m not sure where you would add those options? Maybe /etc/modprobe.d/alsa-base.conf but I don’t know … just taking a stab in the dark. It would be much easier if one had the hardware to try to figure it out. So you’re going to have to keep working at it by trial and error and research since you have the hardware to work with.
I’m no expert just trying to point you in some direction whether it’s the right direction I’m not sure.