Hi Pierre,
On Thu, 2018-08-23 at 11:32 -0700, Andre Guedes wrote:
On Wed, 2018-08-22 at 21:25 -0500, Pierre-Louis Bossart wrote:
On 08/22/2018 07:46 PM, Guedes, Andre wrote:
On Tue, 2018-08-21 at 17:51 -0500, Pierre-Louis Bossart wrote:
> +static int aaf_mclk_start_playback(snd_pcm_aaf_t *aaf) > +{ > + int res; > + struct timespec now; > + struct itimerspec itspec; > + snd_pcm_ioplug_t *io = &aaf->io; > + > + res = clock_gettime(CLOCK_REF, &now); > + if (res < 0) { > + SNDERR("Failed to get time from clock"); > + return -errno; > + } > + > + aaf->mclk_period = (NSEC_PER_SEC * aaf- > > frames_per_pkt) / > > io->rate;
is this always an integer? If not, don't you have a systematic arithmetic error?
NSEC_PER_SEC is 64-bit so I don't see an arithmetic error during calculation (e.g. integer overflow). Not sure this was your concern, though. Let me know otherwise.
No, I was talking about the fractional part, e.g with 256
frames
with 44.1kHz you have a period of 5804988.662131519274376 - so your math adds a truncation. same with 48khz, the fractional part is .333
I burned a number of my remaining neurons chasing a <100 ppb error which led to underruns after 10 hours, so careful now with truncation...
Thanks for clarifying.
Yes, we can end up having a fractional period which is truncated. Note that both 'frames' and 'rate' are configured by the user. The
user
should set 'frames' as multiple of 'rate' whenever possible to avoid inaccuracy.
It's unlikely to happen. it's classic in audio that people want powers of two for fast filtering, and don't really care that the periods are fractional. If you cannot guarantee long-term operation without timing issues, you should add constraints to the frames and rates so that there is no surprise.
Fair enough. So for now I'll add a constraint on frames and rates to unsure no surprises. Later we can revisit this and implement the compesation mechanism you described below.
I've been thinking about this potential underrun situation you described, and I'd like to get your input on the following assessment.
In a typical scenario using real audio hardware, we have one thread producing data to the audio buffer (application thread) and another thread consuming data from the buffer (driver thread). If the consuming thread is slightly faster than the producing one, we end up having an underrun error.
In the AAF plugin scenario, however, we have only one thread (application thread) that is responsible for both producing and consuming data to/from the buffer. Once the buffer is full, the thread consumes data from the buffer, trasmits an AVTP packet, copies more data to the buffer, and blocks until the next transmission time. Since it is single threaded, the potential underrun situation you described doesn't look real (even if the consumption rate is slightly faster than the nominal rate due to the period truncation).
Does the above make sense to you?
BTW, I have been running an experiment with 44.1 kHz and 6 frames for 72+ hours and haven't seen any xrun error so far.
Regards,
Andre