[linux-dvb] Re: LinuxDVB V4 API questions II

[Michael Hunold <hunold@convergence.de>]

Hello,

On 04/06/04 12:39, Alasdair FARMER wrote:
> 1) The DEMUX -> DECODER linkage : what mechanisms are
> supported/promoted for transferring data between these
> components.  The API needs to bear in mind that these
> can and often will be separate unconnected pieces of
> hardware/software.  To this end I am assuming that there
> will be support for both a read/write API and some form
> of buffer mapping ?
Just to make this clear: It's assumed that data is transferred 
automatically between the demux and the decoder on *one* device, ie. 
there is no support for connecting a demux from card xx to the decoder 
of card yy.

The actual implementation hasn't been specified, but the simple 
read()/write() (with an integrated software ringbuffer) approach will be 
there for sure.

For more sophisticated hardware, a direct mapping of a "hardware buffer" 
(ie. a buffer from which the hardware can dma) will be available, too..

Currently this is already implemented for the recording filters and the 
av7110 driver, where you can mmap() the hardware ringbuffer (which is 
simulated in software here because the av7110 doesn't have any 
specialized hardware) and you can request/confirm the data in the buffer 
just mapped (ie. you have zero-copy transfer from user-space buffers via 
dma to your hardware)

> 2) Audio implementation.  I am curious why you have decided to implement
>an Audio API rather than adopt the decoder / renderer separation that 
exists
>for video.

Hm, do you really think that the current approach is really a 
full-featured audio API?

> As there are a number of well defined API's to support 
>video/graphics rendering it makes sense to decouple the presentation 
of the
>data from the LinuxDVB API and leave it up to the decoder.  So, following
> that line of reasoning, why was the same approach not taken with audio ? 
>There are a number of well defined Audio presentation/rendering API's 
available
>- for example the ALSA API.  It would seem to make more sense - less work
> and for a more coherent and holistically consistent solution to leave the
> presentation of the audio to the audio API's...

IMHO the audio part was designed to only provide access to the audio 
features that are special to an MPEG audio decoder without having to 
hassle with other sound subsystems.

For a full-featured STB you'll need to implement ALSA or OSS access 
anyway, the audio API is no replacement for that. In that case you can 
simply start/stop the decoder via DVB, but need to access everything 
else via ALSA.

But for a simple STB you have the choice to control everything via the 
DVB audio api without the need to use ALSA, which is less complicated if 
you focus on the mpeg audio decoder aspects only.

> Regards
> Ali Farmer
But as always: this is my personal opinion and I'm always open for 
discussions. 8-)

CU
Michael.


--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.