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 |
> 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 Brady wrote:
> 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 calcu
Thanks for the comments and suggestions.
> On 25 Oct 2018, at 08: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 the hardware chip doesn't
> provide the hwptr update.
As I understand it, this driver
> 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 milliseconds.
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 th
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
>
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 clarifie
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
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
> > +
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
11 matches
Mail list logo
