softvol wasn't meant to be used for per-application volume controls, it was made so you could adjust your master sound volume if your hardware didn't have hardware volume control. Using softvol to provide per-application volume controls is a hack and must be implemented by apps themselves or a wrapper.
OSSv4 has transparent and centrally managed per-application volume controls. Built into the API. No additional wrappers or programming required.
As you seem to know alsa very well maybe you could show me a config for hdmi audio with softvol + dmix. i currently have got dmix running with hdmi (over gt220).
I've never tried using softvol to provide per-app controls. Mostly because such an external solution is much more trouble than it's worth.
Do you have any source for all this stuff you are talking about?
Mixing belongs into the sound system. There is no way that applications should worry about whether something is playing already. That's not a hack, it is exactly where it belongs. The history of Linux sound is a history of weirdo sound daemons which were all hated and ended up abandoned carcasses next to the road. An app should either talk to a well-defined hardware interface (ALSA or OSS, or something else), or using a library which abstracts this away. It should not be talking to a daemon which most people will not install anyway.
PA and JACK are solutions for sound professionals, not for playing music on a regular everyday desktop. You don't need any of their features for anything you do every day, unless you're a sound engineer. Forcing this onto everyone just so 0.01% of people can stream sound over the network as a tech demo is insane.
If there are problems with ALSA, then you fix ALSA. It seems like most "problems" don't even exist. Sure, per-app volume would be nice. should I run a professional sound daemon and run all my software through an emulation layer because of this? Hell no!
Software mixing only exists because some hardware does not do this at the hardware level. If it doesn't exist at the hardware level, then it has to be performed by a driver -- dmix. OSSv4 does exactly the same thing. Why on Earth is on a hack, and the other one not?
What are you smoking?
In fact, I support OSSv4 for the very reason that the ALSA devs aren't implementing features anymore and are instead relying on PulseAudio to provide new features. Mostly because they can't be bothered to extend ALSA anymore it's too damn complicated to be usefully expanded while keeping API stability.
Linux needs a simple, extenisble audio API that doesn't need wrappers to provide functionality that should be in the API itself. ALSA will never be that API. OSSv4 has the potential to become it, if we solve the political issues.
And I'm not sure ALSA can be fixed to become simple and extensible. Which is why I began to look at other options like OSSv4.
- Short-term: Abandon PulseAudio
If a game uses sound for timing, it's toast with PulseAudio due to the higher latency. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.
- Long-term: Look at OSSv4 as a possible replacement for ALSA
PulseAudio's functionality needs to be replaced somehow. This would not be possible with ALSA unless we made another wrapper, which would have many of the same unavoidable problems as PulseAudio.
The problem isn't that ALSA doesn't work. The problem is ALSA is too damn complicated to be usefully expanded while keeping API stability. This is why PulseAudio was created in the first place.