Closed playaspec closed 2 years ago
Hi,
[76/80] Generating ALSAHwdep-0.0.gir with a custom command
g-ir-scanner: link: x86_64-linux-gnu-gcc -pthread -o /opt/alsa-gobject-0.2.0/build/tmp-introspectbm236ozt/ALSAHwdep-0.0 /opt/alsa-gobject-0.2.0/build/tmp-introspectbm236ozt/ALSAHwdep-0.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/opt/alsa-gobject-0.2.0/build/src/hwdep -Wl,-rpath,/opt/alsa-gobject-0.2.0/build/src/hwdep -lalsahwdep -lgobject-2.0 -lglib-2.0 -ludev -lgirepository-1.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0
../src/hwdep/alsahwdep-enum-types.h:10: Warning: ALSAHwdep: symbol='SNDRV_HWDEP_IFACE_LINE6': Unknown namespace for symbol 'SNDRV_HWDEP_IFACE_LINE6'
../src/hwdep/alsahwdep-enum-types.h:16: Warning: ALSAHwdep: symbol='SNDRV_HWDEP_IFACE_FW_MOTU': Unknown namespace for symbol 'SNDRV_HWDEP_IFACE_FW_MOTU'
../src/hwdep/alsahwdep-enum-types.h:17: Warning: ALSAHwdep: symbol='SNDRV_HWDEP_IFACE_FW_FIREFACE': Unknown namespace for symbol 'SNDRV_HWDEP_IFACE_FW_FIREFACE'
I can regenerate the warnings in my build environment for Ubuntu 20.04. It comes from g-ir-scanner to parse src/hwdep/alsahwdep-enum-types.h
for generation of ALSAHwdep.typelib
and ALSAHwdep.gir
.
As you note, it's inconsequential. It's successful to generate shared library (libalsahwdep.so.0.2.0), so the warnings are relevant to gobject-introspection metadata, which is important to language bindings such as PyGobject and alsa-gobject-rs. And the metadata is successfully generated as expected.
In the file, below macros are detected by the scanner for the warnings:
$ cat src/hwdep/alsahwdep-enum-types.h
...
#if LINUX_VERSION_CODE < KERNEL_VERSION(4,9,0)
#ifndef __GTK_DOC_IGNORE__
#define SNDRV_HWDEP_IFACE_LINE6 (SNDRV_HWDEP_IFACE_FW_TASCAM + 1)
#endif
#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(4,12,0)
#ifndef __GTK_DOC_IGNORE__
#define SNDRV_HWDEP_IFACE_FW_MOTU (SNDRV_HWDEP_IFACE_LINE6 + 1)
#define SNDRV_HWDEP_IFACE_FW_FIREFACE (SNDRV_HWDEP_IFACE_FW_MOTU + 1)
#endif
#endif
...
I've been investigating, but at present, I have no idea to suppress the wanings... When I found any solution to it, let me fix the issue.
Running on a Mac Pro 4,1, using a MOTU 828mkII.
Perhaps these warnings are inconsequential, but I figured I'd report them since it may affect my hardware. Happy to provide more info and testing.
Thanks for your care. For your information, I note that current implementation of snd-firewire-motu-ctl-service
in snd-firewire-ctl-services doesn't have the function to operate CueMix
. The service program just supports the functions in MOTU Audio console
at present.
Additionally, changing the mode of optical interfaces by the service program brings trouble to PipeWire runtime since the combination of PCM channels at any rate is changed, against cache in the runtime. In the case, I use standard Linux kernel interface for bind/unbind functionalities in sysfs
node to emulate hot-plugging and hot-unplugging without physically operations, like:
$ sudo -i
# echo fw1.0 > /sys/bus/firewire/drivers/snd_firewire_motu/unbind
# echo fw1.0 > /sys/bus/firewire/drivers/snd_firewire_motu/bind
At a commit 7e6b558274a4 ("ctl/timer/seq: optimization for GLib v2.68"), this issue is solved by introduction of conditional macro for g_memdup2().
Tried both git version and the 0.2.0 tar file. System is Ubuntu Studio 20.04.02 Kernel 5.8.0-59-lowlatency. ALSA: alsa-base 1.0.25+dfsg-0ubuntu5, Pulseaudio 1:13.99.1-1ubuntu3.11, pipewire 0.3.31-3~ubuntu20.04, jack2 1.9.14-0ubuntu2
Running on a Mac Pro 4,1, using a MOTU 828mkII.
Perhaps these warnings are inconsequential, but I figured I'd report them since it may affect my hardware. Happy to provide more info and testing.