Re: SM501 driver development: problem with start of playback

["Jonas Eymann" <sm501_dev@gmx-topmail.de>]

> At Wed, 22 Nov 2006 10:44:55 +0100,
> Jonas Eymann wrote:
> > 
> > Hi everyone,
> > 
> > I'm currently developing/ enhancing an ALSA driver for a Silicon
> > Motion SM501 compagnion chip which contains also an 8051 µC acting
> > as AC97 controller. It doesn't support DMA and so the copy of audio
> > data is done in the driver. There is a small hardware buffer of 1920
> > bytes which is devided into two halves and used as ring buffer. When
> > the hardware has finished playing one half, it sends an interrupt to
> > the driver so it can fill this half with new audio data while the
> > hardware plays from the other one and so on. In the driver, I use an
> > intermediate buffer with vmalloc(). 
> > 
> > Actually, I have a working driver now, but one small problem remains
> > and I'm absolutely running out of ideas how to fix it: when the
> > playback starts, the hardware expects the buffer to be filled
> > completely (both halves), but the copy routine which does this first
> > filling (snd_sm501_pfill()) only gets one period, not the two which
> > are needed to fill the buffer completely. The second half it just
> > reads zeros. It seems that the intermediate buffer is not yet filled
> > with more data. This results in a gap of one period at the beginning
> > of the playback (it's the second period that doesn't get copied).  
> 
> Hm, this kind of implementation gets more common nowadays for small
> devices, so we may need a better/simpler framework in furture.
> 
> Usually, the filler routine should fill the data as much as possible
> at the time it's called.  The size of available data on the
> itermediate buffer can be calculated via PCM appl_ptr.
> 
> Possibly, helper functions defined in pcm-indirect.h could be used in
> your case.  Check the alsa-devel list archive in the last months,
> threads "Driver design question".  The discussions went on there
> regarding a driver implementation without DMA.  (The pcm-indirect.h
> routines didn't work for his case well, unforutnately, though...)
> 
> 
> Takashi

Thanks for your answer, Takashi!

when I check the appl_ptr in the trigger callback, it gives me exactly one period of available data. As soon as we are in the copy function called from the isr (snd_sm501_copy_pdata), the appl_ptr is a few thousand periods further. Is there a simple way to change the default value for this first portion of available value?
I'm also trying to implement the driver using the pcm-indirect.h. I just thought maybe there is a simpler solution.

Thx for your answers!

Jonas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV