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@suse.de 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.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.