Linux is not ready for Steam

[darkphoenix22]

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.

Modernized? Unclean? Unsafe? Jesus, I'm leaving this discussion because clearly PulseAudio is becoming a religion.

In a perfect world, PulseAudio would be the perfect audio framework. But sadly, we don't live in that perfect worls.

And sadly, removing hardware interupts only increases latency, as the software can't sync with the rest of the hardware.

[darkphoenix22]

You're asking all programmers to adhere to your perfect world and recode their applications to work with it.

Sadly, that just isn't going to happen in reality.

[IsawSparks]

Modernized? Unclean? Unsafe? Jesus, I'm leaving this discussion because clearly PulseAudio is becoming a religion.

In a perfect world, PulseAudio would be the perfect audio framework. But sadly, we don't live in that perfect worls.

And sadly, removing hardware interupts only increases latency, as the software can't sync with the rest of the hardware.

It seems to have worked fine for Windows with DirectSound/Foundation and OSX with AudioUnits. Both of those platforms have benefited immensely from virtualised IRQs and hardware conflicts, let alone those of software are all but gone these days.

Stop living in the past. Hardware interrupts have their function, but they should be low level and managed by the kernel via some form of abstraction. Software, especially multimedia apps and games, should not be using hardware interrupts. That's modern design principles.

Also, don't try and detract the conversation into some pseudo-religious BS by making silly comments just because of your irrational obsession with one mixer which was borne out of a need to make ALSA work properly in routing audio.

[pingufunkybeat]

Everybody who disagrees with IsawSparks has an "irrational obsession" with something

In one thread, he's arguing that you should use the hardware capabilities to the fullest (HD decoding), and in another that you should NOT use the hardware capabilities to the fullest (HW sound mixing).

[IsawSparks]

Everybody who disagrees with IsawSparks has an "irrational obsession" with something

In one thread, he's arguing that you should use the hardware capabilities to the fullest (HD decoding), and in another that you should NOT use the hardware capabilities to the fullest (HW sound mixing).

Keep trolling. The post wasn't even directed at you.

He's mentioned XFCe Mixer multiple times as if it somehow makes ALSA automagically equivalent to or better than Pulse. A third party solution to a bunch of driver issues really shows how well ALSA has been maintained and how forward looking it is as an audio solution.

Get out of here Stalker.

[mugginz]

Everybody who disagrees with IsawSparks has an "irrational obsession" with something

In one thread, he's arguing that you should use the hardware capabilities to the fullest (HD decoding), and in another that you should NOT use the hardware capabilities to the fullest (HW sound mixing).

Full utilisation of hardware isn't dependant on the use of hardware interrupts by userland software.

Especially video decode.

[pingufunkybeat]

I'm not personally attached to hardware interrupts, although compatibility with older applications is important.

I can understand that a higher-level API is desired in order to provide support for more advanced things such as redirecting existing audio streams in order to ease bluetooth and PnP device support, and that doing this in the kernel might not be the best approach. So I don't oppose standardisation and development in this direction.

It's just that

1) I'm not sure if yet another software daemon is the best way to approach this. The experience with software mixing daemons on Unix has been one huge disaster, without exception.

2) It won't fix buggy drivers and you'll run into similar problems until you take care of that

3) It is still not working correctly for many people, and deprecating and breaking the existing solutions (which DO work correctly for many people) is not the answer.

I don't have the solution either, but the approach of saying "If you don't use GNOME/Ubuntu/PulseAudio, you do not matter" has never worked in the past. To me, it looks like yet another sound daemon with yet another set of problems. Probably better engineered than aRts or ESD, maybe more suitable than JACK, but still a similar solution with the same sorts of problems.

[chaperon]

Everybody who disagrees with IsawSparks has an "irrational obsession" with something

In one thread, he's arguing that you should use the hardware capabilities to the fullest (HD decoding), and in another that you should NOT use the hardware capabilities to the fullest (HW sound mixing).

IsawSparks is true : today's games are modeled after XBox360 capabilities : hardware assisted video and software mixed sound, and that perfectly makes sense : mixing audio is essentially free on today's multi-gigahertz, multi-core, multi-thread platforms. If your CPU is impacted by a 64-channel mix with one reverb, which can be done by an old P200 MMX, then it won't cope with physics, advanced AI and other CPU-hungry tasks of modern games.

PA is getting in the way of OpenAL : game developers just want OpenAL, SDL and FMod to work. The last thing they want is another sound API to include in their engine. Linux userland is ready for gaming, the driver side is the problem (PA is considered as a driver in OpenAL's point of view). And Steem does not offer a level of abstraction in that respect : it is merely an app launcher offering a stable binary environment, like PlayOnLinux.

Constant trolling is killing this thread. I do not want to hear again about interrupts, hardware audio processing, per-app volume or realtime audio device switching : these are not needed for games. Microsoft understood that very well in 1995 and created DirectSound (not that shitty DirectSound 3D that appeared later), bypassing their regular MMC sound system, reducing features for latency and CPU efficiency. The design was flawed (required specific drivers) but the idea was there.

In my opinion, high level sound libraries should have access to raw ALSA/OSS and the ability to disable PulseAudio (to save CPU time, interrupt latencies and timers). And they should use software mixing by default to ensure proper compatibility.

Remember : the thread is about gaming (and sound in games, since it is the last problem).

[Remco]

In my opinion, high level sound libraries should have access to raw ALSA/OSS and the ability to disable PulseAudio (to save CPU time, interrupt latencies and timers). And they should use software mixing by default to ensure proper compatibility.

This is already possible. Just launch the app with pasuspender <app>. Then you lose all PA sounds during the game. I'd be fine with that as the solution for games that use legacy audio libraries. Note that the new versions of these libraries do work with PA. So this whole thread is pretty much a non-issue.

[darkphoenix22]

In my opinion, high level sound libraries should have access to raw ALSA/OSS and the ability to disable PulseAudio (to save CPU time, interrupt latencies and timers). And they should use software mixing by default to ensure proper compatibility.

This I agree with. Perhaps it's time to lock the thread...