From: Ethin Probst <ethindp@pm.me>
To: Lars Melin <larsm17@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: Assistance getting the Universal Audio Apollo Solo USB to work with Linux
Date: Thu, 16 May 2024 05:56:03 +0000 [thread overview]
Message-ID: <5jZCAcuLt5YeqkzP4xk28ICJ2WQUxY1eht4CjJNdnGymv3q6AIk3WugtglGVjqvu6BPVO7zHNx7LJeMnS71JUcoNpVZAMmz4o7G4vVyu0GU=@pm.me> (raw)
In-Reply-To: <8d415ea6-fe5a-4ec0-8e95-45c03968e666@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3198 bytes --]
On Thursday, May 16th, 2024 at 00:19, Lars Melin <larsm17@gmail.com> wrote:
> On 2024-05-16 05:12, Ethin Probst wrote:
>
> > On Sunday, May 12th, 2024 at 09:13, Alan Stern stern@rowland.harvard.edu wrote:
> >
> > > ...
> >
> > > Most likely, Windows sends some firmware to the device (which it needs
> > > in order to run properly) and then restarts the device.
> >
> > I don't believe this is happening after trying to dig into the
> > captures a bit more. The firmware blobs that are in the archive are
> > over 100000 bytes, and though there are some significantly large
> > transfers, there isn't a single transfer that is the size of the
> > firmware blob. I can't tell for certain though; VirtualBox truncated
> > those large frames, so I'm uncertain what data is in them.
>
>
> The .inf files in your drivers directory clearly tells the difference
> between the two USB Id's.
> The description of 2b5a:000c is "UAD2 Arrow Firmware Loader" while the
> description for 2b5a:000d is "Universal Audio Apollo Solo USB" so there
> is no doubt what the initial pid 000c is intended for.
Ah, I didn't look too deeply into those, I should've! :)
> There is nothing in your packet captures indicating a firmware transfer
> but that does not necessarily have to happen, there might just be a
> check of what firmware version is currently loaded in your audio
> hardware and if their isn't a more recent one in the firmware directory
> then everything is ok.
The trick then is to figure out what makes it make the transition. I
don't know if it's vendor-specific or not and I'm uncertain how to
"replay" the packets, particularly given that they're truncated.
> What puzzles me is your ua-init-windows.pcap, it starts with the device
> already having the pid 000d (packet #2). You said that the capture
> starts when the device is plugged in but I think you have missed
> something, it should have started as pid 000c and later transitioned to
> pid 000d.
>
> I can also not find such a transition in your other two captures, all
> descriptor readouts that includes USB Id are 2b5a:000c.
This is what puzzles me as well. If I'm missing something it's at a
level that USB Pcap can't capture. When I begin the capture, plug in
the device and power it on, the second packet is always the right
descriptor (pid 000d). There is no indicator in the capture that
commands are sent before that pid is received. As for the other
problem, yeah, that confused me too; I would've thought that another
get descriptor request would've been sent, but apparently not, because
when I remove the device from the VM and reattach it to the host, the
pid is correct.
If you want I can try another capture, though I'm not sure how useful
that would be. I can also try another VM-based USB capture as well. If
I'm the only person on this list with this device I don't mind doing
all the debugging; the device isn't super expensive but it's also not
really cheap, either. It also needs some extra setup to get it
working, but perhaps that setup process could give us an idea as to
more things we're missing.
>
> rgds
> Lars
>
[-- Attachment #1.2: publickey - ethindp@pm.me - 0x846BFA7B.asc --]
[-- Type: application/pgp-keys, Size: 4337 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
next prev parent reply other threads:[~2024-05-16 5:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-11 20:07 Assistance getting the Universal Audio Apollo Solo USB to work with Linux Ethin Probst
2024-05-12 14:13 ` Alan Stern
[not found] ` <8fcVwO4QZdKndXMug6gtJOMJ7bCUM0dk3lfyiKsUSR1QFvQeQ1SdRkQUUTJd73wI_dgxAULH_oTBA64hdSb3JYiwAyejHLM7RccUgY1m4sM=@pm.me>
2024-05-13 1:14 ` Alan Stern
2024-05-15 22:12 ` Ethin Probst
2024-05-16 5:19 ` Lars Melin
2024-05-16 5:56 ` Ethin Probst [this message]
2024-05-16 10:09 ` Lars Melin
2024-05-17 19:10 ` Ethin Probst
2024-05-17 21:43 ` Ethin Probst
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='5jZCAcuLt5YeqkzP4xk28ICJ2WQUxY1eht4CjJNdnGymv3q6AIk3WugtglGVjqvu6BPVO7zHNx7LJeMnS71JUcoNpVZAMmz4o7G4vVyu0GU=@pm.me' \
--to=ethindp@pm.me \
--cc=larsm17@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).