From owner-freebsd-multimedia@FreeBSD.ORG Wed Dec 3 16:37:14 2003 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0115216A4CE for ; Wed, 3 Dec 2003 16:37:14 -0800 (PST) Received: from arg1.demon.co.uk (arg1.demon.co.uk [62.49.12.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B18D43FE3 for ; Wed, 3 Dec 2003 16:37:12 -0800 (PST) (envelope-from arg-bsd@arg.me.uk) Received: by arg1.demon.co.uk (Postfix, from userid 1002) id 363839B32; Thu, 4 Dec 2003 00:37:11 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by arg1.demon.co.uk (Postfix) with ESMTP id 277C65D6A; Thu, 4 Dec 2003 00:37:11 +0000 (GMT) Date: Thu, 4 Dec 2003 00:37:10 +0000 (GMT) From: Andrew Gordon X-X-Sender: freebsd@server.arg.sj.co.uk To: John-Mark Gurney In-Reply-To: <20031203175701.GA54398@funkthat.com> Message-ID: <20031204002502.X49643@server.arg.sj.co.uk> References: <200312030524.hB35OpJ28562@jwlab.FEITH.COM> <20031203175701.GA54398@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: multimedia@freebsd.org Subject: Re: Hauppauge PVR-250 / 350 Driver X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2003 00:37:14 -0000 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).