Subject: Coding for ecasound
From: Nolan J. Darilek (nolan_AT_thewordnerd.info)
Date: Fri Oct 03 2003 - 03:10:11 EEST
I've been working on a Ruby API and, while I've made lots of progress,
I'm running up against some issues.
Ecasound produces lots of messages, telling me that it's filling the
audio buffer, etc. However, the only ones I'm really interested in are
the ones that are the result of running my command. I want an eci
command method to block until it is completed, but unfortunately, I don't
know whenm a command is complete, and I think this is causing problems
for me, as I don't know which value to return and when to stop parsing
returned messages for the last command.
Here's an example:
ecasound ('h' for help)> start
4 21
Connecting chainsetup
2 56
(eca-chainsetup) 'rtlowlatency' buffering mode selected.
2 115
(eca-chainsetup) Audio object "null", mode "read".
(audio-io) Format: s16_le, channels 2, srate 44100, interleaved.
2 124
(eca-chainsetup) Audio object "jack_alsa", mode "write".
(audio-io) Format: f32_le, channels 2, srate 44100, noninterleaved.
4 20
Chainsetup connected
2 61
(eca-controller) Connected chainsetup: "command-line-setup".
4 29
Controller/Processing started
256 103 e
(eca-control) ERROR: Warning! No chainsetup connected. Trying to connect currently selected chainsetup.
ecasound ('h' for help)> 4 26
Engine init - Driver start
2 52
(eca-engine) Using realtime-scheduling (SCHED_FIFO).
2 36
(eca-engine) Prefilling i/o buffers.
2 52
(eca-engine) Using realtime-scheduling (SCHED_FIFO).
2 36
(eca-engine) Prefilling i/o buffers.
2 52
(eca-engine) Using realtime-scheduling (SCHED_FIFO).
When a coder using my API calls Chainsetup.start, I want the method to
block, returning when processing begins. Yet I don't know how to
determine, given the above stream of messages, which corresponds to
something like "This message indicates that the last command is
complete."
Also, is there some way to eliminate lots of those messages? The
application I'm working on, for instance, doesn't necessarily care
that you're prefilling I/O buffers, what type of scheduling you're
using, etc. All of these useless messages are piling up, and are
creating some very difficult-to-diagnose bugs. :) It would be great if
I could tell ecasound that I only cared about a certain kind of
message, and then the remaining "useless" messages wouldn't clog up my
queue.
How have other API developers handled this issue? Do you just return
the first message you get, or is there some weird convention that I'm
not aware of? I'm still not clear about the - and emptty types, for
instance; are those what I need to be looking for to determine when to
stop blocking?
Thanks.
This archive was generated by hypermail 2b28 : Fri Oct 03 2003 - 03:08:28 EEST