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.
Jaroslav
-----
Jaroslav Kysela <perex@xxxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
