On Fri, 2006-08-18 at 12:38 -0400, Paul Davis wrote: High HZ will improve MIDI timing though. MIDI is more likely to be polled than interrupt driven. Lee

--- Mulyadi Santosa <a_mulyadi(a)telkom.net> wrote: I know at least some MIDI sequencers (eg. the one I have written) rely on simple gettimeofday() and sleep() and usleep() to wake up when it's time (or nearly time) to send MIDI events out to MIDI devices. Mine uses gettimeofday to know what time it is, consults a schedule of events it is supposed to send out, sleeps until just before it needs to do the next item on the schedule, wakes up, then starts polling gettimeofday() for the imminent "go time" to arrive, and repeats for the next item on the schedule, etc. sleep() relies on the internal timer. With whatever the default Hz setting is for 2.6.16 kernels or thereabouts, I seem to remember getting notes out within 200 microseconds of the scheduled time as long as there wasn't lots of contention. I instrumented the code to check (via gettimeofday) if the deadline was missed by some adjustable interval and if it was missed by more than that, print a message. I then adjusted the interval until only a few messages came out during times when lots of notes were coming out at the same time. That turned out to be around 200 microseconds. (Actually the code to print a message is currently turned off, since if it executes, it only makes a bad situation worse.) Actually now that I think about it again, my algorithm, since it wakes up slightly before the "go time" then polls gettimeofday may be mostly immune to HZ changes (kind of why I wrote it that way, because I knew sleep() didn't make guarantees). xruns are, I think, JACK's equivalent of my deadline-missed message. It calls such tardiness an "xrun". JACK is the Jack Audio Connection Kit, an app that is useful for sync'ing and communicating audio data between various audio apps that know how to talk to JACK. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

I've certainly seen setitimer()-driven sleeping get much better response time on a kernel compiled to 1000 Hz (with preemption) over one compiled to 100 Hz (without preemption). the audio card with smaller buffers more quickly, reducing latency. But I haven't made tests using audio, specifically, so I won't say more. I suspect the kernel driver and userspace API (ALSA or whatever) might need to be made to take advantage of it, but I know little about ALSA internals. Steve On 8/18/06, Paul Davis <paul(a)linuxaudiosystems.com> wrote:

Yes, the driver is interrupt driven, but the driver interrupt handler is only responsible for getting the data off the card's FIFO and storing it in memory. (i.e., initialing a DMA transfer.) It doesn't do anything with the audio data itself, except pass it on to user space. Won't HZ make a difference to the user application code which must wake up to do something with this audio data? Hence the need for SCHED_FIFO and the like.. Steve

Ah, interesting. Thanks. I feel like I should have known that. I'm going to go read up on audio drivers now.. Steve

On Fri, 2006-08-18 at 20:39 -0400, Stephen Sinclair wrote: I'm not familiar with audio drivers, but is that strictly correct? I am familiar with storage drivers (e.g. cciss) and there, interrupts happen when DMA transfers complete. At that time, the driver _may_ say, "as long as I'm down here in the driver, let me check if there's more work to do and set up some additional dma transfer(s) before the interrupt handler returns," but it doesn't _have_ to do that, excepting unplugging the stream of requests from the OS in case the board was too busy on last submission and i/o got plugged.) The only data gotten from the board in the interrupt handler is typically a tag (or tags) that tells _which_ of many previously initiated DMA transfers have completed. The tag may or may not be gotten via DMA, often it's a memory mapped register on the board, and it's retrieved via readl(), etc, though if the board is coalescing completions and delivering a pile of tags with one interrupt, _that_ would have been done by a DMA, typically. The primary purpose of the interrupt handler in the storage world is to figure out which previously initiated DMA transfers have completed, and notify the upper levels of the OS code that they have completed, so that layer can, among other things, wake up processes waiting for that i/o... the data isn't copied to userspace by the driver (usually), but by some upper layer of the OS (assuming O_DIRECT isn't used. If it is, the DMA goes right to/from userspace directly.) Probably audio drivers are different in some ways, due to the more sequential nature of typical i/o, and the need for low latency and keeping buffers from getting empty, general differences in how audio data vs. generic block i/o is used, etc? Probably depends on the hardware too. Still, I would expect an interrupt on DMA completions... Just wondering, (and I probably managed to get at least some of the above wrong as well.) -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Paul Davis wrote: Paul has it right. I will explain how the audio transfer works on Creative Sound cards, as I know about them, but I assume most sound cards are the same. During setup of the buffer, one configures a number of periods. On Creative cards, one can have anything from 2 to 8 periods per buffer. The sound card hardware has a pointer identifying where the DAC is currently playing samples from. At each period boundary and interrupt is triggered. The stream of DMA transfers is simply started, then keeps running automatically until commanded to stop. Each DMA transfer is 64 bytes, so there are normally multiple DMA transactions between each interrupt. James