This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 217259 - Review Request: alsa-firmware - Firmware for several ALSA-supported sound card
Review Request: alsa-firmware - Firmware for several ALSA-supported sound card
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
:
: 186858 (view as bug list)
Depends On:
Blocks: 186858
  Show dependency treegraph
 
Reported: 2006-11-25 20:45 EST by Tim Jackson
Modified: 2008-08-20 08:23 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-20 08:23:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
tibbs: fedora‑review+


Attachments (Terms of Use)
Another spec variant (1.65 KB, application/octet-stream)
2006-11-27 17:41 EST, Nicolas Mailhot
no flags Details

  None (edit)
Description Tim Jackson 2006-11-25 20:45:54 EST
Spec URL: http://www.timj.co.uk/linux/specs/alsa-firmware.spec
SRPM URL: http://www.timj.co.uk/linux/srpms/alsa-firmware-1.0.12-1.src.rpm
Description:
This package contains the firmware binaries for a number of sound cards.
Some (but not all of these) require firmware loaders which are included in
the alsa-tools-firmware package

alsa-firmware has not been in Fedora since Fedora.us days, even though it is absolutely vital to make some soundcards usable.  There are several possible issues:

1. licensing/distribution
2. compliance with Guidelines

Let's take (1) first. Thorsten did a bit of background research on this and summarised in a private mail on 2 June 2006:

======================================================================
I took a closer look at the latest upstream package at
ftp://ftp.alsa-project.org/pub/firmware/alsa-firmware-1.0.11.tar.bz2


It contains a file COPYING in the root with the GPL. And a README with
---
LICENSE AND COPYRIGHT
=====================

The files contained in this package is regarded as the example data
for each alsa-tools program.  Hence, their copyright and license
follow basically to the definition of alsa-tools programs.  The
detailed license and copyright is found in README of each
subdirectory.
---

alsa-tools contains a lot of license files with the GPL (and once LGPL).

Most subdirs contains README files with terms like
---
COPYRIGHT
=========

Copyright (c) 2003 Digigram SA <alsa@digigram.com>
Distributable under GPL.
---
or 
---
COPYRIGHT
=========

Copyright (c) RME
Distributable under GPL.
---
or
---
COPYRIGHT
=========

tascam_loader.ihx, tascam_loader.asm and an2131.asm:
Available under GPL without restrictions.

other firmware files:
Copyright (c) 2003 Tascam / TEAC Corporation.
Distributable under GPL.

======================================================================

This still stands with 1.0.12. So it appears to meet the requirements for Binary Firmware in the Guidelines. (It is also distributed with a number of other distros including Mandriva and OpenSUSE)


2. spot and Thorsten did some work with "file" to see if it met the requirement for "no executables". The most interesting one was:

./lib/firmware/mixart/miXart8.elf: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped

Now this does appear to really be an ELF binary, but it is not +x and it doesn't appear to run on Linux:

$ chmod +x miXart8.elf 
$ ./miXart8.elf 
bash: ./miXart8.elf: cannot execute binary file

so I think we can say that is truly is firmware, and it just happens that this device uses a piece of firmware in ELF format.

a "file $(find . -type f) | grep -v -e ASCII -e Bourne -e shell" also throws up some other bits that aren't "data" like:

./lib/firmware/digiface_firmware.bin: DOS executable (device driver)
./lib/firmware/digiface_firmware_rev11.bin: DOS executable (device driver)
./lib/firmware/ea/3g_asic.fw: PGP encrypted data

but these appear to just be "file" noise. They appear to be genuine firmware, that's not executed on the host, so they should be fine. (and 3g_asic is not PGP data; that's just what happens when you chuck lots of random stuff at "file").

Last CVS from fedora.us days, which is largely unchanged here:

http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/alsa-firmware/FC-5/alsa-firmware.spec?root=extras&rev=1.5

Package is listed on:
http://www.fedoraproject.org/wiki/Extras/PackagesNoLongerInDevel?highlight=%28alsa-firmware%28

as "pending legal review" but there appears to be nothing happening and nobody tasked to do anything AFAICT. Given the above details, in the absence of a compelling reason, I don't see why this shouldn't be included in Fedora. I'm looking to spot here to make a call or, if some kind of legal review really is needed, make this block FE-LEGAL and get someone's attention about it.

Note that I only have one piece of hardware that this firmware supports (Echo Audio Indigo DJ) so any feedback from anyone else welcome.

I have marked the package as "noarch"; since it's containing firmware it should be. However, given that the firmware is "compiled" from big strings and there's some fiddly stuff going on, I would appreciate some md5sums of the generated firmware from someone with ppc/x86_64 architectures just to make sure that the end result is the same.
Comment 1 Tim Jackson 2006-11-25 20:47:56 EST
adding cc's from bug #186858 which this bug obsoletes
Comment 2 Tim Jackson 2006-11-25 20:49:57 EST
NB that alsa-tools-firmware (needed to push the firmware for some of the things
in this package) is a subpackage of alsa-tools; see bug #217256
Comment 3 Tim Jackson 2006-11-27 17:29:47 EST
Incidentally, given that few people will need more than one set of firmware
installed, there is a valid argument for splitting the firmware into subpackages
(e.g. alsa-firmware-echoaudio). Any arguments pro- or con- are welcome.
Comment 4 Nicolas Mailhot 2006-11-27 17:41:17 EST
Created attachment 142239 [details]
Another spec variant

The spec variant I use on my box, in case it helps
Comment 5 Tim Jackson 2006-12-09 05:33:49 EST
Thanks Nicolas. Your spec seems substantially the same at a glance; are there
any specific bits you think need importing into mine?

Also would you consider reviewing this package so we can have it in FE?
Comment 6 Nicolas Mailhot 2006-12-09 05:53:33 EST
I fear I won't have this kind of free time before next year at least, that's why
I dumped my spec on you
Comment 7 Tim Mayberry 2007-01-02 22:02:13 EST
I built the alsa-tools package so it would generate the alsa-tools-firmware
subpackage aswell as this package on an x86_64 FC6 system. I have a RME
hammerfall DSP and with both packages installed the firmware is now loaded
successfully when the udev magic happens early in the boot process.

It is a little bit of a pity that at least for the RME cards that require
firmware 3 separate packages are required to use the card rather than just one
alsa-rme-tools package(or whatever) but I'm happy with a working solution, thank
you :)
Comment 8 Jason Tibbitts 2007-06-29 11:14:49 EDT
Hmm, what's the status of this review?  It's been sitting for ages without any
progress.

If all of the legal issues are clear now, it should be easy to review because
there's not much to it.
Comment 9 Tim Jackson 2007-07-06 17:55:47 EDT
From my POV it's just waiting for a review.
Comment 10 Jason Tibbitts 2007-07-06 22:05:58 EDT
OK, I know I'm really not the best person to review this because I haven't a
single piece of hardware that needs this, but nobody more qualified has stepped
up in over eight months and it's pointless to let this sit aroud when it would
be useful to people.

Perhaps you could answer one question which comes immediately to mind:

Why are some of the firmware files under /lib/firmware and some under
/usr/share/alsa/firmware?
Comment 11 Jason Tibbitts 2007-07-12 10:58:20 EDT
Ping?
Comment 12 Tim Jackson 2007-07-12 15:13:59 EDT
It's a good question and I was looking into it. I'm pretty sure I tried moving
them all to /lib/firmware and it didn't work, so it seemed to be something
that's compiled in to ALSA.
Comment 13 Jason Tibbitts 2007-07-26 23:13:40 EDT
I finally have some free time now, so....

This builds fine; rpmlint says:

W: alsa-firmware strange-permission alsa-firmware.spec 0660
  Kind of weird and quite insecure on many systems.  Should be 644.  I don't 
  know if this matters at all once things are in CVS.

W: alsa-firmware mixed-use-of-spaces-and-tabs (spaces: line 10, tab: line 1)
  I don't see this as a problem; fix it if you like.

W: alsa-firmware incoherent-version-in-changelog 0:1.0.12-1 1.0.12-1.fc8
  rpmlint doesn't like seeing the epoch there, but I think this is an rpmlint 
  issue.

E: alsa-firmware arch-independent-package-contains-binary-or-object 
   /usr/share/alsa/firmware/mixartloader/miXart8.elf
E: alsa-firmware arch-independent-package-contains-binary-or-object 
   /lib/firmware/mixart/miXart8.elf
  You explained these initially.

So no big rpmlint problems.

This does not install, due to an unsatisfied dependency on alsa-tools-firmware
>= 1.0.12.  I guess this is a subpackage of alsa-tools which is currently
disabled.  You own alsa-tools so it should be pretty easy to get it turned on. 
I have no hope of testing this anyway so not being able to install it isn't much
of an impediment to a review.

The license does concern me (GPL but there's no real source, just C files
containing data) but if spot has already acked it then I suppose it's OK.  I'll
ping him on it before I approve anything.

The specfile does not consistently use macros.  If you want to use %{__make} and
%{__rm}, you need to use them everywhere and also use %{__mv} and %{__cp}.

The current version seems to be 1.0.14, which came out in June.  Any reason not
to package it?

Because of the missing dependency, I can't determine whether /usr/share/alsa is
properly owned.  It's provided by alsa-utils, but I can't tell if it's in the
dependency chain since alsa-tools-firmware doesn't exist.

* source files match upstream:
   6e7d3104c4de7d031790c1e750067b13e9481bf2855b0806a300d1e697549fbd  
   alsa-firmware-1.0.12.tar.bz2
* package meets naming and versioning guidelines.
* specfile is properly named
X specfile does not use macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
X latest version is not being packaged.
* BuildRequires are proper.
* compiler flags are appropriate (not that it matters for a noarch package).
* %clean is present.
* package builds in mock (development, x86_64).
X package fails to install properly due to a missing dependency.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
   alsa-firmware = 1.0.12-1.fc8
  =
   alsa-tools-firmware >= 1.0.12
   udev
* %check is not present; no test suite upstream.  I have no hope of testing this 
  pacakge.
* no shared libraries are added to the regular linker search paths.
? owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* This is acceptable content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
Comment 14 Jason Tibbitts 2007-07-27 01:56:24 EDT
I'd pay good money if someone would figure out why on earth the component keeps
changing....
Comment 15 Tim Jackson 2007-08-14 17:07:39 EDT
(In reply to comment #13)

Thanks for the review, Jason.
> W: alsa-firmware strange-permission alsa-firmware.spec 0660
>   Kind of weird and quite insecure on many systems.  Should be 644.  I don't 
>   know if this matters at all once things are in CVS.

I'm sure it doesn't.
 
> W: alsa-firmware mixed-use-of-spaces-and-tabs (spaces: line 10, tab: line 1)
>   I don't see this as a problem; fix it if you like.

Sorted. (but see below)
 
> W: alsa-firmware incoherent-version-in-changelog 0:1.0.12-1 1.0.12-1.fc8
>   rpmlint doesn't like seeing the epoch there, but I think this is an rpmlint 
>   issue.

Looks like it.

> This does not install, due to an unsatisfied dependency on alsa-tools-firmware
> >= 1.0.12.  I guess this is a subpackage of alsa-tools which is currently
> disabled.  You own alsa-tools so it should be pretty easy to get it turned on. 

Yes. It's disabled as a subpackage of alsa-tools for the exact reason that
having the -firmware package without alsa-firmware makes no sense. As soon as
we're reasonably happy with this package, I'll enable alsa-tools-firmware.

> The specfile does not consistently use macros.  If you want to use %{__make} and
> %{__rm}, you need to use them everywhere and also use %{__mv} and %{__cp}.

Sorted.

> The current version seems to be 1.0.14, which came out in June.  Any reason 
> not to package it?

Nope, updated.
Will post updated packages when I get a chance to build and test them. It seems
that just dropping in 1.0.14 to the current spec leads to all kinds of craziness.
Comment 16 Tim Jackson 2007-08-14 17:30:35 EDT
Aha. May have solved one of the mysteries raised earlier in comment #10.  From
README:

"The recent ALSA driver supports the hotplug firmware loader.
As default, the package will install firmware data to the places for
both the old ALSA fw loader and the hotplug fw loader.  To disable
the installation of old ALSA fw loader data (if both ALSA and hotplug
fw loaders are available), pass --disable-loader to configure."

This disables the generation of the /usr/share/alsa/firmware/* files. Will test
without these in place; I imagine it's going to work just fine.
Comment 17 Tim Jackson 2007-08-18 18:37:11 EDT
Well, the firmware for the Echo Indigo DJ card (the only hardware I have that
needs firmware) works fine with the firmware just in /lib/firmware, so great.

Updated package here:

Spec URL: http://www.timj.co.uk/linux/specs/alsa-firmware.spec
SRPM URL: http://www.timj.co.uk/linux/srpms/alsa-firmware-1.0.14-1.src.rpm

rpmlint is clean on all packages, and it builds in mock. Additionally, the
alsa-tools-firmware dependency has been built in FC-6. (In the needsign queue as
I write)
Comment 18 Jason Tibbitts 2007-08-25 14:35:53 EDT
Actually rpmlint isn't quite completely clean:

W: alsa-firmware invalid-license GPL
E: alsa-firmware arch-independent-package-contains-binary-or-object
/lib/firmware/mixart/miXart8.elf

The latter is OK, but the former is not.  I see a GPL copying file and some LGPL
headers in some of the code (echoaudio/DSP/Echo3gDSP.c, for example), plus weird
things like "aica/license.txt".

Honestly I don't think it's the package reviewer's job to do complete license
review and I'm certainly not a lawyer so I can't really do so in any case.  The
other issues I had are fixed now, so I'll just leave it to you to make a
determination as to what the new-style License: tag should be (ping spot or
block FE-Legal if you need to) and then go ahead and check in.

APPROVED
Comment 19 Tim Jackson 2007-08-31 08:45:08 EDT
Thanks very much for the review Jason. I will check out the licensing again
before importing and make sure that it all ties up with the new License tag etc.
Comment 20 Tim Jackson 2007-09-18 04:25:25 EDT
Detailed license breakdown and questions submitted to spot, awaiting response.
In any case the package could do with a PACKAGE-LICENSING file adding.
Comment 21 Jason Tibbitts 2007-12-19 13:35:30 EST
Any progress over the past three months?
Comment 22 Tim Jackson 2008-01-05 09:17:49 EST
Unfortunately no. For the record, summarising some offline discussions with spot:

a) some parts of the the package which are GPL'd (hdsploader,
mixartloader, pcxhrloader, us2xyloader,vxloader) don't specify a license
version for the GPL, containing only "Distributable under GPL".

-> see https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3411 (no response
from upstream)

b) the "aica" firmware (aica/license.txt) is under a "KOS" license which spot
says is the same as BSD, so that's OK.

c) One of the firmwares (emi_26_62/license.txt) is clearly not OK for Fedora:

"This firmware is for the Emagic EMI 2|6 Audio Interface
 
The firmware contained herein is Copyright (c) 1999-2002 Emagic
as an unpublished work. This notice does not imply unrestricted
or public access to this firmware which is a trade secret of Emagic,
and which may not be reproduced, used, sold or transferred to
any third party without Emagic's written consent. All Rights Reserved.

This firmware may not be modified and may only be used with the
Emagic EMI 2|6 Audio Interface. Distribution and/or Modification of
any driver which includes this firmware, in whole or in part,
requires the inclusion of this statement."

-> see http://mailman.alsa-project.org/pipermail/alsa-devel/2008-January/005020.html
Comment 23 Tim Jackson 2008-04-17 19:03:40 EDT
With some clarifications made in recent releases, I think if we exclude the
emi_26_62 firmware we will probably be OK. See also
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-January/005702.html

As soon as I get a mo I will do a fresh package which should be OK.
Comment 24 Tim Jackson 2008-05-06 14:52:32 EDT
*** Bug 186858 has been marked as a duplicate of this bug. ***
Comment 25 Tom "spot" Callaway 2008-05-12 15:23:24 EDT
(In reply to comment #23)
> With some clarifications made in recent releases, I think if we exclude the
> emi_26_62 firmware we will probably be OK. See also
> http://mailman.alsa-project.org/pipermail/alsa-devel/2008-January/005702.html

I think so too, but I'm waiting to see a new package to do the final sign-off.
Comment 26 Tim Jackson 2008-05-12 18:01:35 EDT
OK, in what must rate as one of the most unrewarding bits of work on packaging
ever, I have been through the package licensing in exhaustive detail at a source
level (the licenses even vary between firmware from the same manufacturer for
minor hardware revisions!) and offer the following rather clumsy but unambiguous
revision:

Spec URL: http://timj.fedorapeople.org/SPECS/alsa-firmware.spec
SRPM URL: http://timj.fedorapeople.org/SRPMS/alsa-firmware-1.0.16-1.src.rpm
Comment 27 Tom "spot" Callaway 2008-05-14 12:56:09 EDT
Well, I'm less than thrilled about the korg, asihpi, and yamaha firmwares not
having explicit licensing, but I won't hold this package on them. Please file
upstream bugs to get this corrected.

Lifting FE-Legal. Tim, thank you for your hard work and due diligence.
Comment 28 Jason Tibbitts 2008-05-14 13:03:50 EDT
I'm not sure why this ticket isn't assigned to me since I did the review.  There
shouldn't be any need to reassign a review ticket unless the reviewer changes
for some reason.
Comment 29 Tim Jackson 2008-05-15 15:59:39 EDT
I would like to file upstream bugs, but their bugtracker is currently broken.
Bugs #3410-3413 upstream cover some of the licensing issues. I will import the
package now; thanks to all for the input.
Comment 30 Tim Jackson 2008-05-15 16:34:05 EDT
Package Change Request
======================
Package Name: alsa-firmware
New Branches: F-8
Updated Fedora Owners: timj
This is resurrection of a long-dead package
Comment 31 Kevin Fenzi 2008-05-15 18:53:15 EDT
I see in pkgdb that this package is owned by Andreas Bierfert (awjb)... 
was it ever orphaned? Or did Andreas intend to? 
Comment 32 Jason Tibbitts 2008-05-15 21:12:36 EDT
It was dead.package'd back in the days of FC-5; I think it's pretty safe to
assume  that ownership should have been dropped then, but I guess if Andreas
really wants back on this package then I'm sure he need only make the request.
Comment 33 Tim Jackson 2008-05-16 08:17:40 EDT
As per comment #30, this is a resurrection of a long-dead package. As Jason
rightly says, it's been dead.packaged for ages, so my request is to take
ownership. Andreas would be welcome to have ownership although ISTR (perhaps
incorrectly) that I tried to contact him ages ago and got no response or
negative. I will forward this bug to him.
Comment 34 Kevin Fenzi 2008-05-16 11:09:06 EDT
ok, makes sense. I guess if Andreas wants to maintain or co-maintain he will
speak up. ;) 

cvs done. 
Comment 35 Tim Jackson 2008-05-18 08:33:07 EDT
Package Change Request
======================
Package Name: alsa-firmware
Please remove the CVS tag alsa-firmware-1_0_16-1_fc9 which was made without the
Makefile present (due to the package having previously been dead.package'd)
Comment 36 Tim Jackson 2008-05-18 08:33:27 EDT
Built in F-8 and devel; F-9 awaiting tag removal as above
Comment 38 Nicolas Mailhot 2008-05-18 11:47:19 EDT
# yum update alsa-firmware
Loaded plugins: refresh-packagekit
Excluding Packages in global exclude list
Finished
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package alsa-firmware.noarch 0:1.0.16-1.fc10 set to be updated
--> Processing Dependency: alsa-tools-firmware >= 1.0.16 for package: alsa-firmware
--> Finished Dependency Resolution
alsa-firmware-1.0.16-1.fc10.noarch from koji-f10-builds has depsolving problems
  --> Missing Dependency: alsa-tools-firmware >= 1.0.16 is needed by package
alsa-firmware-1.0.16-1.fc10.noarch (koji-f10-builds)
Error: Missing Dependency: alsa-tools-firmware >= 1.0.16 is needed by package
alsa-firmware-1.0.16-1.fc10.noarch (koji-f10-builds)
Comment 39 Tim Jackson 2008-05-18 12:31:07 EDT
Argh. I had that problem from the other end a while ago and had to take the
alsa-tools-firmware subpackage out.

I will rebuild alsa-tools with the -firmware subpackage for all branches now.

Thanks Nicolas.
Comment 40 Nicolas Mailhot 2008-05-18 17:10:22 EDT
* Sun May 18 2008 Tim Jackson <rpm@timj.co.uk> - 1.0.16-2
- Enable firmware subpackage - the accompanying alsa-firmware package is
  finally in Fedora

Not really :(
Comment 41 Tim Jackson 2008-05-18 17:32:48 EDT
(In reply to comment #40)
> * Sun May 18 2008 Tim Jackson <rpm@timj.co.uk> - 1.0.16-2
> - Enable firmware subpackage - the accompanying alsa-firmware package is
>   finally in Fedora
> Not really :(

I think you're pointing out the alsa-tools-firmware packages not built, still.
Thank you. I don't know what has screwed up this time, but I am hoping it is the
final obstacle on the road to getting this damn package in the repo. I will fix it.
Comment 42 Tim Jackson 2008-05-18 18:04:03 EDT
Builds of alsa-tools which include the -firmware package for F-8 and F-9 are in
the updates-testing queue, and it is built on devel.
Comment 43 Jim Cochrane 2008-05-18 22:44:42 EDT
Sorry to intrude - it looks like the problem has been resolved and a patch/fix
will be available soon; but I'd like to check whether the problem I'm having is
directly related to this defect - it seems almost certain it is.

Initialization of my Echo mia midi card is failing:

$ dmesg|grep -i echoaudio
ALSA sound/pci/echoaudio/echoaudio.c:2001: Echoaudio driver starting...
ALSA sound/pci/echoaudio/echoaudio.c:1918: chip=f7bce000
ALSA sound/pci/echoaudio/echoaudio.c:1948: pci=f78d2000 irq=17 subdev=0081 Init
hardware...
ALSA sound/pci/echoaudio/mia_dsp.c:44: init_hw() - Mia
ALSA sound/pci/echoaudio/echoaudio.c:44: firmware requested: mia_dsp.fw
ALSA sound/pci/echoaudio/echoaudio.c:47: get_firmware(): Firmware not available (-2)
ALSA sound/pci/echoaudio/echoaudio.c:1964: init_hw err=-2
ALSA sound/pci/echoaudio/echoaudio.c:1854: Stop DSP...
ALSA sound/pci/echoaudio/echoaudio_dsp.c:882: rest_in_peace() open=0
ALSA sound/pci/echoaudio/echoaudio_dsp.c:846: stop_transport 0
ALSA sound/pci/echoaudio/echoaudio_dsp.c:865: stop_transport: No pipes to stop!
ALSA sound/pci/echoaudio/midi.c:39: enable_midi_input(0)
ALSA sound/pci/echoaudio/echoaudio.c:1859: Stopped.
ALSA sound/pci/echoaudio/echoaudio.c:1870: MMIO freed.
ALSA sound/pci/echoaudio/echoaudio.c:1876: Chip freed.
Echoaudio Mia: probe of 0000:00:0c.0 failed with error -2

This is on Fedora 9.  The alsa firmware package(s) are not included in F9 at
this point, right? - Thus the error.

Two questions: Is the fix (such as 'yum'able alsa*firmware packages) likely to
be available soon?

Is there a fairly straightfoward work-around, such as installing the missing
alsa-firmware packages by hand?


Thanks!
Comment 44 Tim Jackson 2008-05-19 17:03:02 EDT
(In reply to comment #43)
Jim: yes, your problem should be solved by installing the firmware which,
conveniently enough, is now packaged as per this bug :-)

The package is built and ready for testing. The best thing for now is to install
the RPM directly from
https://admin.fedoraproject.org/updates/F9/pending/alsa-firmware-1.0.16-1.fc9 .
You can also provide feedback via the above URL. There are a limited number of
people with hardware which requires firmware, so please do - your testing is
very valuable. It will also help to give us the confidence to push it into the
"real" Fedora 9 repository where everyone will then be able to install it via
yum. Thanks!
Comment 45 Nicolas Mailhot 2008-05-19 17:27:29 EDT
(In reply to comment #41)

> I think you're pointing out the alsa-tools-firmware packages not built, still.
> Thank you.

Yes, sorry I was a bit terse, I was working on my own packaging brownpaper bag
mistakes at the time

Everything is ok now
Comment 46 Tim Jackson 2008-05-19 17:55:44 EDT
(In reply to comment #44)

Jim, although it's not actually technically required for your hardware, to avoid
broken dependencies you will also need the alsa-tools and alsa-tools-firmware
packages from:

https://admin.fedoraproject.org/updates/F9/pending/alsa-tools-1.0.16-4.fc9

alsa-tools also has the "echomixer" tool which will be useful for your hardware.
Comment 47 Jim Cochrane 2008-05-21 06:11:55 EDT
Tim -  Thanks for the fast response.

I installed the alsa* rpms and rebooted and the card was recognized!
The only problem I had was that alsa-firmware and alsa-tools-firmware
depended on each other:

	alsa-firmware is needed by alsa-tools-firmware-1.0.16-4.fc9.i386
	alsa-tools-firmware >= 1.0.16 is needed by alsa-firmware-1.0.16-1.fc9.noarch

This was easily solved by picking one and installing with --nodeps options.

Below is the relevant output of aplay and aplaymidi showing that the device
is recognized.

As a further test, I hooked a MIDI keyboard up to the sound card, started
up jackd and rosegarden and succeeded in recording the MIDI keyboard output
in rosegarden; and I was also able to play compositions (including what was
recorded) in rosegarden with the MIDI keyboard as the output device.

I've not tested the audio ports yet because I don't yet have the right
connectors - for the Mia's audio ports - to hook up my speakers.

$ aplaymidi -l
 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0
 16:0    Mia                              Mia

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Mia [Mia], device 0: PCM [Mia]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: V8237 [VIA 8237], device 0: VIA 8237 [VIA 8237]
<snip>

Here's some info about my system.  Let me know if you need to know anything
else.

$ uname -a
Linux titan.milkyway.org 2.6.25.3-18.fc9.i686 #1 SMP Tue May 13 05:38:53 EDT
2008 i686 athlon i386 GNU/Linux

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 7
model name      : AMD Athlon(tm) 64 Processor 3500+
stepping        : 10
cpu MHz         : 1000.000
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up ts fid
vid ttp
bogomips        : 2001.67
clflush size    : 64


Thanks to you and your team for all the work you've put into this.

Comment 48 Jim Cochrane 2008-05-27 05:01:15 EDT
Addendum: I've hooked up speakers to the sound card and have verified that the
audio, as well as MIDI, is working on my Echo Mia MIDI card with alsa-firmware
installed.


Thanks!
Comment 49 Jason Tibbitts 2008-08-08 12:31:13 EDT
Is there any reason this ticket is still open?  I don't see that CVS was ever done, but the package seems to be in the distro.
Comment 50 Tim Jackson 2008-08-20 08:23:06 EDT
(In reply to comment #49)
> Is there any reason this ticket is still open?  I don't see that CVS was ever
> done, but the package seems to be in the distro.

No, closed. CVS didn't need to be done because there was already a module in CVS from legacy Fedora Extras.

Note You need to log in before you can comment on or make changes to this bug.