From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: alsa-devel@alsa-project.org
Subject: M-Audio transit: illegal sync type and noise on startup?
Date: Wed, 12 Aug 2015 23:07:51 -0500 [thread overview]
Message-ID: <55CC1817.1020500@linux.intel.com> (raw)
While playing with my M-Audio Transit USB device (0763:2006) I saw a synchronization type that doesn't exist in the USB audio class. I get audio out but often the start is garbled with white noise and cracks. Wondering what's going on.
more /proc/asound/card1/stream0
M-Audio Transit USB at usb-0000:00:14.0-2, full speed : USB Audio
Playback:
Status: Stop
Interface 1
Altset 1
Format: S24_3LE
Channels: 2
Endpoint: 3 OUT (ADAPTIVE)
Rates: 48001 - 96000 (continuous)u
Interface 1
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 3 OUT (NONE) <<<<<<< illegal
Rates: 8000 - 48000 (continuous)
Interface 1
Altset 3
Format: S16_LE
Channels: 2
Endpoint: 3 OUT (ASYNC)
Rates: 8000 - 48000 (continuous)
The only definitions in the spec are Asynchronous, Adaptive or Synchronous...
lsusb tells me that there seems to be a synch endpoint for this setting:
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0126 1x 294 bytes
bInterval 1
bRefresh 0
bSynchAddress 131
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 1 Milliseconds
wLockDelay 100 Milliseconds
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0003 1x 3 bytes
bInterval 1
bRefresh 2
bSynchAddress 0
I couldn't figure out what the code does in this case. I didn't find any sync URBs being retired so wondering if this is considered as a synchronous or asynchronous endpoint based on the additional sync endpoint? Any idea on how to debug further? It looks like there could be a second error in the descriptors: if this is a synchronous endpoint then the sync endpoint is meaningless, and if it is asynchronous then the information on locking time is irrelevant...
Regarding the noise on startup, should a delay be inserted after the mode is set? the spec recommends that the host sends silence periods for adaptive and synchronous modes. I see a set of mdelays being added in the quirks, should a new one be added?
Thanks for any pointers,
-Pierre
reply other threads:[~2015-08-13 4:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=55CC1817.1020500@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--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