[alsa-devel] Problem bringing up new alsa driver

[Jon Smirl]

On Sun, Apr 26, 2009 at 1:43 PM, Jaroslav Kysela <perex at perex.cz> 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 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.

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



-- 
Jon Smirl
jonsmirl at gmail.com