> On Mon, Nov 29, 1999 at 12:39:26PM +0100, Benno Senoner wrote:
> > PS: Alan , I think most mp3 players use a relatively big buffersize
> > (most of time the full 64k of soundcard), and I don't think that VESA
> > disables
> > the IRQs for 370ms ( the time it takes to play the 64k audio buffer)
>
> Yes, but imho redrawing frame buffer console blocks the kernel, scheduling,
> IRQ processing, right ? If so, it's possible to remain only a few kilobytes
> to play for DMA, and it can't play newer buffer block since end of dma
> irq or so is not received since IRQs are locked during frame buffer console
> redrawings. Or I'm wrong and even during this scheduling and IRQ receiving is
> enabled ?
>
> (maybe something kernel thread would be usefull for framebuffer updates
> because scheduler can schedule it as well ...)
sorry I'm not a framebuffer expert, but it remains to be seens if the BIOS really
locks the IRQs that long, or the framebuffer code spends too much time in the
update routines without checking need_resched.
the easiest way is to use my latencytest on a kernel with the low-latency patch
applied.
( http://www.gardena.net/benno/linux/audio )
( test with an UP kernel, because SMP is not handled well on this kernel).
then run a test session while your box is in idle mode,
and later during heavy framebuffer updates.
If the latencies are high in the 2nd case, there is a problem in the frame buffer
code,
and/or BIOS routines.
Benno.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/