Subject: Re: [ecasound] sync-related issues
From: Kai Vehmanen (k_AT_eca.cx)
Date: Wed Nov 07 2001 - 21:56:17 EET
On Tue, 6 Nov 2001, John Denker wrote:
> Adding hw-sync seems like the best option. C++ is the native language
> around here.
[...]
> I'm allergic to kludges. (Otherwise I would have gone with the loopback
Aa, music to my ears! :)
> Of course fully "generic" HW sync is impossible, since not all hardware
> even supports the concept, but if we're going to go to the trouble of
> messing with this at all we might as well try to do a good job.
[...]
> That corresponds to what we are doing now, with the addition of the
> "use-hw-sync" command, which would cause all chains to wait until started
Hmm, true, a special mode is probably needed at least at first (we could
also automatically check wheter hw-sync is supported by all rt-devices,
but this may be tricky).
I'd suggest using the -z:feature syntax, ie. something like -z:hwsync (and
for disabling -z:nohwsync).
> use-hw-sync
cs-option -z:hwsync
> Any suggestions on how to implement this?
Good place to start is libecasound/eca-engine.cpp, and the function
start() (lines 694-751). This function is called when processing is
started (start or run). If multitrack mode is enabled, start() calls
multitrack_start() (in the same file).
Basicly ecasound iterates through all input devices and issues their
start() functions (see libecasound/audioio.h). Then same is done for
output devices.
If we want to use hw-sync, the above mechanism has to be
altered. Possible approaches:
- ALSA devices are aware of each other (in AUDIO_IO::start() of
the master device, we actually start all rt-devices;
in slave device AUDIO_IO::start() function, we don't do
anything); this solution is transparent to the engine code
- engine is able to pick the master ALSA device and only
issue start for that specific device
In some regards, this is close to ecasound loop-devices (audioio-loop.h).
Like ALSA master and slave devices, also loop devices must be aware of
other loop objects. This special connection is established in the object
factory code (see eca-object-factory.h, functions create_loop_input() and
create_loop_output()).
All in all, this is not a trivial problem. In Ardour this is much, much
easier because Ardour is already tied closely to ALSA. For ecasound, ALSA
objects are just like any other audio objects that implement the AUDIO_IO
interface.
Relevant source files are:
AUDIO_IO class interface, implemented by all audio devices:
- libecasound/audioio.h
The ALSA 0.9.x plugin, implements the AUDIO_IO interface:
- libecasound/plugins/audioio-alsa3.cpp
Chainsetup code:
- libecasound/eca-chainsetup.cpp
- libecasound/eca-chainsetup-parser.cpp
Ecasound's engine:
- libecasound/eca-engine.cpp
Object factory; used to create AUDIO_IO objects:
- libecasound/eca-object-factory.cpp
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Wed Nov 07 2001 - 21:50:11 EET