Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: James Courtier-Dutton <James@superbug.co.uk>
To: Adrian McMenamin <adrian@mcmen.demon.co.uk>
Cc: alsa-devel@alsa-project.org
Subject: Re: Advice on writing driver
Date: Sun, 26 Feb 2006 02:40:07 +0000	[thread overview]
Message-ID: <44011507.7000808@superbug.co.uk> (raw)
In-Reply-To: <1140911587.9838.19.camel@localhost.localdomain>

Adrian McMenamin wrote:
> I have asked some the questions below in piecemeal form before and only
> occasionally got an answer, so i'll go through it all now and see if you
> can help.
>
> I am writing a driver for the Sega Dreamcast. Years ago I wrote an OSS
> driver but the sound dma had not been reversed then so it was slower and
> tended to lock the system.
>
> On the Dreamcast (DC) sound the main CPU is an SH4 but there is a
> separate low powered ARM7 to handle sound (PCM). The ARM7 has its own
> memory space which is directly accessible to the SH4 only through a FIFO
> like gateway (so slow) unless DMA is used.
>
> The ARM7 also has to have its own program to be told how to play the
> sound (this looks like firmware to the SH4).
>
> The driver currently allocates a buffer in the main SH4 memory (using
> the DMA buffer allocation APIs). This is then transferred to the ARM7
> space using DMA.
>
> The ARM7 code raises an interrupt to the SH4 whenever it plays 4096
> bytes of the sound - ie every period.
>
> What should my pointer callback return? the number of bytes/frames still
> to be transferred from the DMA buffer to the ARM memory or the number of
> bytes/frames still to play, or what?
>
> Adrian
>
>   
The pointer callback should return the current playback position in the 
sound  ring buffer.
So, NOT the following:

a) the number of bytes/frames still to be transferred from the DMA buffer to the ARM memory
b) the number of bytes/frames still to play

but instead it should return the position in the ring buffer of the 
frame currently being played by the ADC.


James



-------------------------------------------------------
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

      reply	other threads:[~2006-02-26  2:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-25 23:53 Advice on writing driver Adrian McMenamin
2006-02-26  2:40 ` James Courtier-Dutton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44011507.7000808@superbug.co.uk \
    --to=james@superbug.co.uk \
    --cc=adrian@mcmen.demon.co.uk \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox