Re: Hardware audio decoder driver design

[Clemens Ladisch <clemens@ladisch.de>]

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