I bet that you're wrong man ;-)
It looks like you are right about me being wrong, i based my interpretations on found forum and knowledgebase questions where developers come up with questions about ALSA's exclusive claiming of audio devices and they get simply answered that Alsa doesn't share the sound-device. But i think i misinterpreted the idea where developers wanted to claim the audio device directly rather than use Alsa at all.
Otherwise how can I play youtube with flash + smplayer + clementine + ... at the same time?
Without any userland sound daemon.
I doubt they don't use an audio deamon, http://tuxradar.com/...audio-explained
If you're thinking that things are going to get easier with ALSA safely behind us, you're sadly mistaken. ALSA covers most of the nuts and bolts of getting audio into and out of your machine, but you must navigate another layer of complexity. This is the domain of PulseAudio - an attempt to bridge the gap between hardware and software capabilities, local and remote machines, and the contents of audio streams. It does for networked audio what ALSA does for multiple soundcards, and has become something of a standard across many Linux distros because of its flexibility.
As with ALSA, this flexibility brings complexity, but the problem is compounded by PulseAudio because it's more user-facing. This means normal users are more likely to get tangled in its web. Most distros keep its configuration at arm's length; with the latest release of Ubuntu, for example, you might not even notice that PulseAudio is installed. If you click on the mixer applet to adjust your soundcard's audio level, you get the ALSA panel, but what you're really seeing is ALSA going to PulseAudio, then back to ALSA - a virtual device.
At first glance, PulseAudio doesn't appear to add anything new to Linux audio, which is why it faces so much hostility. It doesn't simplify what we have already or make audio more robust, but it does add several important features. It's also the catch-all layer for Linux audio applications, regardless of their individual capabilities or the specification of your hardware.
This snippet does explain Alsa should be capable to share audio among multiple applications (because OSS was exactly lacking that)
ALSA is responsible for translating your audio hardware's capabilities into a software API that the rest of your system uses to manipulate sound. It was designed to tackle many of the shortcomings of OSS (and most other sound drivers at the time), the most notable of which was that only one application could access the hardware at a time. This is why a software component in ALSA needs to manages audio requests and understand your hardware's capabilities.
It does also explains this about the Alsa driver:
But it's also far more ambitious than a normal kernel driver; it can mix, provide compatibility with other layers, create an API for programmers and work at such a low and stable latency that it can compete with the ASIO and CoreAudio equivalents on the Windows and OS X platforms.
I suspect for the latter, exclusive mode is required as Renoise aims for low latency. I'm not sure if adding an Alsa shared mode is easily done, but performance wise this is really not a good idea at all, it beats the purpose of serious music production.
Besides, once Renoise would run in shared mode, i am not sure either if Alsa can be claimed strictly again if other applications already have access to Alsa.