Possible message repeat

Possible message repeat

[Brent Weatherall]

Hello.  I sent this message previously before I solidified my membership to
the list and it seems my message never posted.  Here it is again.
 My apologies if did go through and I missed it.

I am new to audio development in Linux.  I have worked with user space
development with respect to UVC code and I have worked with specifying an
XU in UVC.  I wrote a user space driver/application to talk to a device
supporting the UVC XU in Linux.  I am trying to specify an extension to the
UAC specification and then write a user space driver/application to use the
extension when a device that supports it is available in Linux.  Pretty
much the same situation as I have already done with UVC XU.  Windows and
Mac code will follow, but right now I am only concerned with Linux.

Can anyone assist me with the best path forward for writing user space code
to use the XU I am going to define?  Meaning generically speaking how to
use UAC XU controls in ALSA.  I was looking for code samples that use the
audio.h header file interface, but after a day and a half I am coming to
conclusion that only kernel space uses audio.h and that I will need to go
through ALSA to accomplish my task.  Again, this will be user space code I
want distribute easily, with minimal dependencies.  Our code will be
apache licensed afterwards if possible, just like our UVC code was.  So any
work I do should be freely available to the community afterwards. **EDIT
FROM PREVIOUS MESSAGE**  After more searching, it appears that any XU
controls would be processed through usbmixer.c, but I don't see how to use
the code in usbmixer from user space.  And so far I can't tell what source
usbmixer resides in.  I downloaded the alsa-lib source in Fedora, but I
don't see that file.  Is this a Linux kernel file?  So far I am having lots
of trouble finding anything useful regarding audio XUs in Linux.  My
apologies if this should be simple.  Thank you in advance for
any assistance.

Best Regards,

Brent

Re: Possible message repeat

[Clemens Ladisch]

Brent Weatherall wrote:
> I am trying to specify an extension to the UAC specification and then
> write a user space driver/application to use the extension when
> a device that supports it is available in Linux.
>
> Can anyone assist me with the best path forward for writing user space code
> to use the XU I am going to define?  Meaning generically speaking how to
> use UAC XU controls in ALSA.

XU controls cannot be used generically.  The driver must be extended to
create the vendor-specific controls of this particular device; or the
driver could get a function to allow userspace to add such controls.

> it appears that any XU controls would be processed through usbmixer.c,
> but I don't see how to use the code in usbmixer from user space.

That code creates mixer controls.

> And so far I can't tell what source usbmixer resides in.

sound/usb/mixer.c in the kernel source, although such extensions
probably belong into mixer_quirks.c.


Regards,
Clemens

Re: Possible message repeat

[Brent Weatherall]

Clemens.  I just wanted to clarify the situation.  It seemed you were
hinting at the possibility, but I was not 100% sure.  Thank you for
clearing that up.

On Mon, Jun 25, 2012 at 2:49 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Brent Weatherall wrote:
> > our goal is to specify a special XU that WOULD require vendors
> > supporting it to modify their firmware.  We fully expect a vendor to
> > modify their firmware to support our specification.  That being said,
> > is there a simple way to use ALSA to communicate with a vendor
> > specific XU as long as the software understands the XU?  For example,
> > in the video4linux2 world, we can specify a UVC XU with a set of
> > controls for special processing, then vendors that want to support it
> > modify their firmware to support it.  Then anyone can use our custom
> > user-space drivers to easily talk to the video device.  V4L2 has
> > controls made for using XUs in this manner.
>
> The audio class specification does not define any mechanism for a device
> to specify what those controls would be.  And because nobody has ever
> needed to use XUs so far, the current ALSA driver has no other way to
> create such controls.
>
> If you insist on not changing ALSA, you must bypass it.
>
>
> Regards,
> Clemens
>

Re: Possible message repeat

[Clemens Ladisch]

Brent Weatherall wrote:
> our goal is to specify a special XU that WOULD require vendors
> supporting it to modify their firmware.  We fully expect a vendor to
> modify their firmware to support our specification.  That being said,
> is there a simple way to use ALSA to communicate with a vendor
> specific XU as long as the software understands the XU?  For example,
> in the video4linux2 world, we can specify a UVC XU with a set of
> controls for special processing, then vendors that want to support it
> modify their firmware to support it.  Then anyone can use our custom
> user-space drivers to easily talk to the video device.  V4L2 has
> controls made for using XUs in this manner.

The audio class specification does not define any mechanism for a device
to specify what those controls would be.  And because nobody has ever
needed to use XUs so far, the current ALSA driver has no other way to
create such controls.

If you insist on not changing ALSA, you must bypass it.


Regards,
Clemens