25 Sep
2009
25 Sep
'09
1:20 p.m.
On Thu, Sep 24, 2009 at 06:37:56PM -0400, Paul Davis wrote:
On Tue, Sep 22, 2009 at 12:45 PM, Fons Adriaensen
<fons(a)kokkinizita.net> wrote:
Interesting ?
* How can this option be modified ?
* If varyspeed slaving is enabled,
- How many channels can be resampled ?
On my 2G P4 libsamplerate has trouble with
just 5 channels in real time.
- Will Ardour resample signals being recorderd
as well ?
Note that the latter is essential. If a signal is recorded
with some speed error, and then played back with the same
speed error the result should be the original signal. Since
it will be resampled on playback it has to be resampled on
record as well, in the opposite direction.
Ciao,
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.
An app decoding SMPTE to jack transport position
would be needed if
you want to slave a Jack app (e.g. Ardour) to SMPTE. This implies that
the slaved app is able to adjust its speed over a small range while
preserving full audio quality - the equivalent of a tape machine made
to run slightly slow or fast. This means resampling, for both playback
and recording. Since Ardour AFAIK can't do this, it can't be slaved to
SMPTE or any other timecode that doesn't run in sync with the sample
clock. It may locate to and start at the correct position, but since
its speed is fixed it will not remain in sync while rolling.
this isn't quite correct. ardour can slave to "varispeed" sync
sources, and tracks them with remarkable accuracy. there is an option
that is on by default which tells ardour to expect the timecode source
to be sample-clock-locked to whatever is driving JACK. if it is
enabled, ardour won't bother to even look for speed fluctuations. if
it is off, ardour will do varispeeding to stay very very closely in
sync with the timecode source. this option cannot currently be changed
via the GUI.