[wdmaudiodev] Re: Raspberry Pi OTG Audio

  • From: Børge Strand-Bergesen <borge.strand@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Mon, 12 Feb 2018 11:01:47 +0100

Hi Robert,

You're possibly in for quite a bit of code work here. To me it was very
rewarding (in a suduko kind of way) to get all these mechanisms working on
all OSes. I had a very good starting point in the SDR-Widget project,
without which I wouldn't have had much success.


Then the device code would be the best way to start. If this was my project
(and limited by what you have written), my angle of attack would be:

- Get the descriptors right, at first with only one sample rate. Use
Thesycon Descriptor Dump (or similar) to compare your work to >> 1 working
device.

- Make a feedback endpoint which reports correctly formated data (but not
neccessarily correct data). Here you need to understand the XX.YY format
for rate reporting. The state machine I wrote has ways to simulate a
computer which ignores or won't understand the feedback endpoint. This is a
good place for you to understand the fb-ep.

- Make the state machine which calculates feedback data. The Audio-Widget
team put a lot of effort into this. It works on UAC1 and UAC2. Your state
machine should indicate buffer switching on GPIO pins. My code toggles GPIO
pins as the write pointer (sequential USB code) or read pointer (hardware
DMA) cross buffer addresses. Very-very-very useful as you study the
stability of your state machine.

- Expand the code to cover more more sample rates.


I wouldn't want to use this list to push products. But send me a pm if
you'd like to get the hardware on which the device code runs. Then you can
take working code and hardware as a starting point as you port stuff to
your own HW. Setting up the same build environment as I use for it will
take about a day.


Børge




On Mon, Feb 12, 2018 at 5:47 AM, Robert Bielik <Robert.Bielik@xxxxxxxxx>
wrote:

Now, all of this is a lot of code and large projects to get an overview
of.
Perhaps you could tell us what you wish to achieve. Do you need improved
device or driver code?

Pretty much fix the linux UAC2 gadget to be USB 2.0 compliant, i.e.
provide a feedback ep for the OUT ep. Today this stops linux audio gadgets
from working in windows. They do however seem to work on Mac and Linux
(AFAIK), so I'm not sure how that works 😊

Regards
/Robert

"Set the phase" = "define the speed" in this context.

Cheers,
Børge



On Sun, Feb 11, 2018 at 7:37 PM, Robert Bielik <Robert.Bielik@xxxxxxxxx
<mailto:Robert.Bielik@xxxxxxxxx> > wrote:


      Thanks Børge,

      > If it is of any help: I work on an open source project with
UAC2 device and
      > ASIO driver, both with audio OUT and feedback IN
endpoints. All functional.

      It might be, do you have a link to that project ?

      > AFAIK you can use an audio IN endpoint to set the phase as
an alternative to
      > dedicated feedback IN.

      Ok, don't really know what phase means in this context, but I'll
look it up 😊

      Regards
      /Robert

      >
      > Børge
      >
      > On Sunday, February 11, 2018, Robert Bielik
<Robert.Bielik@xxxxxxxxx <mailto:Robert.Bielik@xxxxxxxxx>

      > <mailto:Robert.Bielik@xxxxxxxxx
<mailto:Robert.Bielik@xxxxxxxxx> > > wrote:
      >
      >
      >       > Wait, never mind – I recognize that failing status code.
      > usbaudio2.sys is
      >       > complaining that you have an asynchronous data OUT
      > endpoint but it can’t
      >       > find a corresponding feedback endpoint.
      >
      >       Thanks Matthew, that explains it. And this is, as of linux
4.15.*
      > not implemented, there is no feedback endpoint defined in
the UAC2 gadget
      > driver.
      >
      >       Damn.
      >
      >       Regards
      >       /Robert
      >
      >
      >





Other related posts: