[alsa-devel] Hardware audio decoder driver design
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.
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
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
participants (3)
-
Clemens Ladisch -
Koul, Vinod -
Nikita V. Youshchenko