On Sun, Apr 26, 2009 at 1:43 PM, Jaroslav Kysela <perex@xxxxxxxx> wrote: > On Sun, 26 Apr 2009, Takashi Iwai wrote: > >> At Sun, 26 Apr 2009 11:42:14 -0400, >> Jon Smirl wrote: >>> >>> On Sun, Apr 26, 2009 at 7:14 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: >>>> >>>> At Sat, 25 Apr 2009 17:28:55 -0400, >>>> Jon Smirl wrote: >>>>> >>>>> These new patches have broken audio support on the mpc5200.... >>>> >>>> Then the lowlevel callbacks are likely wrong :) >>>> >>>>> They assume that the hardware is capable of telling where the DMA >>>>> engine is in the middle of an operation. >>>> >>>> Well, nothing new by these patches. The original PCM core >>>> implementation has been designed in that way. These changes may check >>>> some bogus value more strictly. >>>> >>>> If the hardware doesn't support it, it needs report at least some >>>> "sane" value; i.e. it must not be over the real position, but not >>>> below the previous pointer. >>> >>> >>> >>>> In the worst case, the driver just needs to report the same position >>>> at the previous period boundary until the next >>>> snd_pcm_period_elapsed(). >>> >>> That's doesn't work anymore. The PCM code is using jiffies to estimate >>> where the pointer needs to be. >>> I used the same jiffies to fake up a hardware position. >> >> Hrm, then it's a breakage. The quantum position must be still >> supported. >> Jaroslav, could you check that? It's your new code... > > My code checks only if samples delta is over expected jiffies delta, thus > this case should not be evaluated as a wrong ring buffer position. It just > problem with John's broken lowlevel driver. > > But adding finer resolution for pointer callback using jiffies or other > timing source might make sense when hardware does not transfer whole buffer > quickly (just small FIFO is on path). I'm not only sure, if we should add > this code to the pcm midlevel code, because it's relatively easy to > implement this in the lowlevel driver. I set snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); I don't get errors from ALSA when playing with this set. I then tried removing the DMA position estimating code. delta = jiffies - s->jiffies; delta = delta * runtime->rate / HZ; frames = bytes_to_frames(substream->runtime, count); return frames + delta; If I take this out I get these errors... ALSA sound/core/pcm_lib.c:264: PCM: hw_ptr skipping! [Q] (pos=11026, delta=5513, period=5513, jdelta=33/37/0) Once I hit one of those, the attempt at pointer fix up makes things worse... ALSA sound/core/pcm_lib.c:264: PCM: hw_ptr skipping! [Q] (pos=16539, delta=11026, period=5513, jdelta=38/75/0) ALSA sound/core/pcm_lib.c:264: PCM: hw_ptr skipping! [Q] (pos=0, delta=16539, period=5513, jdelta=37/112/0) ALSA sound/core/pcm_lib.c:264: PCM: hw_ptr skipping! [Q] (pos=5513, delta=22052, period=5513, jdelta=38/150/0) > > Jaroslav > > ----- > Jaroslav Kysela <perex@xxxxxxxx> > Linux Kernel Sound Maintainer > ALSA Project, Red Hat, Inc. > -- Jon Smirl jonsmirl@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
