Hi Takashi. My apologies — t turns out I was wrong. My measurements were
systematically wrong due to integer truncation going from 64 bit to 32 bit
representation.
Apologies
Mike
> On 11 Oct 2018, at 13:53, Mike Brady wrote:
>
> Hi Takashi. Just testing out the updated bcm2835 aud
e,
>
> 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
s -- 2,000 parts per million --
to result in an inaccurate estimate, whereas
crystal- or resonator-based clocks typically have an
inaccuracy of 10s to 100s of parts per million.
Signed-off-by: Mike Brady
---
Changes in v2 -- remove inappropriate addition of SNDRV_PCM_INFO_BATCH flag
.../vc0
s -- 2,000 parts per million --
to result in an inaccurate estimate, whereas
crystal- or resonator-based clocks typically have an
inaccuracy of 10s to 100s of parts per million.
Signed-off-by: Mike Brady
---
.../vc04_services/bcm2835-audio/bcm2835-pcm.c | 23 ++-
.../vc04_servic
Hi Kirill. Thanks again for your comments.
> On 24 Oct 2018, at 19:06, Kirill Marinushkin wrote:
>
> Hello Mike,
>
> On 10/24/18 10:20, Mike Brady wrote:
>> Hi Kirill. Thanks for your comments.
>>
>>> On 22 Oct 2018, at 23:25, Kirill Marinushkin
&
> On 25 Oct 2018, at 08:37, Takashi Iwai wrote:
>
> On Thu, 25 Oct 2018 00:02:34 +0200,
> Kirill Marinushkin wrote:
>>
When you play sound - the pointer increments.
>>>
>>> Unfortunately, when you play sound, the pointer does not actually
>>> increment, for up to about 10
Hi Kirill. Thanks for the post.
Mike
> On 25 Oct 2018, at 18:20, Kirill Marinushkin wrote:
>
> Hello Takashi, Mike,
>
> @Takashi
>
> On 10/25/18 09:37, Takashi Iwai wrote:
>> Well, in the API POV, it's nothing wrong to keep hwptr sticking while
>> updating only delay value. It implies that
as mentioned above).
All the best,
Mike
> FYI, there is
>> a discussion of the effects of a downstream equivalent of this suggested
>> patch
>> at:
>> https://github.com/raspberrypi/firmware/issues/1026#issuecomment-415746016.
>
> Thank you for the link, it clarified
> On 5 Nov 2018, at 16:11, Takashi Iwai wrote:
>
> On Mon, 05 Nov 2018 16:57:07 +0100,
> Mike Brady wrote:
>>
>>> One another thing I'd like to point out is that the value given in the
>>> patch is nothing but an estimated position, optimistically calcul
> On 6 Nov 2018, at 21:31, Takashi Iwai wrote:
>
> On Tue, 06 Nov 2018 22:05:11 +0100,
> Mike Brady wrote:
>>
>>
>>> On 5 Nov 2018, at 16:11, Takashi Iwai wrote:
>>>
>>> On Mon, 05 Nov 2018 16:57:07 +0100,
>>> Mike Brad
Hi Takashi.
> On 9 Oct 2018, at 14:44, Takashi Iwai wrote:
>
> On Tue, 09 Oct 2018 15:18:15 +0200,
> Mike Brady wrote:
>>
>>>> @Mike: Do you want to write a patch series which upstream "interpolate
>>>> audio delay" and addresses Takashi'
ttp://0pointer.de/blog/projects/guide-to-sound-apis).
On LMKL.org, Takashi wrote:
> Date Wed, 19 Sep 2018 11:52:33 +0200
> From Takashi Iwai <>
> Subject Re: [PATCH 17/29] staging: bcm2835-audio: Add 10ms period
> constraint
> [snip]
> That's OK, as long as the computation is accurate enough (at least not
> exceed the actual position) and is light-weight.
> [snip]
The overhead is small -- an extra ktime_get() every time a GPU message
is sent -- and another call and a few calculations whenever the delay
is sought from userland.
At 48,000 frames per second, i.e. approximately 20 microseconds per frame, it
would take a clock inaccuracy of roughly
20 microseconds in 10 milliseconds -- 2,000 parts per million — to result in an
inaccurate estimate.
Crystal or resonator-based clocks typically have an inaccuracy of 10s to 100s
of parts per million.
Finally, to see the effect of the absence and presence of this interpolation,
please have a look at this:
https://github.com/raspberrypi/firmware/issues/1026#issuecomment-415746016,
where a downstream version of this fix was being discussed.
Best wishes
Mike Brady
?
Regards
Mike
> On 9 Oct 2018, at 16:28, Mike Brady wrote:
>
> Hi Takashi.
>
>> On 9 Oct 2018, at 14:44, Takashi Iwai wrote:
>>
>> On Tue, 09 Oct 2018 15:18:15 +0200,
>> Mike Brady wrote:
>>>
>>>>> @Mike: Do you want to write
Hi Stefan. Thanks for this.
> On 19 Sep 2018, at 13:41, Stefan Wahren wrote:
>
> Hi,
>
> [add Phil and Mike]
>
> Am 19.09.2018 um 11:52 schrieb Takashi Iwai:
>> On Wed, 19 Sep 2018 11:42:22 +0200,
>> Stefan Wahren wrote:
>>> Hi Takashi,
>>>
>>> Am 04.09.2018 um 17:58 schrieb Takashi Iwai:
Hi Kirill. Thanks for the post.
Mike
> On 25 Oct 2018, at 18:20, Kirill Marinushkin wrote:
>
> Hello Takashi, Mike,
>
> @Takashi
>
> On 10/25/18 09:37, Takashi Iwai wrote:
>> Well, in the API POV, it's nothing wrong to keep hwptr sticking while
>> updating only delay value. It implies that
> On 25 Oct 2018, at 08:37, Takashi Iwai wrote:
>
> On Thu, 25 Oct 2018 00:02:34 +0200,
> Kirill Marinushkin wrote:
>>
When you play sound - the pointer increments.
>>>
>>> Unfortunately, when you play sound, the pointer does not actually
>>> increment, for up to about 10
s -- 2,000 parts per million --
to result in an inaccurate estimate, whereas
crystal- or resonator-based clocks typically have an
inaccuracy of 10s to 100s of parts per million.
Signed-off-by: Mike Brady
---
.../vc04_services/bcm2835-audio/bcm2835-pcm.c | 23 ++-
.../vc04_servic
Hi Takashi. My apologies — t turns out I was wrong. My measurements were
systematically wrong due to integer truncation going from 64 bit to 32 bit
representation.
Apologies
Mike
> On 11 Oct 2018, at 13:53, Mike Brady wrote:
>
> Hi Takashi. Just testing out the updated bcm2835 aud
ote:
>
> On Sun, 11 Nov 2018 19:21:29 +0100,
> Mike Brady wrote:
>>
>> /* hardware definition */
>> static const struct snd_pcm_hardware snd_bcm2835_playback_hw = {
>> .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
e,
>
> 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
s -- 2,000 parts per million --
to result in an inaccurate estimate, whereas
crystal- or resonator-based clocks typically have an
inaccuracy of 10s to 100s of parts per million.
Signed-off-by: Mike Brady
---
Changes in v2 -- remove inappropriate addition of SNDRV_PCM_INFO_BATCH flag
.../vc0
as mentioned above).
All the best,
Mike
> FYI, there is
>> a discussion of the effects of a downstream equivalent of this suggested
>> patch
>> at:
>> https://github.com/raspberrypi/firmware/issues/1026#issuecomment-415746016.
>
> Thank you for the link, it clarified
Hi Kirill. Thanks again for your comments.
> On 24 Oct 2018, at 19:06, Kirill Marinushkin wrote:
>
> Hello Mike,
>
> On 10/24/18 10:20, Mike Brady wrote:
>> Hi Kirill. Thanks for your comments.
>>
>>> On 22 Oct 2018, at 23:25, Kirill Marinushkin
&
> On 6 Nov 2018, at 21:31, Takashi Iwai wrote:
>
> On Tue, 06 Nov 2018 22:05:11 +0100,
> Mike Brady wrote:
>>
>>
>>> On 5 Nov 2018, at 16:11, Takashi Iwai wrote:
>>>
>>> On Mon, 05 Nov 2018 16:57:07 +0100,
>>> Mike Brad
?
Regards
Mike
> On 9 Oct 2018, at 16:28, Mike Brady wrote:
>
> Hi Takashi.
>
>> On 9 Oct 2018, at 14:44, Takashi Iwai wrote:
>>
>> On Tue, 09 Oct 2018 15:18:15 +0200,
>> Mike Brady wrote:
>>>
>>>>> @Mike: Do you want to write
> On 5 Nov 2018, at 16:11, Takashi Iwai wrote:
>
> On Mon, 05 Nov 2018 16:57:07 +0100,
> Mike Brady wrote:
>>
>>> One another thing I'd like to point out is that the value given in the
>>> patch is nothing but an estimated position, optimistically calcul
Hi Stefan. Thanks for this.
> On 19 Sep 2018, at 13:41, Stefan Wahren wrote:
>
> Hi,
>
> [add Phil and Mike]
>
> Am 19.09.2018 um 11:52 schrieb Takashi Iwai:
>> On Wed, 19 Sep 2018 11:42:22 +0200,
>> Stefan Wahren wrote:
>>> Hi Takashi,
>>>
>>> Am 04.09.2018 um 17:58 schrieb Takashi Iwai:
ttp://0pointer.de/blog/projects/guide-to-sound-apis).
On LMKL.org, Takashi wrote:
> Date Wed, 19 Sep 2018 11:52:33 +0200
> From Takashi Iwai <>
> Subject Re: [PATCH 17/29] staging: bcm2835-audio: Add 10ms period
> constraint
> [snip]
> That's OK, as long as the computation is accurate enough (at least not
> exceed the actual position) and is light-weight.
> [snip]
The overhead is small -- an extra ktime_get() every time a GPU message
is sent -- and another call and a few calculations whenever the delay
is sought from userland.
At 48,000 frames per second, i.e. approximately 20 microseconds per frame, it
would take a clock inaccuracy of roughly
20 microseconds in 10 milliseconds -- 2,000 parts per million — to result in an
inaccurate estimate.
Crystal or resonator-based clocks typically have an inaccuracy of 10s to 100s
of parts per million.
Finally, to see the effect of the absence and presence of this interpolation,
please have a look at this:
https://github.com/raspberrypi/firmware/issues/1026#issuecomment-415746016,
where a downstream version of this fix was being discussed.
Best wishes
Mike Brady
Hi Takashi.
> On 9 Oct 2018, at 14:44, Takashi Iwai wrote:
>
> On Tue, 09 Oct 2018 15:18:15 +0200,
> Mike Brady wrote:
>>
>>>> @Mike: Do you want to write a patch series which upstream "interpolate
>>>> audio delay" and addresses Takashi'
29 matches
Mail list logo
