Re: Ensuring accurate playback speed.
Re: Ensuring accurate playback speed.
- Subject: Re: Ensuring accurate playback speed.
- From: Brian Willoughby <email@hidden>
- Date: Sun, 20 Aug 2017 13:03:02 -0700
The issue you describe is not specific to CoreAudio. It is the nature of
digital audio recording whenever multiple devices are used.
Unless you connect Word Clock or some other digitally clocked signal between
two or more devices, there will always be some drift between them. It is
impossible for two or more digital sample clocks to remain sample accurate over
a long period of time unless those clocks are connected electrically (or
optically). Your Mac or iOS device, just like any digital audio device, each
has a crystal oscillator that is the master clock. Crystals are very accurate,
but no two of them precisely match (and even if they did, their clocks would
not necessarily happen at the exact same instant). So, even if you set both
devices to 48 kHz sample rate, the samples will not be the same when separate
recordings are made on the two devices. The analog waveforms will match fairly
closely, but the digital samples could be vastly different.
In recording studios, and even in advanced mobile recording setups, there are
multiple technologies to deal with this issue. One is Word Clock. With Word
Clock, a master clock can be connected to all slave devices, and if everything
is set correctly then their samples will all be aligned no matter how long the
recording. Other options include AES3 digital audio, ADAT, and a few others.
These latter connections pass audio as well as clock, and may be more or less
accurate (in terms of clock jitter) compared to Word Clock technology.
Bottom line: this is not an issue with RemoteIO.
Brian Willoughby
Sound Consulting
On Aug 20, 2017, at 12:11 PM, Antonio Nunes <email@hidden> wrote:
> On some software I’ve been writing, I use remoteIO to playback very short
> sound files. In the rendering callback I provide the required samples. This
> is all working well and playback sounds great.
>
> The only issue I have is that playback appears to be somewhat inaccurate, in
> the sense that it is overall a tad too quick. The thing is, I also have the
> ability for a playback session to be recorded live to disk. When I inspect
> the resulting sound file in a sound editor, I see perfect results. Lets say I
> set everything up for a bleep to play 60 times a minute and I start playback
> with live recording to audio file on. I also record the playback session
> through a microphone on another device (my Mac). After the session the file
> recorded through micorophone is trimmed so that the first bleep starts a 0
> time.
>
> When I subsequently inspect both files in a sound editor I see that the file
> recorded file has each sample start exactly on time at every second advance,
> throughout the whole file. In the file recorded through microphone though, I
> can see that each subsequent bleep starts ever so slightly too early,
> resulting in an accumulating discrepancy.
>
> I haven’t been able to find a clue as to why the externally recorded sound
> file doesn’t show equal results to the internally recorded sound file. When I
> playback and simultaneously record through microphone the sample perfect
> sound file, the results are as expected, without accumulating error. My guess
> is that maybe remote IO is playing back the samples ever so slightly too
> fast.
>
> In fact…as I was writing this, I realised I could also playback the
> internally recorded sound file on my iOS device and record it via mike on my
> Mac. When I do that, I see a very similar discrepancy to what I see when I
> record the live session via mike on my Mac. So: could it be that remoteIO’s
> actually playback speed is slightly inaccurate, where samples are played back
> a fraction of a millisecond too fast, resulting in an accumulating error?
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden