[linux-dvb] Linux DVB API V4 / Audio API

[Johannes Stezenbach <js@convergence.de>]

Hi all,

I've collected some requirements for the V4 audio DVB API.
In V3 we currently have:

    demux ---> decoder ---> output/mixer
    
    ^^^^^^^^^^^^^^^^^^      ^^^^^^^^^^^^
     covered by DVB API     some other API (e.g OSS)

The V3 audio decoder API also had some ad hoc extensions to support
DVD playback for the EM8300 and Margi drivers.


In V4 we want better support for audio post-processing, mixing
and output control. Since I think that existing Linux audio APIs
like OSS and ALSA don't fit well for embedded DVB applications,
I propose to include the following in the Linux DVB API:


  demux ---> decoder --> post-proc -> |-------|
         |           |                |       |
	 |           |--------------> |       |  |-> TV out
	 |                            |       |  |
	 |-> decoder --> post-proc -> | mixer |--|-> VCR out
                                      |       |  |
  ext -----> decoder --> post-proc -> |       |  |-> head phones
                                      |       |
  pcm -----------------> post-proc -> |-------|


        ^............^.............^...........^   S/P-DIF out


We have the following devices:

o audio decoder
  - decodes audio PES or ES in various formats
    (MPEG-1, MPEG-2, mp3, AC3, ...)
  - performs synchronization to the STC (lip-sync)
  - input can be from demux, from external input (I2S or SPDIF)
    or memory
o audio post processor
  - performs 5.1 to stereo downmix
  - performs 2ch to 5.1 Dolby Prologic decoding
  - stereo to 3D stereo (SRS, virtual Dolby)
  - dynamic compression
  - ...
o mixer and output control
  - possible input signals are all decoder outputs, all
    post-proc outputs and external PCM inputs
  - generates different mixes for each output, including
    volume and balance control
  - may include bass/treble control, equalizer or similar
  - may include a test tone generator ("beep")
o S/P-DIF output
  - this is a separate device so it can be connected at
    various points in the signal path
  - S/P-DIF output may be synched to the STC (lip-sync)


A possible simplification which would not sacrifice functionality
for current hardware would be to integrate decoder and post-processor
into one device. That means it won't be possible to have more than one
post-processor per decoder.

A post-proc can support a number of different modes, and in each
mode there will be a distinct set of parameters. If a decoder
does not use a post-proc the mode will simply be set to "none".
Similarly, to feed PCM to a post-processor (or directly to
the mixer) one would set the decoder to "pass though". This can
also be used for PCM playback from memory.

If the hardware has more decoders than post-processors they are
assigned dynamically, and the attempt to enable a post-processor
for a decoder may return EBUSY.

Output from the decoder may be mono, stereo oder 5.1ch, and
one can only select a matching post-processor mode.

The outputs from the decoders and post-processors are fed
into the mixer (so the mixer can e.g. output 5.1 on main
and a stereo downmix on headphones).

The S/P-DIF output device can be connected at various points
in the signal path to output an undecoded stream or a PCM audio
stream. If the output signal is PES from the demux it
can be synced to the STC.

Sample rate conversion is handled implicitely by the driver.
The API only allows to specify input sample rates and output
sample rates. If a rate conversion along the signal path is
not supported by the hardware, an error code will be returned.

The ioctls for the decoder + post-prcessor, mixer and spdif
output device are defined in audio.h.


I'm currently not sure how to proceed. The basic device
structure might work for a variety of DVB audio systems,
but the differences between audio HW are so large that
it is difficult to have a generic API to manage all possible
paramters.
Also, the mixer could get awfully complicated because
actual HW has many restrictions on internal signal routing.

o we could try to define paramter sets for common functionality
  (e.g. 5.1 to stereo downmix or Dolby Prologic are common
  post-processors and would have common paramter sets), and leave
  everything else for private extensions;
  I'm inclined to go that way.
o or we try to have a generic inferface with lots of capabilities etc.
  (sounds nice, but how?)


Please comment.

Regards,
Johannes


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