All of lore.kernel.org
 help / color / mirror / Atom feed
* UVC and V4L2_CAP_AUDIO
@ 2013-07-25  9:03 Hans Verkuil
  2013-07-25  9:10 ` Laurent Pinchart
  0 siblings, 1 reply; 4+ messages in thread
From: Hans Verkuil @ 2013-07-25  9:03 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Bård Eirik Winther, linux-media

Hi Laurent,

While working on adding alsa streaming support to qv4l2 we noticed that uvc
doesn't set this capability telling userspace that the webcam supports audio.

Is it possible at all in the uvc driver to determine whether or not a uvc
webcam has a microphone?

If not, then it looks like the only way to find the associated alsa device
is to use libmedia_dev (or its replacement, although I wonder if anyone is
still working on that).

And in particular, the presence of CAP_AUDIO cannot be used to determine
whether the device has audio capabilities, it can only be used to determine
if the V4L2 audio ioctls are supported. That would have to be clarified in
the spec.

Regards,

	Hans

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UVC and V4L2_CAP_AUDIO
  2013-07-25  9:03 UVC and V4L2_CAP_AUDIO Hans Verkuil
@ 2013-07-25  9:10 ` Laurent Pinchart
  2013-07-25 13:11   ` Devin Heitmueller
  0 siblings, 1 reply; 4+ messages in thread
From: Laurent Pinchart @ 2013-07-25  9:10 UTC (permalink / raw)
  To: Hans Verkuil; +Cc: Bård Eirik Winther, linux-media

Hi Hans,

On Thursday 25 July 2013 11:03:13 Hans Verkuil wrote:
> Hi Laurent,
> 
> While working on adding alsa streaming support to qv4l2 we noticed that uvc
> doesn't set this capability telling userspace that the webcam supports
> audio.
> 
> Is it possible at all in the uvc driver to determine whether or not a uvc
> webcam has a microphone?

Not without dirty hacks. The UVC interfaces don't report whether the device 
has an audio function, the driver would need to look at all the interfaces of 
the parent USB device and find out whether they match one of the USB audio 
drivers. That's not something I would be inclined to merge in the uvcvideo 
driver.

> If not, then it looks like the only way to find the associated alsa device
> is to use libmedia_dev (or its replacement, although I wonder if anyone is
> still working on that).

I need to post the code I have. I'll try to do that next week.

> And in particular, the presence of CAP_AUDIO cannot be used to determine
> whether the device has audio capabilities, it can only be used to determine
> if the V4L2 audio ioctls are supported. That would have to be clarified in
> the spec.

The V4L2 audio ioctls are definitely not supported by the uvcvideo driver :-)

-- 
Regards,

Laurent Pinchart


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UVC and V4L2_CAP_AUDIO
  2013-07-25  9:10 ` Laurent Pinchart
@ 2013-07-25 13:11   ` Devin Heitmueller
  2013-07-25 13:19     ` Laurent Pinchart
  0 siblings, 1 reply; 4+ messages in thread
From: Devin Heitmueller @ 2013-07-25 13:11 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Hans Verkuil, Bård Eirik Winther, linux-media

On Thu, Jul 25, 2013 at 5:10 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Not without dirty hacks. The UVC interfaces don't report whether the device
> has an audio function, the driver would need to look at all the interfaces of
> the parent USB device and find out whether they match one of the USB audio
> drivers. That's not something I would be inclined to merge in the uvcvideo
> driver.

We need this functionality anyway for other snd-usb-audio based tuners
like em28xx and au0828, so I think some sort of solution is
unavoidable.  I hacked something together for em28xx a few years ago
to do such an enumeration, but in reality we should probably have an
export in snd-usb-audio which would help figuring this out in a less
hacky way.

>> If not, then it looks like the only way to find the associated alsa device
>> is to use libmedia_dev (or its replacement, although I wonder if anyone is
>> still working on that).

Yup, it's 2013 and we still don't have a way for applications to ask
the kernel which ALSA device is tied to a given /dev/video node.
Hans, remember when I proposed adding a trivial ioctl() call back in
2009 that would allow this, and you rejected it saying the media
controller API was the answer?  It's hard not to feel like salt in the
wound that it's four years later and there *still* isn't a solution.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UVC and V4L2_CAP_AUDIO
  2013-07-25 13:11   ` Devin Heitmueller
@ 2013-07-25 13:19     ` Laurent Pinchart
  0 siblings, 0 replies; 4+ messages in thread
From: Laurent Pinchart @ 2013-07-25 13:19 UTC (permalink / raw)
  To: Devin Heitmueller; +Cc: Hans Verkuil, Bård Eirik Winther, linux-media

Hi Devin,

On Thursday 25 July 2013 09:11:31 Devin Heitmueller wrote:
> On Thu, Jul 25, 2013 at 5:10 AM, Laurent Pinchart wrote:
> > Not without dirty hacks. The UVC interfaces don't report whether the
> > device has an audio function, the driver would need to look at all the
> > interfaces of the parent USB device and find out whether they match one of
> > the USB audio drivers. That's not something I would be inclined to merge
> > in the uvcvideo driver.
> 
> We need this functionality anyway for other snd-usb-audio based tuners
> like em28xx and au0828, so I think some sort of solution is
> unavoidable.  I hacked something together for em28xx a few years ago
> to do such an enumeration, but in reality we should probably have an
> export in snd-usb-audio which would help figuring this out in a less
> hacky way.
> 
> >> If not, then it looks like the only way to find the associated alsa
> >> device is to use libmedia_dev (or its replacement, although I wonder if
> >> anyone is still working on that).
> 
> Yup, it's 2013 and we still don't have a way for applications to ask the
> kernel which ALSA device is tied to a given /dev/video node. Hans, remember
> when I proposed adding a trivial ioctl() call back in 2009 that would allow
> this, and you rejected it saying the media controller API was the answer? 
> It's hard not to feel like salt in the wound that it's four years later and
> there *still* isn't a solution.

It's partly my fault for not having found time to work on this.

http://git.ideasonboard.org/media-ctl.git/shortlog/refs/heads/enum
http://git.ideasonboard.org/media-enum.git

Not completely there yet, but this already allows enumerating media devices 
(audio and video) in the system. A bit of code cleanup is still needed in the 
media-ctl enum branch. I'll try to find time for that next week and finally 
submit patches.

-- 
Regards,

Laurent Pinchart


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-07-25 13:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-25  9:03 UVC and V4L2_CAP_AUDIO Hans Verkuil
2013-07-25  9:10 ` Laurent Pinchart
2013-07-25 13:11   ` Devin Heitmueller
2013-07-25 13:19     ` Laurent Pinchart

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.