Apologies for the delay coming back to this.
Having had a long look at the further implications of this proposed change, I
would like to withdraw the suggested patch.
I agree that is would seem excessive to have to change the PCM core to
accommodate it. Furthermore, the idea only works if is
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 |
>SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID |
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 |
>SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID |
Hi Mike,
> Mike Brady hat am 11. November 2018 um 19:21
> geschrieben:
>
>
> When the BCM2835 audio output is used, userspace sees a jitter up to 10ms
> in the audio position, aka "delay" -- the number of frames that must
> be output before a new frame would be played.
> Make this a bit nicer
Hi Mike,
> Mike Brady hat am 11. November 2018 um 19:21
> geschrieben:
>
>
> When the BCM2835 audio output is used, userspace sees a jitter up to 10ms
> in the audio position, aka "delay" -- the number of frames that must
> be output before a new frame would be played.
> Make this a bit nicer
5 matches
Mail list logo
