Ensuring accurate playback speed.
Ensuring accurate playback speed.
- Subject: Ensuring accurate playback speed.
- From: Antonio Nunes <email@hidden>
- Date: Sun, 20 Aug 2017 21:11:54 +0200
Hi,
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?
I hope the above description made some sense to someone. :-)
Thank you,
António
_______________________________________________
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