[vdr] Re: VDR plugins - RFC - audio handling

[Karlheinz.Pischke@t-online.de (Karlheinz Pischke)]

Hi Klaus,

why do you insist on having "normal" and "special" audio handling ?

Wouldn't it be a better approach (from design point of view) to use just 
- cVideoDevice
- cAudioDevice
and do the exception handling (like Mono, Stereo, DD, AC3, DTS or
whatever) 
afterwards ?
This would make the design and API cleaner and better structured,
wouldn't it ?

You have already implemented (up to 1.0.x) the "normal" audio handling.
In
your new design you also have to only implement the "normal" audio
handling
as a kind of reference design for the audio handling class/plugin.


 
Klaus Schmidinger wrote:
> 
> Andreas Schultz wrote:
> >
> > ...
> > > Also, any buffering and/or threading will be handled completely by the
> > > cMyPlayer class, so every player can use the buffering method it prefers.
> > > There will also be an abstract cDvbDevice class, to which a player will be
> > > attached for replaying. cDvbDevice will assume that the cPlayer delivers
> > > a data stream that it shall replay. This data stream will go directly into
> > > the DVB driver, without additional buffering in VDR.
> >
> > Assuming that the output device will allways have a DVB type API is IMHO a
> > severe limitation.
> 
> That name was not well chosen, I guess. I'm now assuming a "cDevice", which can
> be a DVB device, or some other thing, maybe even a software MPEG decoder.
> 
> > > Now for the original subject of this thread: it will be totally up to the
> > > cMyPlayer class what to do with any additional audio data. In the simplest
> > > case this will be the "normal" audio data that is part of the DVB data
> > > stream sent to the cDvbDevice. If there is Dolby Digital data available,
> >
> > Again, what is "normal" for the output device? The NEWSTRUCT branch of the DVB
> > driver allready includes a driver for dxr3 cards which also support DD
> > digital out. The definition of "normal" becomes more and more blurry, and i
> > believe the output model has to deal with that.
> 
> With "normal" I mean the audio that comes, e.g., from channels like RTL etc.
> Nothing special, just the usual audio (that can be played directly by the DVB
> cards). Anything else (like DD, AC3 or whatever) would be "special".
> 
> > > cMyPlayer can send that data to, e.g., a cAudioDolbyDigital device, which
> > > will be an abstract interface to an actual implementation done via a
> > > plugin. So on a system that doesn't use a DD plugin, nothing will happen.
> > > On a system that has a DD plugin loaded, the DD audio will be presented by
> > > the way actually implemented in that plugin. I assume that it should be
> > > sufficient to have *one* such interface for each kind of digital audio (DD,
> > > DTS, PCM, MPEG), since every VDR user will probably have one specific way
> > > of replaying a given type of audio. By loading the proper plugin he/she can
> > > define what to do with that particular type of audio data. The cMyPlayer
> > > will be able to query whether a given type of audio data can be handled by
> > > the current system (i.e. whether there is a plugin loaded for that type of
> > > data).
> >
> > I would prefer *NOT* to divide the DVB output from any additional audio
> > output. Video and audio output are tightly coupled and so should the output
> > classes for them.
> 
> Ok, fine with me.
> 
> Would it then be ok to give the cDevice a Play() function through which it
> can receive "normal" video and audio data, and additionally a PlayAudio()
> function through which it can receive any kind of (additional) audio data?
> It would, however, still be up to the cMyPlayer to determine which audio
> data (e.g. which language channel) to actually send to the cDevice.
> 
> PlayAudio() would then send the data to every registered audio plugin, and
> it will be up to the individual plugin to decide whether it can handle the
> data or not. PlayAudio() itself will not interpret the data in any way.
> 
> Well, re-reading your posting I guess that's pretty much what you suggested... ;-)
> 
> Klaus
> --
> _______________________________________________________________
> 
> Klaus Schmidinger                       Phone: +49-8635-6989-10
> CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
> Hofmark 2                               Email:   kls@cadsoft.de
> D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
> _______________________________________________________________

-- 



Gruß

Karlheinz