From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jonas Eymann" Subject: Re: SM501 driver development: problem with start of playback Date: Mon, 27 Nov 2006 19:34:51 +0100 Message-ID: <20061127183451.71080@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@lists.sourceforge.net Errors-To: alsa-devel-bounces@lists.sourceforge.net To: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org > 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 =B5C 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 fro= m the isr (snd_sm501_copy_pdata), the appl_ptr is a few thousand periods fu= rther. Is there a simple way to change the default value for this first por= tion of available value? I'm also trying to implement the driver using the pcm-indirect.h. I just th= ought 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=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV