18 Nov
2003
18 Nov
'03
5:33 p.m.
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 <jussi.laako(a)pp.inet.fi>
6:24 p.m.
On Tue, 2003-11-18 at 23:59, Paul Davis wrote:
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.
At least it works better for me.. :)
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
-
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... 
6:57 p.m.
On Tue, 2003-11-18 at 23:59, Paul Davis wrote:
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
-
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...
19 Nov
19 Nov
1:45 p.m.
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 <jussi.laako(a)pp.inet.fi>
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
7467
days inactive
7468
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
2 participants
participants (2)
-
Jussi Laako -
Paul Davis