[lkml]   [1998]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: sb16 duplex fix
Hannu Savolainen wrote:
> On Wed, 14 Oct 1998, Alan Cox wrote:
> > I would agree with this, mmap() on sound is a neat hack but it is very very
> > questionable if it is needed or useful. Its really a quake compatibility
> > feature 8)
> I second this opinion.
> It looks like sound devices in future will have more and more local
> buffer memory or FIFO space which makes using mmap() impossible, difficult
> or at least rather inpractical. I don't see any reason to support this
> feature in future if somebody gets the Quake folks to implement a non
> mmap() version.
> This feature will disappear from the OSS programmer's guide in near
> future.

I'd like to convert a few applications that now have their own sound
driver to use the standard sound driver. However, currently I can't, as
a few features are missing, namely the following:

- "true queue length": the app should be able to query the true queue
including on-card FIFO buffers etc. (and possibly including codec

- the application should be able to query and eventually set (within
the wakeup latency (this is related to the fragment size)

- I need the possibility to switch between input and output (and vice
as fast as possible on half duplex cards, that means I need a
to suppress lengthy autocalibration cycles when switching. Not
a new API element, could be implicit when read follows write and vice

- It would be nice if it was possible to tell the sound driver something
"only wake me up when there are at least N samples (or bytes) in the
receive queue"
and "only wake me up if there are more than N samples free in the
transmit queue
or the transmit queue contains less than M samples".

Can we agree on an API for this?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:45    [W:0.027 / U:4.840 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site