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]
