I am New to windows driver development. Please bear with me If I ask basic questions.
I am developing a (virtual) USB audio device which will be hooked to the USBIPEnum enumerator (http://usbip.sourceforge.net/).
My device enumeration is happening successfully on Windows 7. While trying to stream audio to my device, for every ISOCH OUT URB requests, after consuming the data from the endpoint, I am submitting success response. For these responses, I am getting ABORT_PIPE.
How do I know which driver is sending the error and why?
You might want to try gathering logs from the USB stack:
https://msdn.microsoft.com/en-us/library/windows/hardware/jj151577(v=vs.85).aspx
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@windbg…
I am New to windows driver development. Please bear with me If I ask basic
questions.
I am developing a (virtual) USB audio device which will be hooked to the
USBIPEnum enumerator (http://usbip.sourceforge.net/).
My device enumeration is happening successfully on Windows 7. While trying
to stream audio to my device, for every ISOCH OUT URB requests, after
consuming the data from the endpoint, I am submitting success response. For
these responses, I am getting ABORT_PIPE.
How do I know which driver is sending the error and why?
xxxxx@gmail.com wrote:
I am New to windows driver development. Please bear with me If I ask basic questions.
Asking is fine, but this is not the correct group. You should be asking
on [ntdev] or on [wdmaudiodev].
I am developing a (virtual) USB audio device which will be hooked to the USBIPEnum enumerator (http://usbip.sourceforge.net/).
My device enumeration is happening successfully on Windows 7. While trying to stream audio to my device, for every ISOCH OUT URB requests, after consuming the data from the endpoint, I am submitting success response. For these responses, I am getting ABORT_PIPE.
How do I know which driver is sending the error and why?
That should be pretty clear. Your client is usbaudio.sys. He is
detecting something wrong in your response, and is aborting the
transfer. Note that you are not the first person to encounter this:
http://osronline.com/ShowThread.cfm?link=229966
Usbaudio.sys is extremely picky about timing. It’s possible that it’s
simply the additional latency that is causing the issue. On the other
hand, it’s also possible that it’s relying on known values in some of
the reserved fields in the URB.
Are you shoving error/success codes into the IsoPacket array?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks a lot for the inputs Tim.
While I am still working on getting the timing right for my URB completion handler, I observed that despite sending the ABORTS , usbaudio.sys also sends the data that is getting played on the media player to my device (of course I have to cheat the driver that ABORT is handled properly).
Having said that, can I continue using the data before I fix the ABORT issue? Do you see any problem with that in terms of audio quality?
xxxxx@gmail.com wrote:
While I am still working on getting the timing right for my URB completion handler, I observed that despite sending the ABORTS , usbaudio.sys also sends the data that is getting played on the media player to my device (of course I have to cheat the driver that ABORT is handled properly).
Having said that, can I continue using the data before I fix the ABORT issue? Do you see any problem with that in terms of audio quality?
Who knows? Usbaudio.sys is aborting the pipe because it detected
something that made it unhappy. You cannot predict what it’s going to
do in that state, or where it became unhappy.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.