[wdmaudiodev] Re: wdmaudiodev Digest V6 #170

  • From: Jerry Evans <jerry@xxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Fri, 06 Nov 2009 16:48:56 +0000

If you are talking to Cypress silicon, you could try using the oven-baked isoch driver shipped in the freely downloadable Cypress USB dev kit. This might help pinpoint the issue without a massive investment in learning/debugging/frustration.


Jerry

Steve Hayashi wrote:
Hello,

Thanks for responding to me. You're probably correct in that this is a firmware bug, and that the only way to really fix it is to just write my own drivers for it. Writing a device driver is something I've never done before, but I've always been curious to try it. This is an incredibly simple device from an I/O perspective, just USB in and RCA audio out and 1/8" plug out. There's a volume dial for headphone output, but none of that is reported back. No digital volume control, no eq at any level.

Anyways, with the member variable, it stalls at different points. Sometimes it stalls at the Get_Curr for volume. Sometimes it's Get_Min for volume. Other times it stalls at Get_Res for treble. Sometimes it doesn't stall at any thing at all, and that's when it starts working.

Given the simple nature of the audio device, it always reports back with the same information for all of them, so it seems unnecessary to query this information, when it could be stored. Especially since a stall response to the query seems to break the driver i.e. when the host receives the stall response, it stops querying other variables.

I have a feeling that this will pretty much be happy with just Isochronous transfers, so I'd love to get it to a stage where all I need to do is stream audio packets to it.

Thanks,
-Steve

Clemens Ladisch Wrote:
    Steve Hayashi wrote:
    > Unfortunately, my device will send a stall response to the member variable
    > query

    Which member variable?  Is the query correct, i.e., do the device's
    descriptors indicate that that query should be supported?

    This looks like a typical firmware bug; many low-quality USB devices
    have not been written against the spec but to work with some random
    Windows version that was currently available for testing.

    > My primary goal is to get the usb audio device working normally all the
    > time, ideally through some minor change that I was previously unaware of.

    Well, neither replacing the device's firmware not writing your own
    USB audio driver looks like a minor change.


    Best regards,
    Clemens

Other related posts: