That link seems to encourage raising the latency, which suggests the needs of people like musicians are not being considered at all. Your use-cases are not the only use cases that exist.
The entire world of music production uses JACK, which got the design right well before PulseAudio even existed. It can provide synchronous operation to prevent drifting between audio tools. I include mplayer2 as one of those tools for s few things. More importantly, JACK guarantees a reliable very, very low latency audio path.
How "low latency" do I mean? Consider that in printed music, while somewhat uncommon, quite a few pieces have been written that use 128th notes. That would be anywhere from ~80ms to ~10ms note lengths, depending on the tempo. Larger latencies mean notes being heard as a different note from what was played, and I keep JACK down to about 5ms latency, and would set it lower if I could afford new hardware. Notes are not the only feature of musinc, and some headroom is needed. Any latencies higher than about 10ms-20ms I would consider broken and unusable.
(Incidentally - I cannot play GuitarHero/RockBand on most TVs either because of horrible latench. A (60Hz) video, a two frame delay is a "miss" on the harder songs. those 16.6ms latencies are nasty regardless which direction the latency is being added)
Beyond that, JACK is a great API. It makes it trivial to do a LOT of the common needs (i.e. "Just give me the audio samples..." or "just let me write new audio data and not have to worry about anything else... such as timing")
Raising the latency is what you want in many cases. For instance, the current discussion is about a video player. There is no need for a video player to submit new data every 10ms, because it knows exactly what it will be playing for the next N seconds (depending on the buffer size it uses). Waking up every 10ms just causes more cpu and power use and risks missing the deadline.
Of course, there are cases where you do need lower latencies, such as games where interactive feedback cause the sound to change, or when you pause a movie. In those cases you adjust the latency (possibly temporarily in the case of the pause).
That said, PulseAudio has a different set of requirements and thus design decisions from Jack. It is not meant to be used in music production, but then again, I doubt the music producers will use some sandboxed app to do music production either. So, I don't see the problem here.
The entire world of music production uses JACK, which got the design right well before PulseAudio even existed. It can provide synchronous operation to prevent drifting between audio tools. I include mplayer2 as one of those tools for s few things. More importantly, JACK guarantees a reliable very, very low latency audio path.
How "low latency" do I mean? Consider that in printed music, while somewhat uncommon, quite a few pieces have been written that use 128th notes. That would be anywhere from ~80ms to ~10ms note lengths, depending on the tempo. Larger latencies mean notes being heard as a different note from what was played, and I keep JACK down to about 5ms latency, and would set it lower if I could afford new hardware. Notes are not the only feature of musinc, and some headroom is needed. Any latencies higher than about 10ms-20ms I would consider broken and unusable.
(Incidentally - I cannot play GuitarHero/RockBand on most TVs either because of horrible latench. A (60Hz) video, a two frame delay is a "miss" on the harder songs. those 16.6ms latencies are nasty regardless which direction the latency is being added)
Beyond that, JACK is a great API. It makes it trivial to do a LOT of the common needs (i.e. "Just give me the audio samples..." or "just let me write new audio data and not have to worry about anything else... such as timing")