Hauppauge PVR-250 / 350 Driver

[Andrew Gordon]

On Wed, 3 Dec 2003, John-Mark Gurney wrote:
>
> >
> > This isn't really the case for the PVR-250 / 350.  The MPEG program
> > stream from the card contains both sound and video.
>
> Yeh, And I did say most.. :)  I was thinking that if the card does
> something special with sound, like integrate it into a codec stream,
> then the sound capture could/should? be set as a parameter of that
> device that does the integration...  Because I assume that the card
> can only captuer sound as part of the mpeg codec stream? (going to
> check the specs).
>
> Do people think that sound should be brought under it's umbrela?
> I don't want to delay it too much by expanding the scope..  Just getting
> video is going to be difficult enough..

Well, some means of supporting sound alongside video is certainly
required: if the API doesn't handle sound explicitly, then it needs to
convey the necessary timing information so that the sound can be handled
via separate APIs without losing synchronisation.

For many kinds of device, all you need is to report the delay through the
device (and it's associated driver buffering).  However, some kinds of
device don't have constant delay and timestamps are required.  Devices
such as the MPEG capture card mentioned earlier are a problem to fit into
such a scheme, as although the video will come out nicely timestamped (and
the audio likewise), there may not be a means to relate those timestamps
to real-time (ie. you can achieve A/V-sync between A and V streams
captured on the card as designed, but it's hard to synchronize with sound
captured on a standard sound-card at the same time, for example).