All of lore.kernel.org
 help / color / mirror / Atom feed
* Hardware audio decoder driver design
@ 2011-07-28 15:10 Nikita V. Youshchenko
  2011-07-28 15:56 ` Koul, Vinod
  2011-07-28 16:05 ` Clemens Ladisch
  0 siblings, 2 replies; 3+ messages in thread
From: Nikita V. Youshchenko @ 2011-07-28 15:10 UTC (permalink / raw)
  To: alsa-devel

Hello.

Soon I will work on a linux kernel driver for a custom audio decoder device 
that is being developed by a company I work for. If not going into 
details, that devices reads A52-encoded stream from system memory, and 
writes raw pcm stream to system memory.

Simplest thing to do is - implement a character device, where user-space 
will write encoded stream, and from where user-space will read decoded 
stream.
(driver for similar hardware, located at 
http://sourceforge.net/projects/vs10xx/, does that).

However, perhaps a better architecture (e.g. in-kernel intergation with an 
audio sink) is possible?

I'm looking for any related information - e.g. ideas on what interface to 
implement, examples of drivers for similar devices, etc.

Thanks on any hints.

Nikita Youshchenko,
embedded linux developer.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Hardware audio decoder driver design
  2011-07-28 15:10 Hardware audio decoder driver design Nikita V. Youshchenko
@ 2011-07-28 15:56 ` Koul, Vinod
  2011-07-28 16:05 ` Clemens Ladisch
  1 sibling, 0 replies; 3+ messages in thread
From: Koul, Vinod @ 2011-07-28 15:56 UTC (permalink / raw)
  To: Nikita V. Youshchenko, alsa-devel@alsa-project.org


Nikita V. Youshchenko wrote: 
> Hello.
> 
> Soon I will work on a linux kernel driver for a custom audio decoder device
> that is being developed by a company I work for. If not going into
> details, that devices reads A52-encoded stream from system memory, and
> writes raw pcm stream to system memory.
> 
> Simplest thing to do is - implement a character device, where user-space
> will write encoded stream, and from where user-space will read decoded
> stream.
> (driver for similar hardware, located at
> http://sourceforge.net/projects/vs10xx/, does that).
> 
> However, perhaps a better architecture (e.g. in-kernel intergation with an
> audio sink) is possible?
> 
> I'm looking for any related information - e.g. ideas on what interface to
> implement, examples of drivers for similar devices, etc.
We have implemented a similar scheme for our devices, please see 
staging/intel_sst/. We are currently adding alsa API for compressed path 
streaming which will also involve API for decoding compressed data and sending 
back to system memory

HTH
~Vinod

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Hardware audio decoder driver design
  2011-07-28 15:10 Hardware audio decoder driver design Nikita V. Youshchenko
  2011-07-28 15:56 ` Koul, Vinod
@ 2011-07-28 16:05 ` Clemens Ladisch
  1 sibling, 0 replies; 3+ messages in thread
From: Clemens Ladisch @ 2011-07-28 16:05 UTC (permalink / raw)
  To: Nikita V. Youshchenko; +Cc: alsa-devel

Nikita V. Youshchenko wrote:
> > Nikita V. Youshchenko wrote:
> > > If not going into details, that devices reads A52-encoded stream
> > > from system memory, and writes raw pcm stream to system memory.
> > >
> > > Simplest thing to do is - implement a character device, where
> > > user-space will write encoded stream, and from where user-space will
> > > read decoded stream.
> > >
> > > However, perhaps a better architecture (e.g. in-kernel intergation
> > > with an audio sink) is possible?
> >
> > One of the implicit assumptions of ALSA sound devices is that they run
> > in real time, and at a constant bit rate.  As far as I can tell, your
> > device would be 'just' a DSP, so a character device would be
> > appropriate.
> 
> But there is such thing as 'ac3 passthrough' - to make use of hardware ac3
> decoders on sound cards that have this feature.

It's more intended to be used to transport AC-3 data over a S/PDIF cable
where the decoder is _not_ in the computer itself.

> I was thinking that something similar could be done for 'our device +
> standard alsa driver' combination - to make use of existing software using
> that interface.

This would be possible, but it would result in a userspace ALSA plugin
that still has to access your device with some private API.

Building a kernel driver with virtual playback/capture devices would
be harder because there isn't an official API to access other sound
devices in kernel space.  (However, the OSS emulation has some sample
format conversion plugins that do something like this.)


Regards,
Clemens

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-07-28 16:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-28 15:10 Hardware audio decoder driver design Nikita V. Youshchenko
2011-07-28 15:56 ` Koul, Vinod
2011-07-28 16:05 ` Clemens Ladisch

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.