Re: [RFC - AAF PCM plugin 3/5] aaf: Implement Playback mode support

["Guedes, Andre" <andre.guedes@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3743 bytes --]

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

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3262 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]