Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin <adrian@mcmen.demon.co.uk>]

On Wed, 2006-03-01 at 15:41 -0500, Lee Revell wrote:

> 
> In this example the period (# of frames between interrupts) is 256.  So
> if the app is waiting to write 512 frames (by setting the avail_min
> software parameter) it will be woken up every other interrupt.  (This
> example only makes sense if there are more than 2 periods per buffer,
> otherwise the app is constantly overwriting the data that the hardware
> is playing).
> 
> Lee


I think I have a good idea why my it is not working now - the DMA
routine which transfers sound samples from the main CPU memory to the
ring buffer of the hardware (which is effectively in a different memory
space) is in a kernel thread which, in essence, never gets rescheduled -
so the app thinks there is sound to be transferred but it never is -
hence it gets wedged.

To fix that I need to know what the alsa subsystem calls inside the
driver when it wants a DMA transfer to resume - I have to reschedule the
kernel thread there.

(I have to use a kernel thread or at least something similar to ensure
that the trigger callback remains atomic due to the nature of the SH
DMAC API.)



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642