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

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Andreas Schultz wrote:
> 
> On Wednesday 22 May 2002 22:35, Klaus Schmidinger wrote:
> > Karlheinz Pischke wrote:
> > > 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.
> >
> > The thing is that a "normal" recording simply consists of a video and
> 
> What is normal?

I believe I've stated that several times: when I speak about "normal"
audio I mean the kind of audio that, for instance, is broadcast by channels
like RTL. I don't know if there is a specific technical term for this kind
of audio (as opposed to, for instance, the Dolby Digital audio from Pro7, which
is broadcast in *addition* to the "normal" audio).

> I wouldn't buy a DVD player without DD/DTS, and times will
> come where this will be true for DVB receivers as well.
> 
> > an audio data stream. That's pretty much 99% of what VDR handles, so I'd
> > like to keep that simple. As it is right now, the video and audio data is
> > in one multiplexed stream and can be sent to the driver as such, no need
> > to take it apart.
> 
> But the DVB card has not to be the primary audio out device. In fact the
> video/autio out device has not to be a DVB card at all. The current design is
> so centered arround that single piece of hardware that it is really hard to
> integrate other devices.
> The point is, that there are a lot of possible situations where i would have
> to take appart even your "normal" streams, tweak them or even generaten them
> in the first place.
> Suppose, i want to send the "normal" audio stream not to the DVB card, but to
> some other audio out device, (e.g. to a 6 channel sound card or a SPDIF
> card). Or suppose, i want to send the alternate language stream to
> headphones, while replaying the main language though the TV.
> 
> VDR started as a video recorder for DVB cards, but that doesn't mean that it
> has to stay that way. IMHO a versatile digital video recorder needs more that
> just recording and replaying of MPEG2 streams. Like it or not, VDR has become
> the core of a lot of additional modules which could benefit from a more
> unified audio stream handling.
> 
> I guess, my dream is to have vdr be a very flexible framework to combine all
> kinds of A/V and MPEG hardware into the ultimate multimedia "eierlegende
> Wollmilchsau". Do i want too much?

Ok, I'll then make it so that the cDevice (an abstract "thing" that can replay
video and audio data, but by itself doesn't know how - the actual action will
be implemented by classes derived from cDevice, one of them being cDvbDevice)
will have a PlayVideo() and a PlayAudio() function. A player shall feed video
data into the PlayVideo() function, and (any kind of!) audio data into the
PlayAudio() function. PlayAudio() will simply distribute the audio data to
any registered audio device (which can be implemented via plugins).

The question is: If _all_ audio data is presented to every audio device, will
the various devices be able to filter out exactly the kind of data they can
handle? If not, then we would need several PlayAudio() functions (or a PlayAudio()
with a controlling parameter) for the various types if audio data, and the player
would have to decide where to send each chunk of audio data. Personally I'd
prefer the first method.

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
_______________________________________________________________