Re: volunteer to fix ALSA for every PPC subarch found! :-)
- To: Martin-Éric Racine <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: volunteer to fix ALSA for every PPC subarch found! :-)
- From: Benjamin Herrenschmidt <email@example.com>
- Date: Mon, 08 Aug 2005 11:01:36 +0200
- Message-id: <1123491697.30257.140.camel@gaston>
- In-reply-to: <Pine.LNX.firstname.lastname@example.org>
- References: <Pine.LNX.email@example.com>
On Sun, 2005-08-07 at 11:41 +0300, Martin-Éric Racine wrote:
> Basically, if you have been trying to switch to ALSA on your PowerMac but found
> out that support for your computer's chipset was lacking or severely broken, or
> if you have already switched but a few rough edges remain, now is a good time to
> let the ALSA coders know about it. See:
> (use the Guest user to view the current bug report and comments;
> adding comments requires creating a user in their Bugzilla)
> SEE ALSO
> 1) The "list of PowerMac sound hardware TO-DO (help welcome)" thread on this
> debian-powerpc list, starting around 2005-03-22 for background info, and for
> details on what tools you can use to list your hardware's features to help you
> provide evidence for your bug report.
> 2) Info about the 500 USD bounty offered by Ubuntu's Mark Shuttleworth to fix
> this issue: https://wiki.ubuntu.com/MartinEricRacine
I can provide almost all the necessary informations. I have specs for
most chips, and those I don't have spec for have Darwin drivers that
should tell us all we need to know.
There are several issues though, as I wrote earlier. More than just
"fixups", we need some real re-architecture of the driver. We need to
properly separate the transport layer (can be davbus or i2s) from the
codecs, deal with multiple codecs (G5s have that typically) and multiple
transport busses (some machines have codecs on the 2 i2s interfaces), we
need to properly reprogram the i2s clocks, we need to do clock switching
when fed with a digital input signal, etc...
Also, on pretty much all recent machines, the only info that you have
about the sound hardware is an "ID" value in the device-tree. Apple code
matches that value with some XML structure in the driver property list
that indicates what set of codecs etc... to use.
I don't have time to actually do the work, but I'm willing to help.