[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22867d63-12f1-31f7-acb6-ce9a58fcbe71@gmail.com>
Date: Thu, 18 Oct 2018 21:48:36 +0200
From: Kirill Marinushkin <k.marinushkin@...il.com>
To: Mike Brady <mikebrady@...com.net>
Cc: eric@...olt.net, stefan.wahren@...e.com,
gregkh@...uxfoundation.org, f.fainelli@...il.com, tiwai@...e.de,
nishka.dasgupta_ug18@...oka.edu.in, julia.lawall@...6.fr,
linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, devel@...verdev.osuosl.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: bcm2835-audio: interpolate audio delay
Hello Mike,
On 10/18/18 12:57, Mike Brady wrote:
> + ktime_t now = ktime_get();
> +
> + /* Give userspace better delay reporting by interpolating between GPU
> + * notifications, assuming audio speed is close enough to the clock
> + * used for ktime
> + */
> +
> + if ((ktime_to_ns(alsa_stream->interpolate_start)) &&
> + (ktime_compare(alsa_stream->interpolate_start, now) < 0)) {
> + u64 interval =
> + (ktime_to_ns(ktime_sub(now,
> + alsa_stream->interpolate_start)));
> + u64 frames_output_in_interval =
> + div_u64((interval * runtime->rate), 1000000000);
> + snd_pcm_sframes_t frames_output_in_interval_sized =
> + -frames_output_in_interval;
> + runtime->delay = frames_output_in_interval_sized;
> + }
This doesn't look like a good solution for me. More like a workaround. What is
the root cause of the delay?
Best Regards,
Kirill
Powered by blists - more mailing lists