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 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.