[alsa-devel] Problem bringing up new alsa driver

[Jaroslav Kysela]

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 at 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 at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.