Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-12 Thread Mark Brown
On Wed, Nov 11, 2009 at 06:13:25PM -0500, Jon Smirl wrote: > I don't think it is that much more work for ALSA to provide an > accessible field indicating the end of valid data. It's already > tracking appl_ptr. Appl_ptr just needs to be translated into a > physical DMA buffer address and we've bee

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Jon Smirl
On Wed, Nov 11, 2009 at 4:57 PM, Grant Likely wrote: > On Wed, Nov 11, 2009 at 2:34 PM, Jon Smirl wrote: >> On Wed, Nov 11, 2009 at 2:24 PM, Grant Likely >> wrote: >>> On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown >>> wrote: On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: >

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Grant Likely
On Wed, Nov 11, 2009 at 2:34 PM, Jon Smirl wrote: > On Wed, Nov 11, 2009 at 2:24 PM, Grant Likely > wrote: >> On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown >> wrote: >>> On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: > Providing a final valid data point to the driver would possi

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Jon Smirl
On Wed, Nov 11, 2009 at 2:24 PM, Grant Likely wrote: > On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown > wrote: >> On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: >>> > Providing a final valid data point to the driver would possibly even >>> > make things worse since if it were used then

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Jon Smirl
On Wed, Nov 11, 2009 at 1:37 PM, Mark Brown wrote: > On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: > >> There are two solutions: >> 1) tell me where the end of the valid data is. That allows me to >> program the hardware to not enqueue the invalid data. >> 2) For batched hardware, pad

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Mark Brown
On 11 Nov 2009, at 19:24, Grant Likely wrote: On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown wrote: On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: Providing a final valid data point to the driver would possibly even make things worse since if it were used then you'd have the e

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Grant Likely
On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown wrote: > On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: >> > Providing a final valid data point to the driver would possibly even >> > make things worse since if it were used then you'd have the equivalent >> > race where the application has

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Mark Brown
On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: > There are two solutions: > 1) tell me where the end of the valid data is. That allows me to > program the hardware to not enqueue the invalid data. > 2) For batched hardware, pad an extra period with silence after the > end of the stream

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Jon Smirl
On Sat, Nov 7, 2009 at 3:12 PM, Mark Brown wrote: > On Sat, Nov 07, 2009 at 11:51:16AM -0700, Grant Likely wrote: >> On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl wrote: > >> current period.  My understanding of ALSA is that the application is >> supposed to make sure there is enough silence in the b

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-07 Thread Mark Brown
On Sat, Nov 07, 2009 at 11:51:16AM -0700, Grant Likely wrote: > On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl wrote: > current period. My understanding of ALSA is that the application is > supposed to make sure there is enough silence in the buffer to handle > the lag between notification that the l