rme hdsp firmware is not loaded at system startup

[ttoine]

For RME HDSP cards, the program "hdsploader" must be run to load the cards' firmware. Currently, there is no (complete) udev rule to do this. If you have one of these cards, and your firmware does not load automatically, please attach to this bug the PCI ID of your card, or the output of `lspci -nn`.

[Lionel Le Folgoc (mrpouit)]

I suppose an hal fdi file or and udev rule should do it.
(subscribing Toby)

[Toby Smithe (tsmithe)]

Could you attach the output of `lspci -nn`?

[ttoine (ttoine)]

File attached. The sound card is on the line 21.

The result of lspci -nn is the same weither the firmware is loaded or not.

Toine

[Toby Smithe (tsmithe)]

Thanks. Please install the attached file, 85-hdsploader.rules, to /etc/udev/rules.d and reboot to test.

If you come across any further hdsp cards which do not run hdsploader automatically with that rule installed, please attach the PCI IDs (or `lspci -nn`) to this bug so that the rules can be updated.

[ttoine (ttoine)]

Toby,

Installing this text file does not solve the problem, the firmware is not loaded at startup.

Toine

[Toby Smithe (tsmithe)]

Better as an alsa-firmware-loaders task, really.

[Toby Smithe (tsmithe)]

Please try this updated rule. If it works, I'll prepare a debdiff for Intrepid for alsa-tools.

[ttoine (ttoine)]

Toby,

It doesn't work too. But don't spend too much time on this at the moment, think about your studies first. I am not in a hurry with this bug. Just, some people will not understand what to do because of a lack of documentation about this sound card. Any one can create a menu shortcut of configure the Gnome Session Manager to load it at login.

So, work on that when you have true free time.

Toine

[Raphaël Doursenaud (rdoursenaud)]

On hardy, creating a simple symlink from /lib/firmware/hdsploader/multiface_firmware_rev11.bin to /lib/firmware/multiface_firmware_rev11.bin loads the firmware automagically every time the module is loaded.

I think firmware helper don't seek in subdirectories.

Maybe this bug should be against udev's firmware helper or make the firmwares go to /lib/firmware without subdirectories but this can have a side effect on hdsploader and the such.

[ttoine (ttoine)]

OK,

The place where the firmware helper is looking for the firmware is the old place. It has been corrected by Toby, creating the "hdsploader" folder. So it means that hdsploader is updated, since the command line works well.

So where could be the problem ? Perhaps could Crimsun have any idea about that ?

Toine

[Raphaël Doursenaud (rdoursenaud)]

I think the problem lies between the kernel (module or not) that seeks the firmware in the /lib/firmware directory and hdsploader that is actually patched to seek in /lib/firmware/hdsploader.

We have two ways to fix it. Either patch hdsploader for it to seek in /lib/firmware and install hdsp firmwares without the hdsploader directory in alsa-firmware. That's what is done upstream.

Or patch our kernel with the attached patch.

[ttoine (ttoine)]

So were are we at this time ?

The best way to solve the problem is currently to install the .15 version of alsa-firmware of 64Studio. I do that either on Hardy LTS, Jaunty or Karmic Beta.

Since launching hdsploader in a terminal works, the problem imho is that the kernell module don't look for hdsploader at the good place. Is it hard to patch it ?

[Raphaël Doursenaud (rdoursenaud)]

Actually the best way would be to unpatch our packages and follow the upstream way of installing this particular firmware.

Or

Keep our current patches against ubuntu's alsa-tools (firmware_locations.patch) and medibuntu's alsa-firmware (02_move_hdsploader.patch) in place and use the previously proposed patch against our kernels.

Both ways are pretty trivial but I'd like to know why alsa-tools was patched in the first place?
Maybe should we dig the debian bugtracker for a clue.
It seems it was patched to move the firmwares from an old location (/usr/share/alsa/firmware) to a new one (/lib/firmwares) to follow some kind of new policy but AFAIK upstream vanilla alsa-tools (at least as of 1.0.20) now installs the firmwares in both places!

I'll dig up a bit and propose a patch to unpatch (yes!) our tools if there is no serious drawback.

[Raphaël Doursenaud (rdoursenaud)]

Dug a bit on the debian side and changelog says it was an ubuntu merge at version 1.0.17 so we did it wrong in the first place.
Now that ubuntu synced with debian, the changelog says the same! (Recursive changelog is something I didn't hit before, seems fun ... or not)
Will try to know more and perhaps contact the maintainer.

[Raphaël Doursenaud (rdoursenaud)]

OK so after some research, it seems it was patched as a transition from the firmware storage policy.
I assume we can safely drop the two patches quoted two comments above. Keep debian maintainers tuned and we will be safe using the upstream vanilla way of storing firmwares. Kernel will find the firmware and load it without problems.

Can Toby and the medibuntu guys confirm that they will take action?
These are really trivial fixes!

[ttoine (ttoine)]

Raphaël,

Thanks for your time. I don't know if Toby is still available for
packaging. If you don't have any answer from the Medibuntu guys in a
couple of days, I will try to package it from vanilla sources, add it in
my PPA and report youif it works or not. I may take a bit of time to do
that, it will be my first packaging. But I guess it would not be so
complicated since it is a "all" package, without any patch.

[Lionel Le Folgoc (mrpouit)]

Hi,

You should probably contact the previous uploader (https://launchpad.net/~themuso) for alsa-firmware-loaders. When it's done, I can remove 02_move_hdsploader.patch from alsa-firmwares, and maybe update the package to a newer version (1.0.20). I would be more confident if someone with such hardware could package it though, as I won't be able to test...

[Toby Smithe (tsmithe)]

Hi there,

2009/10/8 ttoine <email address hidden>:
> Thanks for your time. I don't know if Toby is still available for
> packaging.

Sorry ttoine, I'd love to have the time to learn about simple udev
etc, but it would be wrong to say I do. Consequently, I'll have to say
I'm not available to give much help on this, and I'm glad I got it
published and supported by Medibuntu when I did. However, I'll gladly
answer any questions I can on the actions I took.

Best wishes,

--
Toby Smithe :: http://fulltinreality.com

[ttoine (ttoine)]

To everyone,

In Hardy, Jaunty and Karmic, the best way to fix the problem is to install this package:
http://apt.64studio.com/backports/pool/main/a/alsa-firmware/alsa-firmware_1.0.15-2.64studio1~jaunty1_i386.deb

No other package from Ubuntu has to be tweaked.

Can Medibuntu hosts this package, or do the same with a recent version ?

[Raphaël Doursenaud (rdoursenaud)]

ttoine,

This packaging is just what I proposed : drop the 02_move_hdsploader.patch!
The problem here is that hdsploader may now not be able to find the firmware in this location because it's actually patched to seek in the hdsploader subdirectory. Can you test & confirm that?

That's why I think we need to drop both patches :
- 02_move_hdsploader.patch from alsa-firmware in medibuntu
and
- firmware_locations.patch from alsa-tools in ubuntu & debian

Lionel is ready, I just subscribed Luke Yelavich in the hope that he can make the move we need on the MOTU side.

[ttoine (ttoine)]

Raphael,

We don't need to change anything to alsa-tools: I can confirm that the
packaging of alsa-firmware I suggest work, I own and use every day the
RME hdsp Multiface II with this solution... The sound card driver and
firmware are auto loaded.

Toine

[Raphaël Doursenaud (rdoursenaud)]

ttoine,

I understand and know that. I also use a custom alsa-firmware package with my multiface.
What I just say here is that the solution is incomplete and that's why I insist on this change!
There's a few scenarios where people might want to load the firmware manually through hdsploader.
i.e. custom kernel without autoloading, failure to autoload firmware, multiface (re)plugged after boot (this is known to cause problems) etc.
If we don't update the alsa-firmware-loader package which is part of the alsa-tools source package, this tool will be broken because it'll still be searching for the firmware(s) in the wrong place! Just have a look at the code...
Dropping the whole patch might be a bad idea though because it can have an impact on firmware loading for other interfaces but we definitely need to think about that.
... no?

[ttoine (ttoine)]

Raphael,

I don't think so, because hdsploader works if my external box is not
connected at startup. The patch in -loaders is only for hdsploader: it
allow the hdsploader to find where is the firmware to load, for auto or
command line launch.

Let's make a trial: release the version of alsa-firmware I suggest, and
don't change anything to -loaders. I test and give you feedback. If
there is a problem, I'll post a bug against -loaders, so the its
packager will see it the good way. Easy, no ?

Toine

[Lionel Le Folgoc (mrpouit)]

I just uploaded alsa-firmware 1.0.20 without the patch to Medibuntu lucid. Now it's up to Luke. But if I were you, I wouldn't hold my breath for that, as he hasn't even replied...

[David Henningsson (diwic)]

Looking at the code for alsa-tools 1.0.25, it looks like the hdsp firmware is now checked for in /lib/firmware (as per patch in comment #23). I'm marking this as fix released, if it is in fact not working, please reopen this bug. Thanks!