From: Hans Verkuil <hverkuil@xs4all.nl>
To: Divneil Wadhawan <divneil@outlook.com>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: No audio support in struct v4l2_subdev_format
Date: Fri, 04 Jul 2014 11:54:10 +0200 [thread overview]
Message-ID: <53B679C2.7030002@xs4all.nl> (raw)
In-Reply-To: <BAY176-W23C9AA5FB70F17EDEB68F8A9000@phx.gbl>
Hi Divneil,
On 07/04/2014 11:30 AM, Divneil Wadhawan wrote:
> Hi Hans,
>
>
>> To my knowledge nobody has done much if any work on this. Usually
>> the audio part is handled by alsa, but it is not clear if support
>> is also needed from the V4L2 API.
>
> Actually, the application needs to know when to ask the capture
> device to start capturing.
>
> Let's say, the cable is already plugged in/or plugged out.
>
> So, any events will be missed as the driver state machine starts
> during boot up and app is not started.
>
> App starts later, registers for (V4L2_EVENT_SOURCE_CHANGE back
> ported to 3.10) and listens, but will not receive any as they are
> already generated.
I don't understand the problem. When the application starts the first thing it should
do is to call VIDIOC_QUERY_DV_TIMINGS: that will tell it if any signal is present.
An alternative might be to extend v4l2_src_change_event_subscribe() and have it honor
the V4L2_EVENT_SUB_FL_SEND_INITIAL flag: if set, it should issue this event at once.
That might actually be a nice improvement.
>
>
> So, the application is in a blind spot whether to start capture or
> not.
But what has that to do with audio?
> If we get the same interface as video it's good. I mean G_FMT with a
> union for audio as well.
>
> Otherwise, I can go with a proprietary control/ioctl indicating
> whether audio is valid or not.
>
> ioctl seems to be an easy choice, because this subdev is not
> exposing any controls, so, registration with ctrl framework for a
> single one seems a bit of overload.
It's perfectly fine to have a single control. Nothing wrong with that.
Still not sure what you actually need in V4L2 w.r.t. the audio information.
Regards,
Hans
next prev parent reply other threads:[~2014-07-04 9:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-04 6:49 No audio support in struct v4l2_subdev_format Divneil Wadhawan
2014-07-04 7:54 ` Hans Verkuil
2014-07-04 9:30 ` Divneil Wadhawan
2014-07-04 9:54 ` Hans Verkuil [this message]
2014-07-04 10:24 ` Divneil Wadhawan
2014-07-04 10:38 ` Hans Verkuil
2014-07-04 11:38 ` Divneil Wadhawan
2014-07-05 8:41 ` Hans Verkuil
2014-07-07 4:59 ` Divneil Wadhawan
2014-07-09 10:55 ` Divneil Wadhawan
2014-07-09 11:26 ` Hans Verkuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B679C2.7030002@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=divneil@outlook.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.