On Wed, 2003-11-19 at 00:56, Paul Davis wrote: > if you used poll(2) or select(2), you could do simultaneous waits on > each direction, regardless of whether they use different devices or > not. you'd then reduce the context switches and the overhead of > synchronize().
Context switches are not problem when thread's main function is to sleep on blocking descriptor. And synchronize() has minimal overhead on system which have futexes and very small in any case. Sleeping on system call (on waitqueue) doesn't take any noticeable amount of CPU time. This works especially well on SMP machines. Not all OSS Lite drivers support poll() or select(). > i also note that you're also not using mmap, resulting in extra > copying of significant quantities of data on every cycle for > multichannel cards. the cpu cycles for this can be significant when > you get down to very low latency on hammerfall cards, for example. Memorymapping buffers of fast running devices is problematic. (Soundcards are relatively slow however.) Also the pagefault handler takes some time. Another point is that normal gcc memcpy() is significantly slower compared to copy_to/from_user() on modern hardware. Third is that mapping DMA buffers of 32-bit cards to memory space of 64-bit processors is another story. If the driver is mapping some secondary buffer allocated from vm then it's different. > i didn't really sense an answer to my question about your willingness > to maintain your OSS driver in the face of any future changes in > JACK. if i can get a clear answer on this, i'll make a decision about > adding it to CVS. It depends on how much the jack is going to change, my motivation, time and of course on user demand. All I can say is that I will do it for unspecified time, unless it takes too much time from my actual projects. I don't have have any control on jack, so I'm not going to tie myself up on something which needs unspecified amount of work. -- Jussi Laako <[EMAIL PROTECTED]>