[vdr] VDR plugins - RFC - audio handling

[Andreas Schultz <aschultz@cs.uni-magdeburg.de>]

Hi Klaus, hi all

I have a wish. For the new version, i would like to be able to support 
multiple audio out devices for all players (VDR, DVD, VCD, ...).

Currently we support the primary DVB card and one additional external device 
via the '-a' parameter. 
This sheme nad the current implementation of it has some limitations:
 - only 2 audio output channels (might be enough, but it is a limitation 
   nevertheless)
 - for AC3 playback over soundcard, audio decoding has to be done in the    
   output thread, possibly introducing A/V sync problems
 - no control over audio buffer (an thereby audio delay) in external AC3 tools
 - control information available on the input side can not be passed to the
   external tool, again resulting in audio sync problems
 - audio output currently (StipAudioPackets) is to comlicated and unflexible

Some of those limitations have already been addressed in some way or the other 
in the current patches. But IMHO a more generic and general solution is 
needed.

Goals for a new scheme should be:
 - be able to use the same audio output processing methods for all players
 - have the output side only perform the necessary hardware setup, A/V 
   syncing and audio packet routing
 - have all major processing being done on the input side, this also applies 
   to audio channel selection when multiple audio tracks are available
 - be able to pass control messages from the imput to the output thread 
   directly

For that to work, the most important change for vdr will be to mark every 
audio packet on the input side with a destination device id and packet type 
(DD, DTS, PCM, MPEG), with 0 (zero) being the DVB card and any id > 0 being 
an additional device handled by some kind of audio plugin.
This will have the biggest impact on the transfer mode as it mostly handles 
data as a transparent data stream.

I see two possible ways to attach such a device id to audio packets. We could  
always use the frame buffers and make the device id part of the frame 
attributes.Or, we always remux all PRIVATE_STREAM2 packets, so that the first 
bytes of the payload can contain the additional information - much like on 
DVD. Some PES packet analyzing would still be needed on the output side (and 
i'm not sure wether i like that or not). 

Any comments?

Andreas

-- 
Andreas Schultz <aschultz@cs.uni-magdeburg.de>
Student of computer science

"In accordance with plans for Linux OS world domination
      infiltration of governments is vital (:-))."