Re: [linux-audio-dev] oss driver for jack 0.90 rev3
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]
[linux-audio-dev] oss driver for jack 0.90 rev3
Now the oss driver for jack 0.90 starts to shape up. This could be considered as alpha version. Changes: - Conditionally compiled two thread implementation for NPTL (possibly also works with LinuxThreads, untested) - Fixed a load of bugs This version has been tested with CMI8738, ENS1371 and M-Audio Delta1010. (OSS 3.9.8a) This version has been tested to work under load up to 8-in, 8-out, 24-bit 96 kHz with period size of 128. Patch available at http://www.sonarnerd.net/linux/jack_oss.patch and RPMs and tarball at http://www.sonarnerd.net/linux/ Someone familiar with autoconf/automake could see the drivers/oss/Makefile.am for some better way of enabling NPTL/barrier stuff... ;) -- Jussi Laako [EMAIL PROTECTED]
Re: [linux-audio-dev] oss driver for jack 0.90 rev3
- Conditionally compiled two thread implementation for NPTL (possibly also works with LinuxThreads, untested) would you mind explaining why you are using 2 threads? it seems pointless, but perhaps i'm missing something...
Re: [linux-audio-dev] oss driver for jack 0.90 rev3
On Tue, 2003-11-18 at 23:59, Paul Davis wrote: - Conditionally compiled two thread implementation for NPTL (possibly also works with LinuxThreads, untested) would you mind explaining why you are using 2 threads? it seems pointless, but perhaps i'm missing something... One is for input and other one is for output. It is especially useful when input and output goes through different device/driver/hardware and also for SMP. Just allows simultaneous system calls. 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(). you could also use the standard no-thread support infrastructure that JACK now contains, consolidating our ability to move all JACK drivers forward together. 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. i'm not trying to argue against your design - in some ways, its quite clever. its just that it goes in a different direction than the ALSA driver does; not entirely suprising given the differences between OSS and ALSA. 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. --p