I am working on a usb over ip driver. USB headset is connected to linux and usbaudio.sys driver is getting installed properly in windows.
mic works fine, but when i play some file on windows , i heard glitches on speaker , connected at linux side.
I observed that if i play even Media palyer default video, it runs slower and os is keep sending querybustime() call at windows side.
i also recorded data going through isochronous out call(in usbip driver) and also recorded time (when i start playing until file play end). data is fine when played in any player as a raw data but I observe that for 50 sec play file it is taking 83 sec.( difference between first isoch call and last isoch data call)
what type of behaviour it is , is network latency is playing some role???
I have the same problem with audio out using a RDPEUSB-based IP transport.
I haven’t fixed this problem yet, but its most likely cause is rooted in the
fact that the time base for audio generation (host-side) and audio
regeneration (linux-side in our case) are not perfectly synchronized. The
host using querybustime() is attempting to get information about the
remote end time base, but this isn’t perfect. When glitches occur you may
have lost an audio sample (host clock faster than remote) or possibly missed
a playback time slot (host clock slower than remote).
Does you querybustime information come from the host or the remote? Getting
this information from the remote is best.
There’s probably a way to improve this, but I haven’t delved into it yet.
Thomas F. Divine
From: Sent: Monday, December 17, 2012 4:20 AM To: “Windows System Software Devs Interest List” Subject: [ntdev] usbaudio data out problem
> I am working on a usb over ip driver. USB headset is connected to linux > and usbaudio.sys driver is getting installed properly in windows. > mic works fine, but when i play some file on windows , i heard glitches on > speaker , connected at linux side. > I observed that if i play even Media palyer default video, it runs slower > and os is keep sending querybustime() call at windows side. > > i also recorded data going through isochronous out call(in usbip driver) > and also recorded time (when i start playing until file play end). data is > fine when played in any player as a raw data but I observe that for 50 sec > play file it is taking 83 sec.( difference between first isoch call and > last isoch data call) > > what type of behaviour it is , is network latency is playing some role??? > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
Thank You Thomas for your Reply.
Query Bustime is continous called from Windows (host side).
I feel that after sending Isoch IRP , windows media player is waiting for its completion and now in this situation i am making IRP pending until linux send me the Isoch return data . I think that is why windows is delaying ISoch calls ,that could be the reason why when i play 55 sec file(normal play time == 55 sec) on windows, and record the timing (time difference between first isoch and last isoch call) windows media player takes 83 sec(when usb over ip is active) .
Query Bustime is continous called from Windows (host side).
I feel that after sending Isoch IRP , windows media player is waiting for its completion and now in this situation i am making IRP pending until linux send me the Isoch return data .
Windows Media Player doesn’t know anything about USB. The URBs are
being sent by the usbaudio.sys driver, which has its own “continuous
reader”. It submits two isochronous URBs simultaneously and keeps them
running, so it can process one while the other continues. Each URB is
only large enough for 10ms of data, so the timing it very tight. Any
delays will result in gaps, which are interpreted as silence, and
stretches the timing. There are no timestamps in a USB Audio Class
stream. You have to keep the data moving consistently.
You need to understand the isochronous processing very well if you’re
going to pretend to be a USB host controller. Do you understand how to
fill out the IsoPacket structure? That’s critical for isochronous reads.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank Yoy Tim for your reply.
You are right, i can see only two urb’s at a time. when i satisfy Isoch out transactions immediately, after 2-3 irp’s , usbaudio stop sending URB’s and mediaplayer doesnt play files either.
in USBD_ISO_PACKET_DESCRIPTOR
i get USBD_ISO_PACKET_DESCRIPTOR.offset value so i keep it as it is,
USBD_ISO_PACKET_DESCRIPTOR.length doesnt matter for out transactions
and USBD_ISO_PACKET_DESCRIPTOR.status is set to 0 i.e successful always
URB_ISOCH_TRANSFER.Errorcount is also set to 0; Hdr.Status = USBD_STATUS_SUCCESS always.
Pls guide me if these values are correct.
i am stuck and fighting with prj deadlines.
You are right, i can see only two urb’s at a time. when i satisfy Isoch out transactions immediately, after 2-3 irp’s , usbaudio stop sending URB’s and mediaplayer doesnt play files either.
in USBD_ISO_PACKET_DESCRIPTOR
i get USBD_ISO_PACKET_DESCRIPTOR.offset value so i keep it as it is,
USBD_ISO_PACKET_DESCRIPTOR.length doesnt matter for out transactions
and USBD_ISO_PACKET_DESCRIPTOR.status is set to 0 i.e successful always
URB_ISOCH_TRANSFER.Errorcount is also set to 0; Hdr.Status = USBD_STATUS_SUCCESS always.
Have you used a debugger to watch what happens when this request is
submitted to real hardware? For example, maybe the IsoPacket array
Status value gets set to an error for packets beyond the buffer length.
Maybe usbaudio.sys expects you to respond in real-time (with delays) and
gets suspicious when your device responds too quickly.
Isochoronous OUT operations are uncommon enough that I don’t have the
details memorized.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes i checked when this request goes to linux , its not setting any error etc, however windows is sending querybustime multiple times which i am not handling now(as i dnt know how much time it is going to take for a request to travel and goto linux and come back so which frame no is to be provided). I ll do more analysis to find out the solution.
