DMA: do all drivers need it?

DMA: do all drivers need it?

[Guilhem Tardy]

Hi,

I am starting to write an sound driver for a card with no previous support and
would like to know if DMA is necessary as per the ALSA framework itself. My
card doesn't support DMA, yet. So if your answer is no, I would need to
fallback on OSS for the time being.

Thanks,
Guilhem.


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: DMA: do all drivers need it?

[Paul Davis]

>I am starting to write an sound driver for a card with no previous support and
>would like to know if DMA is necessary as per the ALSA framework itself. My
>card doesn't support DMA, yet. So if your answer is no, I would need to
>fallback on OSS for the time being.

its not. ALSA doesn't require anything but a fairly small set of
function pointers to be initialized so that the "mid-level" code can
manage the device. as long as there is some way to move data to and
from the audio interface (which seems like a pretty basic assumption),
you just have to wrap it up and present it to the mid-level code.

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: DMA: do all drivers need it?

[Takashi Iwai]

At Sat, 04 May 2002 07:41:28 -0400,
Paul Davis wrote:
> 
> >I am starting to write an sound driver for a card with no previous support and
> >would like to know if DMA is necessary as per the ALSA framework itself. My
> >card doesn't support DMA, yet. So if your answer is no, I would need to
> >fallback on OSS for the time being.
> 
> its not. ALSA doesn't require anything but a fairly small set of
> function pointers to be initialized so that the "mid-level" code can
> manage the device. as long as there is some way to move data to and
> from the audio interface (which seems like a pretty basic assumption),
> you just have to wrap it up and present it to the mid-level code.

in fact, you don't need even wrappers, if update of periods can be
done asynchronously, that is, either by hardware interrupts or timer
interrupts.

for example, recently i wrote a code to play pcm using emu8000
wavetable engine on sbawe (yes, just for fun :)
it has no DMA and no hardware interrupts.

the DMA'ish copy is done in copy/silence callbacks.  they are called
from the read/write syscalls only if defined.  interestingly, in the
emu8000 pcm routine, there is even no buffer because it transfers the
data from user space to its hardware directly by loop.

the update of period is established by checking the current pointer in
the system timer interrupts.  this is odd, of course.  the least
period size is limited by the timer interrupt frequency.
but it works.

the problem arises when the transfer rate is really slow or equal with
the playback rate.  in such a case, it's fairly difficult to get the
accurate schedule timing.  i don't think this is his case, though.


Takashi

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

prepare(substream)

[Guilhem Tardy]

I believe that I have misunderstood the meaning of this function, could anyone
explain?

In a test of a driver, I see this sequence for playback:
pointer()
copy()
prepare()
copy()
pointer()
copy()
pointer()
pointer()
...

Thanks,
Guilhem.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

----------------------------------------------------------------------------
                   Bringing you mounds of caffeinated joy
                   >>>     http://thinkgeek.com/sf    <<<

Re: prepare(substream)

[Paul Davis]

>I believe that I have misunderstood the meaning of this function, could anyone
>explain?

prepare is used to get the hardware ready to be started. 

>In a test of a driver, I see this sequence for playback:

>pointer()   << gets current h/w pointer location
>copy()      << moves silence or initial data into h/w buffer
>prepare()   << get h/w ready for starting
>copy()      << copy more data
>pointer()   << get current h/w pointer location
>copy()      << etc. etc.
>pointer()
>pointer()


-------------------------------------------------------
                   Bringing you mounds of caffeinated joy
                   >>>     http://thinkgeek.com/sf    <<<

Re: prepare(substream)

[Takashi Iwai]

At Wed, 19 Jun 2002 11:49:14 -0700 (PDT),
Guilhem Tardy wrote:
> 
> I believe that I have misunderstood the meaning of this function, could anyone
> explain?
> 
> In a test of a driver, I see this sequence for playback:
> pointer()
> copy()
> prepare()
> copy()
> pointer()
> copy()
> pointer()
> pointer()
> ...


usually prepare() callback is called at the first before copy() etc.
but please note that prepare() may be called multiple times.
for example, on oss emulation, each time when the condition like
sample format, rates is changed, prepare() is called to set the latest
status.


Takashi


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/