Created attachment 28868 [details] media-sound/alsa-driver/alsa-driver-0.9.1.ebuild
Created attachment 28869 [details] media-sound/alsa-driver/files/alsa-driver-0.9.1-xbox.patch.bz2
please attatche the patch as text. what is the source of this patch? is there a patch availible for a newer version of alsa?
Created attachment 28939 [details, diff] /media-sound/alsa-driver/files/alsa-driver-0.9.1-xbox.patch This is the unbzipd patch. I made it from the xbox-linux.org sourceforge cvs. There is no newer version :-( I have tried the latest alsa-driver unpatched on the xbox but it doesn't work.
If you could merge this patch into 0.9.8, I'll include it as a USE flag driven option.
Created attachment 29349 [details] media-sound/alsa-driver/alsa-driver-1.0.4-r2.ebuild
Created attachment 29350 [details, diff] alsa-driver/files/alsa-driver-1.0.4-xbox.patch This is a small patch for 1.0.4 from http://op-co.de/xbox. It just patches a couple of lines of the hardware detect but doesn't include the spdif support in the other patch. No newer versions of the older/bigger patch exist.
that patch only changes a little debug output... does 1.0.4 work for you out of the box on xbox? It may be the case that the patch was incorperated into mainline alsa.
No, it needs that patch: //snd_ac97_free(ac97); //return -EACCES; That stops the function freeing memory and returning when it fails to detect the xbox hardware.
oh... I didn't notice the code was commented out... this won't get comitted. The correct way to do this is to modify ac97_is_audio() for your hardware.
No, ac97_is_audio() just returns the value of the AC97_SCAP_AUDIO bit in ac97->scaps. This bit would normally be set in the test above ( /* test for AC'97 */ ) because it tries to write a register of ac79 hardware mixer (recording gain). But the xbox is unique in this case, as it doesn't have a hardware mixer or audio input! So the value of AC97_SCAP_AUDIO is correct, but we still want to continue the initialisation. I guess you could take the view that alsa is at fault here, because the ac97 test assumes that an ac97 card will have a hardware mixer and line in. I've attached a new patch that forces the audio capability on in the driver right after the ac97 test.
Created attachment 29588 [details, diff] alsa-driver-1.0.4-xbox-2.patch
sorry, let me clarify... you will need to find some other way to detect if it the xbox hardware (pci id perhaps). What you are doing here will break other systems.
It seems likely that there will be a global xbox USE flag, so this won't affect anyone else. The problem is that the xbox audio appears identical to nforce audio. The codec ID detected by alsa is just the nforce one... I've reported this as a bug in alsa anyway (https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000221) so we'll see what they say.
i won't fix this unless it is done properly (which I'm assuming upstream devs will do).
lets do it
we're not looking at a USE flag but at a PROFILE_ARCH=xbox setting with ARCH=x86
Reopening discussion on adding the xbox alsa-driver patch. I reported this upstream a long time ago: https://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000221 Unforunately it hasn't been fixed. For various reasons we are using a 2.4 kernel with gentoo xbox project. It is unacceptable not to have sound working. As vapier said, the patch in the ebuild can be surrounded with: if "${PROFILE_ARCH}" == "xbox" ; then this will isolate the patch and apply it *only* on xbox. Please let me know if you can do this, or if you mind if I add the patch to the ebuild myself.
that's fine to do it conditionally... go for broke ;) Please use the 1.0.5a ebuild if you can... I want to try cleaning out most of the ond 1.0.x stuff soon...
its done, 1.0.5a
