From: LCID Fire <lcid-fire@gmx.net>
To: alsa-devel@alsa-project.org
Subject: Re: Questions on usb audio development
Date: Mon, 21 May 2007 22:51:33 +0200 [thread overview]
Message-ID: <46520655.7000402@gmx.net> (raw)
In-Reply-To: <s5hk5v2p4az.wl%tiwai@suse.de>
Takashi Iwai wrote:
> The major difference between the normal PCI and USB audio drivers is
> that USB audio has no traditional DMA like most PCI devices have.
> Thus the driver has to sets up URB pakets. usb-audio driver creates
> an intermediate ring-buffer that is used for the communication from/to
> user-space, and URBs are made from this buffer.
Basicly the reoccuring interface pattern I'm facing is:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol 0
iInterface 6 LineIn2
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 9
Transfer Type Isochronous
Synch Type Adaptive
Usage Type Data
wMaxPacketSize 0x00b8 1x 184 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
Which is - if you ask me a normal audio token - hidden as a vendor
specific interface. So what do you think, are these 2 descriptors just
the audio format info or have they really embedded some specific info
for the class? Question is whether to wire that with FIXED_ENDPOINT or
STANDARD_INTERFACE?
The others are:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 0
iInterface 15 Line 1
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Which again does not seem to be more than the sync node of an audio
device (especially as it seems like they did not even change the subclass).
Well and I just for a start tried to write a quirks sections for these
nodes like:
{
USB_DEVICE(0x13e5, 0x0001),
.driver_info = (unsigned long) & (const struct snd_usb_audio_quirk)
{
.ifnum = QUIRK_ANY_INTERFACE,
.type = QUIRK_COMPOSITE,
.data = & (const struct snd_usb_audio_quirk[])
{
{
.ifnum = 0,
.altsetting = 0,
.type = QUIRK_AUDIO_STANDARD_INTERFACE
},
{
.ifnum = 0,
.type = QUIRK_AUDIO_FIXED_ENDPOINT,
.data = & (const struct audioformat)
{
.format = SNDRV_PCM_FORMAT_S16_LE,
.channels = 2,
.iface = 0,
.altsetting = 1,
.altset_idx = 1,
.attributes = 0,
.endpoint = 0x01,
.ep_attr = 0x09,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 44100,
.rate_max = 44100,
}
},
{
.ifnum = 2,
.type = QUIRK_AUDIO_FIXED_ENDPOINT,
.data = & (const struct audioformat)
{
.format = SNDRV_PCM_FORMAT_S16_LE,
.channels = 2,
.iface = 2,
.altsetting = 1,
.altset_idx = 1,
.attributes = 0,
.endpoint = 0x82,
.ep_attr = 0x09,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 44100,
.rate_max = 44100,
}
},
{
.ifnum = 3,
.altsetting = 0,
.type = QUIRK_AUDIO_STANDARD_INTERFACE
},
{
.ifnum = 4,
.type = QUIRK_AUDIO_FIXED_ENDPOINT,
.data = & (const struct audioformat)
{
.format = SNDRV_PCM_FORMAT_S16_LE,
.channels = 2,
.iface = 4,
.altsetting = 1,
.altset_idx = 1,
.attributes = 0,
.endpoint = 0x04,
.ep_attr = 0x09,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 44100,
.rate_max = 44100,
}
},
{
.ifnum = 5,
.type = QUIRK_AUDIO_FIXED_ENDPOINT,
.data = & (const struct audioformat)
{
.format = SNDRV_PCM_FORMAT_S16_LE,
.channels = 2,
.iface = 5,
.altsetting = 1,
.altset_idx = 1,
.attributes = 0,
.endpoint = 0x84,
.ep_attr = 0x09,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 44100,
.rate_max = 44100,
}
},
{
.ifnum = 6,
.altsetting = 0,
.type = QUIRK_AUDIO_STANDARD_INTERFACE
},
{
.ifnum = 7,
.type = QUIRK_AUDIO_FIXED_ENDPOINT,
.data = & (const struct audioformat)
{
.format = SNDRV_PCM_FORMAT_S16_LE,
.channels = 2,
.iface = 7,
.altsetting = 1,
.altset_idx = 1,
.attributes = 0,
.endpoint = 0x85,
.ep_attr = 0x09,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 44100,
.rate_max = 44100,
}
},
{
.ifnum = -1
}
}
}
},
So could anyone please tell me whether I'm totally lost on a wrong track?
next prev parent reply other threads:[~2007-05-21 20:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-20 15:47 Questions on usb audio development LCID Fire
2007-05-20 19:25 ` Lee Revell
2007-05-21 15:47 ` Takashi Iwai
2007-05-21 20:51 ` LCID Fire [this message]
2007-06-07 20:58 ` Quirks device not showing up LCID Fire
2007-06-08 6:27 ` Clemens Ladisch
2007-06-08 14:17 ` LCID Fire
2007-06-08 21:17 ` Lee Revell
2007-06-09 8:32 ` LCID Fire
2007-06-11 21:25 ` LCID Fire
2007-06-11 22:35 ` Lee Revell
2007-06-11 22:38 ` LCID Fire
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=46520655.7000402@gmx.net \
--to=lcid-fire@gmx.net \
--cc=alsa-devel@alsa-project.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).