At Fri, 29 Sep 2006 22:03:09 -0400,
Lee Revell wrote:
>
> On Wed, 2006-09-27 at 19:18 +0200, Takashi Iwai wrote:
> > At Mon, 25 Sep 2006 15:54:22 -0400,
> > Lee Revell wrote:
> > > Here is the code - can you see anything wrong with it? It's derived
> > > from the ALSA dummy driver and still uses the dummy driver's hardware
> > > pointer and timer scheme for calling pcm_period_elapsed() - could this
> > > be the problem? My attempts to track the hardware pointer more
> > > accurately and call pcm_period_elapsed from the copy callback have not
> > > been successful.
> > >
> > > Most of the work is done in the workqueue dream_handle_pcm_queue() and
> > > the copy callback.
> >
> > Well, when you have an intermediate buffer (allocated via
> > snd_pcm_lib_malloc(), you don't need copy and silent callbacks. The
> > data is written on the intermediate buffer. Then, the workq copies
> > the data again from this buffer to the hardware in the background.
> >
> > As I mentioned, the helpers in pcm-indirect.h might make things eaiser
> > for such an implementation. In your case, a pseudo code would look
> > like below.
>
> OK, I've implemented this, but it's still not quite working.
>
> I've noticed that with the PCM indirect implementation, the pointer
> callback invokes the ack callback every time:
>
> pcm-indirect.h:
>
> 90 */
> 91 static inline snd_pcm_uframes_t
> 92 snd_pcm_indirect_playback_pointer(snd_pcm_substream_t *substream,
> 93 snd_pcm_indirect_t *rec, unsigned int ptr)
> 94 {
>
> [ ... ]
>
> 103 if (substream->ops->ack)
> 104 substream->ops->ack(substream);
>
> But, this cannot work with our hardware, if the ack callback always
> transfers 0x2000 words from the hardware, because the pointer callback
> is invoked many times per period.
Actually it's not always 0x2000 words in this case. The ack calls
snd_pcm_indirect_playback_transfer() and this passes the size of data
to be copied as the argument.
> What are the exact rules/semantics for when the ack callback is invoked?
>
> Also, how should I know when to invoke snd_pcm_period_elapsed? It only
> seems to work if I call it from a timer - if I move it to the ack or
> copy callback, playback hangs after the first chunk of audio is played.
The invokation of snd_pcm_period_elapsed() must be in an interrupt
handler (in your case a timer handler). The pcm_indirect framework
doesn't provide the irq mechanism but only the transfer mechanism.
When snd_pcm_period_elapsed() is called, the ack is called from the
PCM core layer so you don't need any other tasks.
Takashi
-------------------------------------------------------------------------
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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel
