19 Nov
2003
19 Nov
'03
3:29 p.m.
On Wed, 2003-11-19 at 00:56, Paul Davis wrote:
OK, your choice. From my perspective, 1 context switch is on the order
of 2-6% of the available CPU cycles for a 64 frames-per-interrupt
configuration. And sleeping in two threads on what in just about every
case will be one piece of hardware with synchronized playback and
capture streams seems like a waste of resources to me. 99 times out of
a hundred, or more, the "ready" bit on a task is set from the
interrupt handler, and it will set both the playback and capture
waitqueues. as a result, you now have to wake up two threads when one
would do. you're accomplishing nothing that i can see, other than
adding a certain kind of theoretical elegance in your code. and
theoretical elegance is for the API, not the implementation :)
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.
do you have a URL i can read about this?
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.
ALSA seems to be handling it perfectly OK so far.
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.
I'll merge it into CVS after thanksgiving (nov 27th) here (first
time i'm likely to have the time).
--p