On 06/25/2009 08:20 AM, Jon Smirl wrote:
On Thu, Jun 25, 2009 at 1:36 AM, Robert Hancockhancockrwd@gmail.com wrote:
On 06/24/2009 10:26 PM, Jon Smirl wrote:
On Wed, Jun 24, 2009 at 5:11 PM, Takashi Iwaitiwai@suse.de wrote:
The problem is knowing which sample in the background music to start mixing the low latency laser blast into.
That's why querying the accurate hwptr is important in PA.
I'm still not convinced that all of this logic should be exposed to PA. Exposing these details is what makes ALSA hard to use. We should be able to better isolate user space from this. If mixing were moved into the kernel these details could be hidden. The in-kernel code could then be customized for various sound DMA hardware. This would also go a long ways toward getting rid of latency issues by removing the need for real-time response from PA.
Mixing really does not belong in the kernel. Moving it there doesn't remove any complication or problem, it just moves it to a different place where it's more difficult to program and less debuggable. Most OSes (Windows included) are moving in the direction of moving mixing out of the kernel, not into it.
Mixing has a real-time component to it. Currently Desktop Linux doesn't have real-time support. That's why pulse is developing RealTimeKit. Buggy real-time code can easily lock your machine to where you need to hit the reset button.
User space code that is locked down with real-time priority and servicing interrupts is effectively kernel code, it might as well be in the kernel where it can get rid of the process overhead.
Just because it runs with real time priority does not mean it is effectively kernel code, or that it belongs there. Putting the code into the kernel adds a bunch of extra challenges for little reason, and also locks all users into a mixing scheme that may not meet their needs (ahem, Windows kernel mixer..)