Re: Ensuring accurate playback speed.
Re: Ensuring accurate playback speed.
- Subject: Re: Ensuring accurate playback speed.
- From: Antonio Nunes <email@hidden>
- Date: Mon, 21 Aug 2017 11:13:04 +0200
Thanks Brian, for the thorough explanation.
Kind regards,
António
SintraWorks
> On 20 Aug 2017, at 22:03, Brian Willoughby <email@hidden> wrote:
>
> 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