* New Audio Driver Design
@ 2009-07-14 4:52 jassi brar
2009-07-15 20:22 ` Daniel Mack
0 siblings, 1 reply; 3+ messages in thread
From: jassi brar @ 2009-07-14 4:52 UTC (permalink / raw)
To: alsa-devel
Hello,
I am to write an ALSA driver for my SOC which has a dedicated DSP
subsystem which can
be loaded with decoder instructions and parameteres, and then we load it
with encoded data. The dsp then decodes the data and sends it to the PCM
controller.
Could someone please refer me to some similar driver/codec which already
does that?
If not, how should i design the driver?
:- Should I load the encoder inst/params using firmware API? Then, which
API should I use to submit encoded data to the DSP?
Any pointers please?
Thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: New Audio Driver Design
2009-07-14 4:52 New Audio Driver Design jassi brar
@ 2009-07-15 20:22 ` Daniel Mack
[not found] ` <1b68c6790907151713y21148275t1768dbb5c6761c43@mail.gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Mack @ 2009-07-15 20:22 UTC (permalink / raw)
To: jassi brar; +Cc: alsa-devel
On Tue, Jul 14, 2009 at 01:52:12PM +0900, jassi brar wrote:
> I am to write an ALSA driver for my SOC which has a dedicated DSP
> subsystem which can
> be loaded with decoder instructions and parameteres, and then we load it
> with encoded data. The dsp then decodes the data and sends it to the PCM
> controller.
Are these decoder instruction something you need to do at runtime? Or
would it suffice to provide them once when the driver is probed?
For the first case, you could use the ALSA control interface, in
particular the SNDRV_CTL_ELEM_BYTES type.
For the latter, you might want to have a look at the firmware framework
and read Documentation/firmware_class/README.
Hope that helps,
Daniel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: New Audio Driver Design
[not found] ` <1b68c6790907151713y21148275t1768dbb5c6761c43@mail.gmail.com>
@ 2009-07-20 6:56 ` Daniel Mack
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Mack @ 2009-07-20 6:56 UTC (permalink / raw)
To: jassi brar; +Cc: alsa-devel
On Thu, Jul 16, 2009 at 09:13:28AM +0900, jassi brar wrote:
> On Thu, Jul 16, 2009 at 5:22 AM, Daniel Mack <daniel@caiaq.de> wrote:
> > Are these decoder instruction something you need to do at runtime? Or
> > would it suffice to provide them once when the driver is probed?
>
> The decoder insn, params atleast, depend upon the mp3 file i want the dsp to
> decode and play.
> So, let us assume, i have to load decoder insns and params into the dsp for
> every mp3 file playback.
Then the alsa control API seems appropriate. Unless there is any other
interface for that specific purpose I'm not aware of.
> Also, by what interface name(like I2S/PCM/AC97) shud my driver get encoded
> mp3 data from my mp3-player and then decode that mp3 data by dsp and play
> the output pcm stream?
> I am afraid i must bypass/hack ALSA stack to directly get mp3 data from
> user-space. Am i right?
Have a look at include/sound/pcm.h - there are more formats defined than
just linear PCM, and I think SNDRV_PCM_FMTBIT_MPEG could be something
you can use. But I'm not sure and never used something like that before,
so maybe anyone else can elaborate more?
Daniel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-07-20 6:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-14 4:52 New Audio Driver Design jassi brar
2009-07-15 20:22 ` Daniel Mack
[not found] ` <1b68c6790907151713y21148275t1768dbb5c6761c43@mail.gmail.com>
2009-07-20 6:56 ` Daniel Mack
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.