24 Jul
2007
24 Jul
'07
10:54 p.m.
Clemens Ladisch wrote:
Because the queue output and draining, AFAICS, is implemented in a blocking
manner. When events are being played by the queue in the kernel, the
application blocks, and I have no control on what is being played, except
that I could raise a SIGTERM anytime and end the app.
AFAIK, using the queue is fine for a simple MIDI player, but not for a
sequencer, when you need full control of everything that happens with the
audio output.
What newer kernels? Interval timers, as far as I've tested, result in more
latency than simple sleeps. And yes, I've tried select(), which seems to
be more accurate than usleep().
Received by what? By the extra subscription to the output port? As I've
mentioned in the original post, I know this works but for now, I'd want to
try out simpler sleeps than having an extra output port subscription.
The queue blocks when it plays events. Thus, the supposed callback
function which, as you suggest, should be called after the event is
received, will already be useless since the callback will only be executed
once the queue unblocks.
Thank you very much.
However, I
wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Why? How could I
get the app to <u|nano>sleep() in the most accurate way in
userspace without using the ALSA queue nor the extra subscription to an
output port?
On newer kernels, you could try POSIX interval timers. Or, is there a
drain or output routine that supports callbacks?
Why can't you simply call the callback when some event has been
received?
Regards,
Clemens
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp