Unknown symbol in module

[RyanHarvieStark]

I built this on Arch Linux kernel 6.4.11. I used the fix of kernel functions change and it seemed to build fine but then I get this:

insmod: ERROR: could not insert module sound/pci/hdsp/hdspe/snd-hdspe.ko: Unknown symbol in module

[jimfrench]

Could you post your output of

cat /proc/version

[RyanHarvieStark]

OK. Here it is:

Linux version 6.4.11-arch2-1 (linux@archlinux) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.41.0) #1 SMP PREEMPT_DYNAMIC

Just to add an update. That Unkown symbol in module happens when I blacklist snd-hdspm. If I don't do this I can then use the driver. All channels appear, hdspeconf functions and even the RME mixer but then other issues. I have one mono channel of working audio that requires huge latency to even remotely playback.

When I try to load the driver and get Unknown symbol in module, if I do:

dmesg | tail

I get this:

[ 440.233482] snd_hdspe: Unknown symbol snd_rawmidi_receive (err -2) [ 440.233489] snd_hdspe: Unknown symbol snd_rawmidi_transmit_empty (err -2) [ 440.233497] snd_hdspe: Unknown symbol snd_rawmidi_transmit (err -2) [ 440.233649] snd_hdspe: Unknown symbol snd_rawmidi_new (err -2) [ 440.233658] snd_hdspe: Unknown symbol snd_rawmidi_set_ops (err -2)

[RyanHarvieStark]

And to elaborate further. This system is generally not used for audio but I have most of my audio software from OSX replicated here, i.e. Reaper, Bitwig for example. When I just use the provided old RME driver which does get assigned to this card, everything works just very poorly. With the motherboard sound chip everything works flawlessly even low latency but obviously poor quality. I have had jack, pulse audio and pipeline all functioning well with onboard sound chip.

[jimfrench]

Thanks for the info. Looks odd behaviour. Which model RME card is it ?

My first thought in response to your first question was GCC version compared to the version that was used to compile the kernel, because this has been known to cause odd issues. Are you using GCC 13.2.1 to compile the driver and/or is that the only version available on the system.

But your later comments suggest another cause

[RyanHarvieStark]

It's the HDSPe AES card. I had it hooked to a Mytek convertor with AES but in an external Thunderbolt box on a Mac Mini. My findings were that this RME card set up this way is absolutely rock solid. Better than any other interface I used.

I have gcc-13.2.1-3. That's the only version available.

[RyanHarvieStark]

The latest update is that when I do get the driver "working" without blacklisting snd-hdspm it fails everywhere except Reaper which works really well. I was testing with Bitwig before. All ins/outs working and at low latency in Reaper when connect to Alsa. I have some MIDI stuck notes but this has always been an issue with Reaper hence why I stopped using it.

Elsewhere on the system the old driver seems to be appearing. That's nowhere to be seen in Reaper. It works the way you would expect. There are probably a lot of clashes going on with configuration on this system. I also have Pipewire on here instead of Pulseaudio.

Surely I need to be able to blacklist that old driver.

[jimfrench]

It's certainly a good card it's one I use too :)

I haven't seen those errors before with RME driver. Sometimes unknown symbol errors in general are caused by building the driver against the source of a kernel that is different version to the one that is running at the time of the build. I guess maybe checking that first.

Has the card ever worked properly with this Arch installation / machine, or is this first time setup?

This issue is probably solvable (could see if anyone else chips in...) but in general you've probably answered your own question, that it's nearer userspace /ALSA

And more generally, you may dislike this "answer" but in the past I have found it's just easier to use a distro which is nearer to your application area, which is clearly AV, so for instance AV Linux or Ubuntu Studio, etc

At the very least maybe test other distros temporarily with live booting with the RME driver and your software you would like to use and see if things are easier.

It's 'nice' to build a system from scratch and Arch is very good and I use it myself ... but in my experience I found I spend more time "working" with Arch Linux than doing the work that needed to be done in Arch Linux (Audio) ... both are fun, but IMO it's better to start with a distro that is near your needs, unless you have infinite amounts of time and patience...

It's probably possible to get everything working seamlessly but from what you've said I don't think it's a driver issue as such, so I would set up different testing environments for the AV software you want to use and the RME card, and see what works.

After doing some testing like that you may stumble on the reason for the error and go back and solve it in your current running config but currently it looks hard to diagnose from within it, and possible to be a combination of causes going by what you've said rather than just a driver issue to solve, especially if there is userspace inconsistencies between software etc.

[RyanHarvieStark]

OK. Thanks for the replies.

The card functions totally if i just let it use the old RME driver that gets assigned to it but it's very bad performance in terms of latency.

There is no way I'm giving up Arch because Arch has actually saved me tons of hassle to be honest compared to other distros although I might try booting to another distro for tests. This is the first major problem I have had for ages but I expected it. I would rather just keep the RME on the Mac. This is a shame because I'm going to build a new PC to have better video capability. However, I will still do some more investigation. A clean PC might be the best environment to test the RME again. This system was installed about ten years ago but that's why i love Arch's rolling release.

The annoying thing is that everything performs fantastically just with the motherboard sound chip and Pipewire which I just recently set up. Really low latency. Everything functions so well including DAWs but obviously I need a quality interface to work.

On Wed, 23 Aug 2023 at 18:52, Jim French @.***> wrote:

It's certainly a good card it's one I use too :)

I haven't seen those errors before with RME driver. Sometimes unknown symbol errors in general are caused by building the driver against the source of a kernel that is different version to the one that is running at the time of the build. I guess maybe checking that first.

Has the card ever worked properly with this Arch installation / machine, or is this first time setup?

This issue is probably solvable (could see if anyone else chips in...) but in general you've probably answered your own question, that it's nearer userspace /ALSA

And more generally, you may dislike this "answer" but in the past I have found it's just easier to use a distro which is nearer to your application area, which is clearly AV, so for instance AV Linux or Ubuntu Studio, etc

At the very least maybe test other distros temporarily with live booting with the RME driver and your software you would like to use and see if things are easier.

It's 'nice' to build a system from scratch and Arch is very good and I use it myself ... but in my experience I found I spend more time "working" with Arch Linux than doing the work that needed to be done in Arch Linux (Audio) ... both are fun, but IMO it's better to start with a distro that is near your needs, unless you have infinite amounts of time and patience...

It's probably possible to get everything working seamlessly but from what you've said I don't think it's a driver issue as such, so I would set up different testing environments for the AV software you want to use and the RME card, and see what works.

After doing some testing like that you may stumble on the reason for the error and go back and solve it in your current running config but currently it looks hard to diagnose from within it, and possible to be a combination of causes going by what you've said rather than just a driver issue to solve, especially if there is userspace inconsistencies between software etc.

— Reply to this email directly, view it on GitHub https://github.com/PhilippeBekaert/snd-hdspe/issues/17#issuecomment-1690388819, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJVTXVLDJYJ46F3BMGPCRDXWY7NLANCNFSM6AAAAAA32X5OX4 . You are receiving this because you authored the thread.Message ID: @.***>

[RyanHarvieStark]

What should I actually be seeing when I open an app and select ins outs because this is very strange. One time it's a name with AES which I'd expect, another timer it's MADI, then it's Hammerfall. In Reaper which I can get working it's got HDSPM in the name which is surely wrong again yet I can get everything working in Reaper with clearly better performance than when it's defaulted to the driver supplied with Alsa.

[jimfrench]

Probably best I would say ... it's easy to get buried in complex issues and a fresh start could be good if it's on the plan anyway

A clean PC might be the best environment to test the RME again

Unsure about the channel naming, the application would be choosing what it feels like showing you, so can't really expect consistency between different apps, there might be ways to manually change the naming to be consistent by editing conf files or in the app itself

[RyanHarvieStark]

If I could get to the route of that Unknown symbol snd_rawmidi error that would be a good start.

The other overall problem is of course that the developer of this driver has sadly passed away.

[jimfrench]

If I could get to the route of that Unknown symbol snd_rawmidi error that would be a good start.

Well the symbols that are not being found are ALSA APIs (../sound/rawmidi.h) The snd-hdspe driver is trying to use (../snd-hdspe/blob/main/sound/pci/hdsp/hdspe/hdspe_midi.c 14)

Therfore I don't think the problem is the snd-hdspe driver itself maybe try clean rebuilding You can also do things like check the symbol table e.g. cat /proc/kallsyms | grep 'snd_rawmidi_set_ops'

Also ref https://www.kernel.org/doc/html/next/sound/kernel-api/writing-an-alsa-driver.html#rawmidi-interface

"The raw MIDI interface is used for hardware MIDI ports that can be accessed as a byte stream. It is not used for synthesizer chips that do not directly understand MIDI."

The above might be a reason why the rawmidi apis are not being used by the onboard sound, also that hardware might not be enabled or even exist, which could be why there are no errors with onboard sound (likely by chance, there probably are "issues" waiting to happen elsewhere and also your apps are giving inconsistencies which indicates there are issues with the sound architecture somewhere, with or without snd-hdspe involved.

EDIT: Are you sure there are not many more unknown symbol errors in the kernel ring buffer ? I didn't notice your tail there

[RyanHarvieStark]

There could be more errors. I didn't check. I've downloaded Manjaro. I'll test things there first. I should be able to avoid the card even being assigned the old driver from square one.

[jimfrench]

OK ignore my previous replies about MIDI in particular I was answering too quickly sorry

Good luck with the testing. It might be worth considering using DKMS as that is the recommended approach, also check out the solved issue #8

[RyanHarvieStark]

I just tried this again on Manjaro. The same errors and I looked at the exact errors and it is just those five rawmidi unknown symbols.

This was a totally fresh Manjaro install. I chose Manjaro because it's a version of Arch. So whatever is wrong on my other system is not something I have configured on the system to cause it.

[jimfrench]

Ok thanks the test results, I'll try to do some testing here to reproduce the errors.

[RyanHarvieStark]

It's working now. I installed it with DKMS on Manjaro. I'm testing using Ardour with low latency and no issues. I did try DKMS on the Arch system but something was wrong. I'll try again on Arch but for now I'll compare this driver to the hdspm one which I have working on Arch. Already there appears to be better performance. I don't have all that weird naming of the hardware like I had before but on this clean system, hdspm driver has been blacklisted from the start.

[jimfrench]

OK this is good, I did have a quick look in Arch but ran out of time. If you're happy then we'll leave it there / close the issue.

If you want to look into the Arch / Manjaro differences, maybe have a look at the dkms.conf and also the /etc/modprobe.d/*conf files for clues. Also compare the logs from the DKMS build with the manual build. In general DKMS does a lot of consistency checking before adding a module, becuase it's intended to be an automatic process, re-inserting the kernel module during kernel upgrades, it is careful not to fail for any reason. If DMKS failed on Arch then that could be a few causes and maybe compare its logs between Arch and Manjaro to find out why.

Hope that helps

[RyanHarvieStark]

I just tried inserting the module on Arch Linux without a DKMS install. I had been using the older driver. I don't get that unknown symbol error now. The only difference is a newer kernel. Comparing hdspe to hdspm, I don't really see a lot of difference in performance with this card to be honest.

The showstopper is that the RME has terrible performance with Pipewire and any audio from any application whereas the onboard sound is great for some reason. I've seen somebody else say the same thing with the MADI card. Everything will need to be good with Pipewire in future or it's no go.

[Schroedingers-Cat]

I can confirm that the performance of the hdspe and the hdspm driver with an RME HDSPe MADI in pipewire is absolutely terrible. JACK is your best bet ATM. The pipewire devs stated that old-school ALSA drivers using IRQs do not work well with Pipewire's timer based approach. So this is the expected behaviour, unfortunately.

[RyanHarvieStark]

I think I had seen your actual comment about this elsewhere. If you do:

journalctl -f | grep pipewire

You can see all the missed syncs.

This is very unfortunate because the RME works really great on my Mac. Most solid interface I ever used.

My problem is that I use a lot of MIDI devices and Jack is not nice for that.

[rubin55]

@RyanHarvieStark @Schroedingers-Cat Are there any links/sources mentioning the pipewire latency issues with RME cards and that specifically that the pipewire dev will probably not fix that? That sounds insane to me!

[Schroedingers-Cat]

My discussion with the pipewire devs about the RME driver not performing well with pipewire happened on their IRC.

With the release of pipewire v1.0 there were some improvements for IRQ based drivers. I made a quick test at the beginning of this year on Manjaro and found it to be much more stable than before but didn't had the time yet to test it more thouroghly.