Linux is not ready for Steam

[mugginz]

Oh, I can manage that... It's not so much MY abilities that are the problem as it's what other people do.

Firstly, a look at why you've been brought up between me and darkphoenix22.

When he used you as justification as to why Pulse needs to go away and we be left with just ALSA here:

Do I really need to quote Svartalf again?

http://www.phoronix.com/forums/showt...695#post132695

I asked:

So he's unable to implement playback as well as the Doom3 demo has?

I was asking him if he felt you weren't able to. I wasn't stating that you couldn't because I dont know you and haven't looked at your code. But I suspect he hasn't either.

If he felt you weren't able to deal with any additional details brought about with the introduction of Pulse, I wanted him to say so in a straight out way, not hide behind weasel words and weak statements.

I actually didn't think your post here->
http://www.phoronix.com/forums/showt...695#post132695

was saying Pulse must go. I didn't think it meant Pulse made things impossible by any means. What stood out for me in that post was that you felt PulseAudio has too high CPU utilisation. And for me, that points at least to specific implementation problems and not necessarily architectural flaws that he obviously feels it does.

The specific reference to Doom3 is because it was used as an example of a program that doesn't run with Pulse, but at lease on my system it actually proves that you can code games to the ALSA API and have them run via a Puse enabled system. I donloading it, and it worked.

Unlike with the Doom3 code, I don't always have the luxury of re-working the stuff to suit the framework like iD does- I'm stuck with what I'm handed more often than not. And it's not that the other people are incapable- they may have other needs within their game that doesn't allow for the same solution they did at iD.

Exactly. Having been a programmer in a commercial environment previously I understand that there can be situations in which the source of a problem can be fixed, or coded around or dealt with in some way but not always be given the time to do so by management, time overruns, etc.

And, more to the point, I think you'll find several other skilled people commenting on the problem (including some pretty skilled people at indie studios...) I've been pointing out earlier in the threads: You can't expect to wrap a broken framework with something to fix it- the best you will do is sweep the problem under the carpet.

Again, exactly. I also don't see how wrapping a broken framework (ALSA) with some random code will be a cure all for everything. But if Pulse (the wrapper) goes away, we're still left with brokeness in ALSA (the wrapee) so one way or the other, if we fix nothing, brokeness is what we will have.

I might add, I don't think Pulse is here to necessarily fix ALSA, it's here to provide more functionality to ALSA in addition to yet another sound API.

Even if you assume PulseAudio IS the answer to things- with OSS and ALSA being effectively broken in varying and different ways, it's not going to be the right answer until you FIX that stuff underneath as there will always be some stupid lingering problem with it.

And yet again, I agree with this, and is what I've been getting at for the last 100 posts or so. Those guys thinking that simply removing Pulse and we being left with audio utopia have got it very wrong in my view.

[darkphoenix22]

I don't consider the removal of Pulse a sound utopia.

I consider it a state that allows programs that I include with my distribution to work. WHich otherwise would not with PulseAudio installed.

[darkphoenix22]

If we sidetrack this flame-infested thread for a bit: have you considered contacting Lennart about PulseAudio's limitations for your use cases? Maybe some tricks can be pulled in PA to make classic Fmod and Allegro work.

Tricks? Hacks? This is a production sound system not a toy.

[darkphoenix22]

The fundamental flaw of PulseAudio that its sound buffering scheme breaks programs. Some applications need hardware interrupts. PulseAudio does not tolerate this.

Lessing the buffer will not work, even if it can mask the problems in some cases. The PulseAudio paradigm is flawed.

[Dragonlord]

Are you suggesting that users should write their own documentation and their own audio library?

No, that game engines evolve out of the stone age. With the proper design game developers would not get in touch with such problems to begin with.

[Dragonlord]

TSome applications need hardware interrupts.

For what "sane" purpose please?

[Remco]

The fundamental flaw of PulseAudio that its sound buffering scheme breaks programs. Some applications need hardware interrupts. PulseAudio does not tolerate this.

Lessing the buffer will not work, even if it can mask the problems in some cases. The PulseAudio paradigm is flawed.

Well, how about propagating those hardware interrupts (not exactly those I guess, you don't want to deal with actual interrupts in a userspace program) through PA to the program? That's the sort of tricks I'm talking about.

[IsawSparks]

For what "sane" purpose please?

Exactly. There are none.

What modern high level implementation in a game engine deals directly with the hardware at all? Even shader code is structured and the actual bulk of the GPU is abstracted away.

We do not need need interrupt control in any decent gaming sound API.

What we need is good driver support, well designed and implemented scalability and a well designed infrastructure.

Pulse supplies all of this and what's more it does so without making anyone beholden to any specific Dev Environment or Corporate shenaninigans, a la MS DirectX.

The issue isn't with pulse, but with other APIs and apps which use them not having complied in Pulse Audio support properly or directly. It's nice that Pulse offers emulation/translation layers for ALSA and OSS interoperability but these should be seen as a transitional thing for game developers and not as a destination.

The sooner APIs and apps have direct Pulse Audio support the better.

[IsawSparks]

Well, how about propagating those hardware interrupts (not exactly those I guess, you don't want to deal with actual interrupts in a userspace program) through PA to the program? That's the sort of tricks I'm talking about.

Any application which needs Hardware Interrupt support is either Hardware Specific and so has its own drivers (some very old high level audio apps come to mind which use sample accurate MIDI timing) or is an app or game whose design needs to be modernised.

In the first case, those sorts of apps have been more trouble than they're worth and are usually overcome by many cheaper, better implementations such as Pro Tools vs Reaper or Acid Pro. Pro Tools used to be the pro audio app of choice but that was back when studios solely aimed at one platform (The Macintosh) and when studio budgets were much much higher than they are today. These days you can get all the power and more of Pro Tools in apps like Reaper, Acid Pro and Fruity Loops and the music industry doesn't have the kind of cash it had back then.

These days with faster CPUs and much faster busses latency is really a non issue whereas back in the Pro Tools halcyon days hardware interrupt timing driven apps circumvented slower archs by talking directly to PCI cards which handled sample accurate SMPTE MIDI encoding for film scores and the like. These days in most modern CPUs and motherboards DMA and IRQ management is virtualised in the OS and so any software which makes direct calls to devices via hardware IRQs can actually SLOW DOWN the system as a whole and cause things to go out fo synch as the virtualised IRQs lose clock cycle focus.

That's the whole point of virtualising DMA and IRQ in modern implementations. To prevent such slowdown and to keep everything in synch.

[Tomservo]

To shit on this current ongoing discussion, OpenSolaris implemented interrupt-free audio a few builds ago. And it works just fine.