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