On Thu, Jun 25, 2009 at 1:36 AM, Robert Hancock<hancockrwd@xxxxxxxxx> wrote: > On 06/24/2009 10:26 PM, Jon Smirl wrote: >> >> On Wed, Jun 24, 2009 at 5:11 PM, Takashi Iwai<tiwai@xxxxxxx> 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. http://git.0pointer.de/?p=rtkit.git;a=blob;f=README > > For what PulseAudio is trying to do, it needs this kind of information > because it wants to be able to rewrite the buffer the card is reading out of > at any time, and it needs to be able to know how far along in the buffer the > card has read so it knows where it can start rewriting. It's somewhat > complicated for sure, but most normal applications don't have to deal with > these kinds of details. > >> >> My hardware doesn't have the capability of querying the hwptr and the >> hwptr speed is not linear because of the FIFO and burst transfers. >> Non-linear speed means I can't use a clock to estimate hwptr. I do >> however have the capability of directing the DMA into a new buffer. >> Another thing I could try is setting up DMA descriptor chain blocks >> for every 16 bytes. These descriptors get marked as they are used and >> they don't have to cause an interrupt. >> >> We are evaluating a processor change from PPC to ARM so all of this >> may change for me. >> > > -- Jon Smirl jonsmirl@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
