Re: [ecasound] sync-related issues

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] sync-related issues
From: Kai Vehmanen (
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

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

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

 Audio software for Linux!

-- To unsubscribe send message 'unsubscribe' in the body of the message to <>.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Nov 07 2001 - 21:50:11 EET