[alsa-devel] Driver code with mpc5200 pointer problem.

[Jon Smirl]

On Mon, Apr 27, 2009 at 11:04 AM, Jon Smirl <jonsmirl at gmail.com> wrote:
> On Mon, Apr 27, 2009 at 10:47 AM, Takashi Iwai <tiwai at suse.de> wrote:
>> At Mon, 27 Apr 2009 10:42:10 -0400,
>> Jon Smirl wrote:
>>>
>>> On Mon, Apr 27, 2009 at 10:24 AM, Mark Brown <broonie at sirena.org.uk> wrote:
>>> > On Mon, Apr 27, 2009 at 10:16:16AM -0400, Jon Smirl wrote:
>>> >> On Mon, Apr 27, 2009 at 10:05 AM, Mark Brown <broonie at sirena.org.uk> wrote:
>>> >
>>> >> > It's a fairly hefty change for -rc4. ?From the sounds of it you just
>>> >> > need to add the constraint?
>>> >
>>> >> it is also broken because of the additional requirement of needing to
>>> >> estimate the current position of the DMA transfer. The changes in
>>> >> pcm_lib.c have made it non-functional.  When I went into fix those
>>> >> problems I found a couple more issues.  It's ok for i2s to be broken
>>> >> in this release, Grant and I both know it is broken and won't ship
>>> >> anything based on it.
>>> >
>>> > Well, if you don't see any need to fix it then I guess that's OK.  We
>>> > should probably disable the Kconfig option for the release in case
>>> > people try to use the driver, though.
>>>
>>> I'll add a patch setting Kconfig BROKEN. Is it ok to do the reorg
>>> after flagging it BROKEN?
>>>
>>> >
>>> >> The pcm_lib.c changes may have broken other embedded drivers too.  And
>>> >
>>> > I see no reason to suspect that embedded drivers will be any more or
>>> > less affected than any other ALSA driver?
>>>
>>> The way I'm looking at the code, any CPU hardware that can't report
>>> the position of a partially complete DMA transfer is probably broken.
>>> Is the mpc5200 the only CPU that doesn't support this?
>>
>> Well, the following three are completely different things:
>>
>> A. the driver doesn't report the current DMA position
>> B. the driver reports the wrong DMA position
>> C. the driver calls snd_pcm_period_elapsed() at wrong timing
>>
>> AFAIK, the problem with mpc5200 is either B or C.  It's not about A.
>
> I have fixed all of the other bugs. If I take out the position
> estimation code it fails.
>
> Jaroslav hasn't commented on this yet....

BTW, my theory is that the FIFO fill is causing this. The initial fill
makes it look like the audio hardware is moving too quickly.

I have to sample my DMA position in front of the FIFO fill. CPUs that
can get the current position sample it after the FIFO.

>
> On Sun, Apr 26, 2009 at 2:31 PM, Jaroslav Kysela <perex at perex.cz> wrote:
>> On Sun, 26 Apr 2009, Jon Smirl wrote:
>>
>>> 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)
>>
>> It means that the period DMA operation is too quick in your case and does
>> not correspond to the timing specified by rate. It might be that the FIFO on
>> path is large or rate set to the codec is not correct. What's HZ value on
>> your system and FIFO size? There is HZ/100 margin in the check now.
>
> FIFO is 512 bytes, HZ is 300.
> The rate on the codec is correct and the music sounds right.
>
>>
>>
>> Takashi
>>
>
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com
>



-- 
Jon Smirl
jonsmirl at gmail.com