All of lore.kernel.org
 help / color / mirror / Atom feed
From: Howard Spoelstra <hsp.cat7@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Programmingkid <programmingkidx@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: Implementing isochronous transfers in hw/hcd-ohci.c
Date: Fri, 10 Sep 2021 08:12:17 +0200	[thread overview]
Message-ID: <CABLmASHenOBj-15oOYvsai8YJuJHbnpVCXW3vAwF3kA=eoPiyQ@mail.gmail.com> (raw)
In-Reply-To: <20210910050740.pgdcwhe5scohepps@sirius.home.kraxel.org>

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

On Fri, Sep 10, 2021 at 7:07 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Thu, Sep 09, 2021 at 05:06:17PM -0400, Programmingkid wrote:
> > Hi Gerd,
> >
> > Howard and I were talking about USB audio problems with Mac OS guests.
> We think the issue might be with frames being sent to the USB audio card
> too soon. My guess is only one frame is suppose to be transmitted every 1
> millisecond. I was also reading the todo notes in the file hw/hcd-ohci.c.
> This is what it says:
> >
> >  * TODO:
> >  *  o Isochronous transfers
> >  *  o Allocate bandwidth in frames properly
> >  *  o Disable timers when nothing needs to be done, or remove timer usage
> >  *    all together.
> >  *  o BIOS work to boot from USB storage
> > */
> >
> > Do you think implementing isochronous transfers would fix the audio
> problems Mac OS guest are experiencing?
>
> Most likely yes, audio devices typically use iso endpints.
>
> take care,
>   Gerd
>

Hi,

Below I pasted the first lines mentioning isochronous traffic from a pcap
file when running fedora12 with the usb-audio device and the first lines
from a pcap file running Mac OS 9.2 with the usb-audio device

Fedora:
91 56.715001 host 0.5.1 USB 256 URB_ISOCHRONOUS out
92 56.715018 0.5.1 host USB 64 URB_ISOCHRONOUS out

MacOS:
143 56.031989 host 0.16.1 USB 256 URB_ISOCHRONOUS out
144 56.032026 0.16.1 host USB 64 URB_ISOCHRONOUS out

The usb-audio device works for the fedora guest, so would this not indicate
that the iso endpoints are already working?

The usb-audio device also work (for a limited amount of time) when running
MacOS. Looking at USB logging in the Mac OS guest, to me it seems the MacOS
side runs into timing issues when packages drift too far apart. It then
finally gives up trying to keep the stream open.

Best,
Howard

[-- Attachment #2: Type: text/html, Size: 2442 bytes --]

  reply	other threads:[~2021-09-10  6:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 21:06 Implementing isochronous transfers in hw/hcd-ohci.c Programmingkid
2021-09-10  5:07 ` Gerd Hoffmann
2021-09-10  6:12   ` Howard Spoelstra [this message]
2021-09-10  7:51     ` Gerd Hoffmann
2021-09-10 11:51     ` BALATON Zoltan
2021-09-10 19:23       ` Programmingkid
2021-09-11  9:46         ` Howard Spoelstra
2021-09-11 15:10           ` Programmingkid

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='CABLmASHenOBj-15oOYvsai8YJuJHbnpVCXW3vAwF3kA=eoPiyQ@mail.gmail.com' \
    --to=hsp.cat7@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=programmingkidx@gmail.com \
    --cc=qemu-devel@nongnu.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.