Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Paul Davis <paul@linuxaudiosystems.com>]

>poll() is quite complex and with a good number of locks in the path the
>maximum latency increases accordingly.

how can poll(2) be more complex than read/write? if it is, it
shouldn't be ;)

>btw., couldnt jackd use a separate input and output thread (of identical
>priority), to be purely read()/write() based? This method should also
>solve the priority problems of poll(): the thread woken up later will do
>the work later. (hence the _earlier_ interrupt source will be handled
>first.) With poll() how do you tell which fd needs attention first, if
>both are set?

we don't really care which one needs attention "first". the jack process
cycle ends up consuming and producing data - 

      before the ALSA backend tells jackd to run the process cycle,
         it will read the data from the capture fd (though its done
	 using mmap, so there is no read(2) call)

      just before jackd goes back to sleep waiting for the next
         interrupt, the ALSA backend will write data to the playback fd
	 (again, using mmap, so there is no actual write(2) call)

it is important to use mmap - it avoids multiple kernel entries and
data copying. for consumer cards this doesn't matter much, but for
high end multichannel cards, the data copy would be inexcusable.

--p