Linux is not ready for Steam

[darkphoenix22]

It just happens that the one that comes with Gnome sucks...

[deanjo]

Great then hop onto the ALSA Project and tell them to take down the page that reads....
I guess they provided this information for entertainment for those people who have it working perfectly. Give me a break.

If there are issues like that the it is a bug in the driver and a bug report should be done up. I've ran across issues like that with HDA systems and once the alsa info script was ran and submitted it was fixed in a future release. Fixed the proper way, not bandaided up.

Uh no. You actually haven't described the nature of a bad driver and what it's effect will be. You're assuming that every anomaly in ALSA gets directly passed through to PA and is heard or noticed by the end user, and it's effect is the same no matter what. Considering we are talking about two different API's hear the likelihood of that being the case in all situations is virtually nill.

See this where you are backwards. ALSA doesn't pass to pulse, pulse passes to alsa. If there is an issue in app that you are running that outputs alsa through pulse and then back to alsa then the bug is in the application. A middle layer maybe able to allow you to flip the channel assignments but that would be on a per app process that would still require you to flip it when ever an app that is bug free is used to get the expected results. The only real way to fix it is in the app again negating the need for that middle layer.

[kaczu]

[QUOTE=darkphoenix22;133054]Again, this is all fixed by using a proper and decent mixer:



OMG. That was just a snippet of the page.

[darkphoenix22]

Seriously "alsamixer" and "alsamixer-gui" are giant messes. But there are MUCH better mixer GUIs out there. Like the Xfce Mixer.

[deanjo]

Hint: Alsa handles different versions of the Intel HDA differntly. Or do you think they all get interpreted the same?

Of course alsa handles different versions. Device combinations though are many. The difference is when you install a driver in windows that driver is for that PCI-ID and knows the combination. With alsa that information has to be added into the driver and then it should function as expected.

Good now how about you go out and purchase the other 10 versions of the codec?

I've got various HDA solutions cmedia's, adi's, via's, nvidia's possibly others. I know I can do the same on all now. Why? Because the issues I have found were reported to ALSA and fixed at the driver level. A couple of the systems even have more then one sound hardware in them and they function as expected again without pulse.

[kaczu]

If there are issues like that the it is a bug in the driver and a bug report should be done up. I've ran across issues like that with HDA systems and once the alsa info script was ran and submitted it was fixed in a future release. Fixed the proper way, not bandaided up.

Really now. It's not "if there are issues" there are issues like that, which is why the page exists. Instead of being dismissive, disrepectful, and borderline an $&@ you could have admitted it from the very beginning and we could have discussed it like adults.

I personally have two different Intel HDA's. One works just fine. The other..... not so much. I ended up downloading the latest version of ALSA in order to resolve most of the problems I was having with it.

See this where you are backwards. ALSA doesn't pass to pulse, pulse passes to alsa. If there is an issue in app that you are running that outputs alsa through pulse and then back to alsa then the bug is in the application. A middle layer maybe able to allow you to flip the channel assignments but that would be on a per app process that would still require you to flip it when ever an app that is bug free is used to get the expected results. The only real way to fix it is in the app again negating the need for that middle layer.

In my explanation I wasn't describing it accurately and I am welcome for your correction, but that does not negate the premise. If you look in my previous posts your example is exactly what I said was possible through PA. Your sound card may not support hardware mixing which would be conveyed by the driver. However, PA can do this before the sound sample is sent to ALSA which is one example of the driver not being able to offer functionality but PA making it possible. This is why "buggy driver" is a generality. It does not describe what is broken in the driver and you need to know that before saying broken in one API is an automatic broken in another. That might not be the case depending on the issue.

[mugginz]

I've got various HDA solutions cmedia's, adi's, via's, nvidia's possibly others. I know I can do the same on all now. Why? Because the issues I have found were reported to ALSA and fixed at the driver level. A couple of the systems even have more then one sound hardware in them and they function as expected again without pulse.

Well both ALSA (obviously) and Pulse are depending on this part being functional, but how are the distros packing dynamic routing of sound in an ALSA only environment.

There's no reason that can't be integrated into ALSA and perhaps they have recently. It is something that's important to some people. If they implement Pulses higher level functionality then an ALSA only system becomes an option for me.

[kaczu]

I've got various HDA solutions cmedia's, adi's, via's, nvidia's possibly others. I know I can do the same on all now. Why? Because the issues I have found were reported to ALSA and fixed at the driver level. A couple of the systems even have more then one sound hardware in them and they function as expected again without pulse.

Dude we KNOW they don't all perform the same. There's still bugs open on their differences.

[darkphoenix22]

Dude we KNOW they don't all perform the same. There's still bugs open on their differences.

Evidence? Links?

[pingufunkybeat]

I don't get something. If your using Gentoo which offers the ability to easily fine tune packages via source what's your beef? Many software packages can be compiled without PA entirely (mplayer, xine, etc) so if you can go your own road why disable PA for everyone else when you don't plan on using it? Of course I'm aware that the option might not exist for everything but it does exist for most things.

It exists as long as upstream offers a compile-time choice. Gentoo can't fork all Linux software and maintain it in parallel.

But as you said it's not just that feature alone but all of them combined. What you're suggesting is that we throw out all of the other features then spend months to year adding in the new feature while keeping Steam on the backburner during this process. Then at some point spend even more developer time to add in all the features PA and the all other OS's have while hoping we don't have a regression which could break Steam for everyone. Does that really make sense to you?

This has to be a joke.

Steam is not coming to Linux, and if it is, it won't care about the sound system. You really think that this is some sort of battle where PA has to "win", and we will get Steam as a reward?