PCI WiFi causes USB Isoch packet loss!?

Hi!

I have a good working isoch streaming driver (full speed USB, queuing up
irp/urb pairs, etc...).
I usually run 12-15hrs long tests to see if any packet loss occurs. (XP sp2)
If my PCI wireless card is disabled in device manager, or at least the WiFi
connection is disabled in network settings, the test completes without any
package loss.
If the wireless card and the wireless network connection are both enabled
(so the connection is alive), isoch packet loss occurs every two minues
(exactly 120 seconds). Sometimes every minute (exactly 60 seconds).
The packet's fail status is usually 0xC0000A00 (bad startframe) or
0xC000000F.
It means that the wireless connection (even if I don't use it at all)
interrups my USB stream every 60 or 120 secs (exactly).
When I replace the wireless card (US Robotics) with another one (Linksys),
the packet loss occurs every 10 minutes. (exactly 600 seconds)

Can anyone explain what is going on and how to avoid this?
Can I recommend any wireless or registry setting to my driver's users to
avoid wifi interruption without disabling their wifi connection?

Thanks for your attention,
Greg1X

Maxim
Sun Mar 09 14:17:02 CDT 2008

So what? isoch is not 100% reliable by very definition.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"greg1x" <greg1x@yahoo.com> wrote in message
news:dc2db$47d3a695$5062c1fc$15972@news.chello.hu...
> Hi!
>
> I have a good working isoch streaming driver (full speed USB, queuing up
> irp/urb pairs, etc...).
> I usually run 12-15hrs long tests to see if any packet loss occurs. (XP sp2)
> If my PCI wireless card is disabled in device manager, or at least the WiFi
> connection is disabled in network settings, the test completes without any
> package loss.
> If the wireless card and the wireless network connection are both enabled
> (so the connection is alive), isoch packet loss occurs every two minues
> (exactly 120 seconds). Sometimes every minute (exactly 60 seconds).
> The packet's fail status is usually 0xC0000A00 (bad startframe) or
> 0xC000000F.
> It means that the wireless connection (even if I don't use it at all)
> interrups my USB stream every 60 or 120 secs (exactly).
> When I replace the wireless card (US Robotics) with another one (Linksys),
> the packet loss occurs every 10 minutes. (exactly 600 seconds)
>
> Can anyone explain what is going on and how to avoid this?
> Can I recommend any wireless or registry setting to my driver's users to
> avoid wifi interruption without disabling their wifi connection?
>
> Thanks for your attention,
> Greg1X
>
>

Alexander
Sun Mar 09 23:27:15 CDT 2008

I suspect EMI is causing USB error.

"greg1x" <greg1x@yahoo.com> wrote in message
news:dc2db$47d3a695$5062c1fc$15972@news.chello.hu...
> Hi!
>
> I have a good working isoch streaming driver (full speed USB, queuing up
> irp/urb pairs, etc...).
> I usually run 12-15hrs long tests to see if any packet loss occurs. (XP
> sp2)
> If my PCI wireless card is disabled in device manager, or at least the
> WiFi connection is disabled in network settings, the test completes
> without any package loss.
> If the wireless card and the wireless network connection are both enabled
> (so the connection is alive), isoch packet loss occurs every two minues
> (exactly 120 seconds). Sometimes every minute (exactly 60 seconds).
> The packet's fail status is usually 0xC0000A00 (bad startframe) or
> 0xC000000F.
> It means that the wireless connection (even if I don't use it at all)
> interrups my USB stream every 60 or 120 secs (exactly).
> When I replace the wireless card (US Robotics) with another one (Linksys),
> the packet loss occurs every 10 minutes. (exactly 600 seconds)
>
> Can anyone explain what is going on and how to avoid this?
> Can I recommend any wireless or registry setting to my driver's users to
> avoid wifi interruption without disabling their wifi connection?
>
> Thanks for your attention,
> Greg1X
>

greg1x
Mon Mar 10 02:55:42 CDT 2008

Mr. Shatskih!

Thank you for your reply.
Does it seem to be an isoch reliability problem to you? Loosing packets at
pre-dictable one-minute boundaries? (60 secs or 120 secs with one card, 600
secs with the other card)
It seems to me like a poorly written driver spends too much time in
interrupt and blocks everything each 60-120-600 seconds.
It must be related to the wireless LAN somehow.
..and it seems to be something with configurable time. (120 secs vs. 600
secs with different cards)

I need a WiFi expert to tell me what is common between two different WiFi
cards on the same system (drivers, services, monitoring software, etc..).
..and what could be that configurable interval that has always one minute
boundaries.

Regards,
Greg1X

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:u9BZpohgIHA.4712@TK2MSFTNGP04.phx.gbl...
> So what? isoch is not 100% reliable by very definition.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "greg1x" <greg1x@yahoo.com> wrote in message
> news:dc2db$47d3a695$5062c1fc$15972@news.chello.hu...
>> Hi!
>>
>> I have a good working isoch streaming driver (full speed USB, queuing up
>> irp/urb pairs, etc...).
>> I usually run 12-15hrs long tests to see if any packet loss occurs. (XP
>> sp2)
>> If my PCI wireless card is disabled in device manager, or at least the
>> WiFi
>> connection is disabled in network settings, the test completes without
>> any
>> package loss.
>> If the wireless card and the wireless network connection are both enabled
>> (so the connection is alive), isoch packet loss occurs every two minues
>> (exactly 120 seconds). Sometimes every minute (exactly 60 seconds).
>> The packet's fail status is usually 0xC0000A00 (bad startframe) or
>> 0xC000000F.
>> It means that the wireless connection (even if I don't use it at all)
>> interrups my USB stream every 60 or 120 secs (exactly).
>> When I replace the wireless card (US Robotics) with another one
>> (Linksys),
>> the packet loss occurs every 10 minutes. (exactly 600 seconds)
>>
>> Can anyone explain what is going on and how to avoid this?
>> Can I recommend any wireless or registry setting to my driver's users to
>> avoid wifi interruption without disabling their wifi connection?
>>
>> Thanks for your attention,
>> Greg1X
>>
>>
>

greg1x
Mon Mar 10 03:03:38 CDT 2008

Hi Mr. Grigoriev!

Thank you for you reply!
It doesn't seem to be an EMI problem, because:
1. It comes always on one minute boundaries
2. It does not relate to communication intensivity/content on WiFi (leave it
alone for 15 hrs and you get the same results as when you use WiFi heavily)

Please see my answer to Mr. Shatskih for the rest of my reasons and doubts.

I hope that some WiFi specialist is reading this thread. ;)
I would like to find out something like: Set this or that to "off" or
"1000000 minutes" instead of "2 minutes".

Regards,
Greg1X

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:ODtbGcmgIHA.1996@TK2MSFTNGP03.phx.gbl...
>I suspect EMI is causing USB error.
>
> "greg1x" <greg1x@yahoo.com> wrote in message
> news:dc2db$47d3a695$5062c1fc$15972@news.chello.hu...
>> Hi!
>>
>> I have a good working isoch streaming driver (full speed USB, queuing up
>> irp/urb pairs, etc...).
>> I usually run 12-15hrs long tests to see if any packet loss occurs. (XP
>> sp2)
>> If my PCI wireless card is disabled in device manager, or at least the
>> WiFi connection is disabled in network settings, the test completes
>> without any package loss.
>> If the wireless card and the wireless network connection are both enabled
>> (so the connection is alive), isoch packet loss occurs every two minues
>> (exactly 120 seconds). Sometimes every minute (exactly 60 seconds).
>> The packet's fail status is usually 0xC0000A00 (bad startframe) or
>> 0xC000000F.
>> It means that the wireless connection (even if I don't use it at all)
>> interrups my USB stream every 60 or 120 secs (exactly).
>> When I replace the wireless card (US Robotics) with another one
>> (Linksys), the packet loss occurs every 10 minutes. (exactly 600 seconds)
>>
>> Can anyone explain what is going on and how to avoid this?
>> Can I recommend any wireless or registry setting to my driver's users to
>> avoid wifi interruption without disabling their wifi connection?
>>
>> Thanks for your attention,
>> Greg1X
>>
>
>

Philip
Mon Mar 10 06:00:12 CDT 2008

The Wireless Zero Config Service scans for access points on all channels
every minute....

Phil

greg1x
Mon Mar 10 06:13:00 CDT 2008

Thanks Phil!

It was my first idea to stop, but the problem remains when I stop the
service.
Maybe some other layer with the same behavior?

Regards,
Greg1X

"Philip Doragh" <someone@microsoft.com> wrote in message
news:0x8Bj.12135$Mw.5476@nlpi068.nbdc.sbc.com...
> The Wireless Zero Config Service scans for access points on all channels
> every minute....
>
> Phil
>
>

Tim
Tue Mar 11 00:45:58 CDT 2008

"greg1x" <greg1x@yahoo.com> wrote:
>
>Does it seem to be an isoch reliability problem to you? Loosing packets at
>pre-dictable one-minute boundaries? (60 secs or 120 secs with one card, 600
>secs with the other card)
>It seems to me like a poorly written driver spends too much time in
>interrupt and blocks everything each 60-120-600 seconds.
>It must be related to the wireless LAN somehow.
>..and it seems to be something with configurable time. (120 secs vs. 600
>secs with different cards)

Possibly so, but whatever the cause, it is irrelevant. An isochronous pipe
does not offer guaranteed delivery. Your driver must be able to handle the
drops.

If you need guaranteed delivery, use a bulk pipe.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim
Tue Mar 11 00:48:49 CDT 2008

"greg1x" <greg1x@yahoo.com> wrote:
>
>Please see my answer to Mr. Shatskih for the rest of my reasons and doubts.
>
>I hope that some WiFi specialist is reading this thread. ;)
>I would like to find out something like: Set this or that to "off" or
>"1000000 minutes" instead of "2 minutes".

The ANSWER is to put this into your knowledge base for support calls. You
can't stop it, and even if you COULD ask all your clients to change their
configurations for your device, it's going to be something different the
next time.

Isochronous pipes do not offer guaranteed delivery. End of story.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

greg1x
Tue Mar 11 01:59:16 CDT 2008

Mr. Roberts!

> The ANSWER is to put this into your knowledge base for support calls. You
> can't stop it, and even if you COULD ask all your clients to change their
> configurations for your device, it's going to be something different the
> next time.
>
> Isochronous pipes do not offer guaranteed delivery. End of story.

I didn't mention yet, but this is is an audio-related real-time device used
in virtual studios.
Professional people using virtual studios (VST hosts, VSTis, ASIO, etc...)
are known to maintain an XP installation dedicated to music production. They
are setting up their music production XP for nothing else, but low latency
error-free music production.
They are setting up their production XPs depending on advises on
http://www.musicxp.net and Steinberg.net:
http://knowledgebase.steinberg.net/91_1.html (setting processor scheduling
to background processes). There are plenty of fine-tuning modifications
those musicians are performing on their XPs before using it for production.
So, answers like use a bulk pipe and use error handling are useless for
their situation as both of these "solutions" are significantly increasing
latency.

I'll have to tell them a new hint: Disable your WiFi card on your production
XP.
All I'm looking for here is a lighter hint than that. I would like to keep
their network still working at production time. Something like: Turn off
this, set that..
Those people are very special ones and require special solutions without
quality loss. Increasing latency is a huge quality loss.

So, if anyone had a useful hint on that, I would be very thankful.

Regards,
Greg1X

Alexander
Tue Mar 11 22:20:16 CDT 2008

Use bulk pipe. You won't notice any hiccups. A single device on USB can get
up to 40 MB/s, which is way more than necessary for audio.
And no, bulk pipe does not increase latency. If you think otherwise, you
misunderstand USB protocol a bit.

And properly written audio software doesn't require any XP tuning, sorry. If
Steinberg needs that, their programmers don't know something about Windows.

"greg1x" <greg1x@yahoo.com> wrote in message
news:OwwfzV0gIHA.1188@TK2MSFTNGP04.phx.gbl...
> Mr. Roberts!
>
>> The ANSWER is to put this into your knowledge base for support calls.
>> You
>> can't stop it, and even if you COULD ask all your clients to change their
>> configurations for your device, it's going to be something different the
>> next time.
>>
>> Isochronous pipes do not offer guaranteed delivery. End of story.
>
> I didn't mention yet, but this is is an audio-related real-time device
> used in virtual studios.
> Professional people using virtual studios (VST hosts, VSTis, ASIO, etc...)
> are known to maintain an XP installation dedicated to music production.
> They are setting up their music production XP for nothing else, but low
> latency error-free music production.
> They are setting up their production XPs depending on advises on
> http://www.musicxp.net and Steinberg.net:
> http://knowledgebase.steinberg.net/91_1.html (setting processor scheduling
> to background processes). There are plenty of fine-tuning modifications
> those musicians are performing on their XPs before using it for
> production.
> So, answers like use a bulk pipe and use error handling are useless for
> their situation as both of these "solutions" are significantly increasing
> latency.
>
> I'll have to tell them a new hint: Disable your WiFi card on your
> production XP.
> All I'm looking for here is a lighter hint than that. I would like to keep
> their network still working at production time. Something like: Turn off
> this, set that..
> Those people are very special ones and require special solutions without
> quality loss. Increasing latency is a huge quality loss.
>
> So, if anyone had a useful hint on that, I would be very thankful.
>
> Regards,
> Greg1X
>

greg1x
Wed Mar 12 04:10:43 CDT 2008

Mr. Grigoriev!

With all of my respect to you, let me take some facts into your attention:
- All USB Audio devices use isoch pipes, not bulk pipes (everyone knows here
why)
- Steinberg invented both VST and ASIO. They are the ones who know
everything about virtual studios on Windows.

Regards,
Greg1X

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:uKjsAA$gIHA.4712@TK2MSFTNGP04.phx.gbl...
> Use bulk pipe. You won't notice any hiccups. A single device on USB can
> get up to 40 MB/s, which is way more than necessary for audio.
> And no, bulk pipe does not increase latency. If you think otherwise, you
> misunderstand USB protocol a bit.
>
> And properly written audio software doesn't require any XP tuning, sorry.
> If Steinberg needs that, their programmers don't know something about
> Windows.
>
> "greg1x" <greg1x@yahoo.com> wrote in message
> news:OwwfzV0gIHA.1188@TK2MSFTNGP04.phx.gbl...
>> Mr. Roberts!
>>
>>> The ANSWER is to put this into your knowledge base for support calls.
>>> You
>>> can't stop it, and even if you COULD ask all your clients to change
>>> their
>>> configurations for your device, it's going to be something different the
>>> next time.
>>>
>>> Isochronous pipes do not offer guaranteed delivery. End of story.
>>
>> I didn't mention yet, but this is is an audio-related real-time device
>> used in virtual studios.
>> Professional people using virtual studios (VST hosts, VSTis, ASIO,
>> etc...) are known to maintain an XP installation dedicated to music
>> production. They are setting up their music production XP for nothing
>> else, but low latency error-free music production.
>> They are setting up their production XPs depending on advises on
>> http://www.musicxp.net and Steinberg.net:
>> http://knowledgebase.steinberg.net/91_1.html (setting processor
>> scheduling to background processes). There are plenty of fine-tuning
>> modifications those musicians are performing on their XPs before using it
>> for production.
>> So, answers like use a bulk pipe and use error handling are useless for
>> their situation as both of these "solutions" are significantly increasing
>> latency.
>>
>> I'll have to tell them a new hint: Disable your WiFi card on your
>> production XP.
>> All I'm looking for here is a lighter hint than that. I would like to
>> keep their network still working at production time. Something like: Turn
>> off this, set that..
>> Those people are very special ones and require special solutions without
>> quality loss. Increasing latency is a huge quality loss.
>>
>> So, if anyone had a useful hint on that, I would be very thankful.
>>
>> Regards,
>> Greg1X
>>
>
>

Alexander
Wed Mar 12 21:40:17 CDT 2008

1. If you use isoch pipe, you must accept possibility of packet loss. If
you're OK with that, good.
Isoch pipe made sense for USB full speed (12 Mb/s raw bit rate). A single CD
quality stream would take almost 20% of its throughput. You wanted to
reserve bandwidth in that conditions. With USB2 high speed, you're not
starved on bandwidth; on the other hand, high speed signalling is much more
picky about EMI, cable quality and routing on the mainboard (which really
kills high speed on some brands of MB). With USB2 you're better with bulk
pipes, with their guaranteed error-free delivery, rather than with
isochronous. Iso tops at 24 MB/s by design, but you don't need that much for
audio, anyway.

And regarding Steinberg. Ok, they know something about virtual studios on
Windows. But if they claim Windows requires special tuning for
responsiveness, they don't know something about Windows itself, namely how
to write reponsive code for it.


"greg1x" <greg1x@yahoo.com> wrote in message
news:eOXp2DChIHA.5280@TK2MSFTNGP02.phx.gbl...
> Mr. Grigoriev!
>
> With all of my respect to you, let me take some facts into your attention:
> - All USB Audio devices use isoch pipes, not bulk pipes (everyone knows
> here why)
> - Steinberg invented both VST and ASIO. They are the ones who know
> everything about virtual studios on Windows.
>
> Regards,
> Greg1X
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:uKjsAA$gIHA.4712@TK2MSFTNGP04.phx.gbl...
>> Use bulk pipe. You won't notice any hiccups. A single device on USB can
>> get up to 40 MB/s, which is way more than necessary for audio.
>> And no, bulk pipe does not increase latency. If you think otherwise, you
>> misunderstand USB protocol a bit.
>>
>> And properly written audio software doesn't require any XP tuning, sorry.
>> If Steinberg needs that, their programmers don't know something about
>> Windows.
>>
>> "greg1x" <greg1x@yahoo.com> wrote in message
>> news:OwwfzV0gIHA.1188@TK2MSFTNGP04.phx.gbl...
>>> Mr. Roberts!
>>>
>>>> The ANSWER is to put this into your knowledge base for support calls.
>>>> You
>>>> can't stop it, and even if you COULD ask all your clients to change
>>>> their
>>>> configurations for your device, it's going to be something different
>>>> the
>>>> next time.
>>>>
>>>> Isochronous pipes do not offer guaranteed delivery. End of story.
>>>
>>> I didn't mention yet, but this is is an audio-related real-time device
>>> used in virtual studios.
>>> Professional people using virtual studios (VST hosts, VSTis, ASIO,
>>> etc...) are known to maintain an XP installation dedicated to music
>>> production. They are setting up their music production XP for nothing
>>> else, but low latency error-free music production.
>>> They are setting up their production XPs depending on advises on
>>> http://www.musicxp.net and Steinberg.net:
>>> http://knowledgebase.steinberg.net/91_1.html (setting processor
>>> scheduling to background processes). There are plenty of fine-tuning
>>> modifications those musicians are performing on their XPs before using
>>> it for production.
>>> So, answers like use a bulk pipe and use error handling are useless for
>>> their situation as both of these "solutions" are significantly
>>> increasing latency.
>>>
>>> I'll have to tell them a new hint: Disable your WiFi card on your
>>> production XP.
>>> All I'm looking for here is a lighter hint than that. I would like to
>>> keep their network still working at production time. Something like:
>>> Turn off this, set that..
>>> Those people are very special ones and require special solutions without
>>> quality loss. Increasing latency is a huge quality loss.
>>>
>>> So, if anyone had a useful hint on that, I would be very thankful.
>>>
>>> Regards,
>>> Greg1X
>>>
>>
>>
>
>

greg1x
Thu Mar 13 02:51:22 CDT 2008

Mr. Grigoriev!

Please read my very first post in this thread.
I was writing there that it is a full speed device.
And again: Every USB audio device uses isoch pipes and I can't take your
negative comments seriously about Steinberg.
This conversation leads to nowhere as your comments are against pure facts.
If you're a WiFi specialist, please help me out with your advises.

Regards,
Greg1X

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:OqPvTOLhIHA.1164@TK2MSFTNGP02.phx.gbl...
> 1. If you use isoch pipe, you must accept possibility of packet loss. If
> you're OK with that, good.
> Isoch pipe made sense for USB full speed (12 Mb/s raw bit rate). A single
> CD quality stream would take almost 20% of its throughput. You wanted to
> reserve bandwidth in that conditions. With USB2 high speed, you're not
> starved on bandwidth; on the other hand, high speed signalling is much
> more picky about EMI, cable quality and routing on the mainboard (which
> really kills high speed on some brands of MB). With USB2 you're better
> with bulk pipes, with their guaranteed error-free delivery, rather than
> with isochronous. Iso tops at 24 MB/s by design, but you don't need that
> much for audio, anyway.
>
> And regarding Steinberg. Ok, they know something about virtual studios on
> Windows. But if they claim Windows requires special tuning for
> responsiveness, they don't know something about Windows itself, namely how
> to write reponsive code for it.
>
>
> "greg1x" <greg1x@yahoo.com> wrote in message
> news:eOXp2DChIHA.5280@TK2MSFTNGP02.phx.gbl...
>> Mr. Grigoriev!
>>
>> With all of my respect to you, let me take some facts into your
>> attention:
>> - All USB Audio devices use isoch pipes, not bulk pipes (everyone knows
>> here why)
>> - Steinberg invented both VST and ASIO. They are the ones who know
>> everything about virtual studios on Windows.
>>
>> Regards,
>> Greg1X
>>
>> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
>> news:uKjsAA$gIHA.4712@TK2MSFTNGP04.phx.gbl...
>>> Use bulk pipe. You won't notice any hiccups. A single device on USB can
>>> get up to 40 MB/s, which is way more than necessary for audio.
>>> And no, bulk pipe does not increase latency. If you think otherwise, you
>>> misunderstand USB protocol a bit.
>>>
>>> And properly written audio software doesn't require any XP tuning,
>>> sorry. If Steinberg needs that, their programmers don't know something
>>> about Windows.
>>>
>>> "greg1x" <greg1x@yahoo.com> wrote in message
>>> news:OwwfzV0gIHA.1188@TK2MSFTNGP04.phx.gbl...
>>>> Mr. Roberts!
>>>>
>>>>> The ANSWER is to put this into your knowledge base for support calls.
>>>>> You
>>>>> can't stop it, and even if you COULD ask all your clients to change
>>>>> their
>>>>> configurations for your device, it's going to be something different
>>>>> the
>>>>> next time.
>>>>>
>>>>> Isochronous pipes do not offer guaranteed delivery. End of story.
>>>>
>>>> I didn't mention yet, but this is is an audio-related real-time device
>>>> used in virtual studios.
>>>> Professional people using virtual studios (VST hosts, VSTis, ASIO,
>>>> etc...) are known to maintain an XP installation dedicated to music
>>>> production. They are setting up their music production XP for nothing
>>>> else, but low latency error-free music production.
>>>> They are setting up their production XPs depending on advises on
>>>> http://www.musicxp.net and Steinberg.net:
>>>> http://knowledgebase.steinberg.net/91_1.html (setting processor
>>>> scheduling to background processes). There are plenty of fine-tuning
>>>> modifications those musicians are performing on their XPs before using
>>>> it for production.
>>>> So, answers like use a bulk pipe and use error handling are useless for
>>>> their situation as both of these "solutions" are significantly
>>>> increasing latency.
>>>>
>>>> I'll have to tell them a new hint: Disable your WiFi card on your
>>>> production XP.
>>>> All I'm looking for here is a lighter hint than that. I would like to
>>>> keep their network still working at production time. Something like:
>>>> Turn off this, set that..
>>>> Those people are very special ones and require special solutions
>>>> without quality loss. Increasing latency is a huge quality loss.
>>>>
>>>> So, if anyone had a useful hint on that, I would be very thankful.
>>>>
>>>> Regards,
>>>> Greg1X
>>>>
>>>
>>>
>>
>>
>
>

Alexander
Thu Mar 13 09:52:19 CDT 2008

Unfortunately, the only good way to solve WiFi interference is to disable
WiFi. You don't want any wireless devices laying around during a recording
session, anyway, as they might interfere with analog circuits. Especially
GSM phones, known to cause those weird sounds in CiscoVOIP phones.

"greg1x" <greg1x@yahoo.com> wrote in message
news:%23bbUL8NhIHA.1132@TK2MSFTNGP06.phx.gbl...
> Mr. Grigoriev!
>
> Please read my very first post in this thread.
> I was writing there that it is a full speed device.
> And again: Every USB audio device uses isoch pipes and I can't take your
> negative comments seriously about Steinberg.
> This conversation leads to nowhere as your comments are against pure
> facts.
> If you're a WiFi specialist, please help me out with your advises.
>
> Regards,
> Greg1X
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:OqPvTOLhIHA.1164@TK2MSFTNGP02.phx.gbl...
>> 1. If you use isoch pipe, you must accept possibility of packet loss. If
>> you're OK with that, good.
>> Isoch pipe made sense for USB full speed (12 Mb/s raw bit rate). A single
>> CD quality stream would take almost 20% of its throughput. You wanted to
>> reserve bandwidth in that conditions. With USB2 high speed, you're not
>> starved on bandwidth; on the other hand, high speed signalling is much
>> more picky about EMI, cable quality and routing on the mainboard (which
>> really kills high speed on some brands of MB). With USB2 you're better
>> with bulk pipes, with their guaranteed error-free delivery, rather than
>> with isochronous. Iso tops at 24 MB/s by design, but you don't need that
>> much for audio, anyway.
>>
>> And regarding Steinberg. Ok, they know something about virtual studios on
>> Windows. But if they claim Windows requires special tuning for
>> responsiveness, they don't know something about Windows itself, namely
>> how to write reponsive code for it.
>>
>>
>> "greg1x" <greg1x@yahoo.com> wrote in message
>> news:eOXp2DChIHA.5280@TK2MSFTNGP02.phx.gbl...
>>> Mr. Grigoriev!
>>>
>>> With all of my respect to you, let me take some facts into your
>>> attention:
>>> - All USB Audio devices use isoch pipes, not bulk pipes (everyone knows
>>> here why)
>>> - Steinberg invented both VST and ASIO. They are the ones who know
>>> everything about virtual studios on Windows.
>>>
>>> Regards,
>>> Greg1X
>>>
>>> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
>>> news:uKjsAA$gIHA.4712@TK2MSFTNGP04.phx.gbl...
>>>> Use bulk pipe. You won't notice any hiccups. A single device on USB can
>>>> get up to 40 MB/s, which is way more than necessary for audio.
>>>> And no, bulk pipe does not increase latency. If you think otherwise,
>>>> you misunderstand USB protocol a bit.
>>>>
>>>> And properly written audio software doesn't require any XP tuning,
>>>> sorry. If Steinberg needs that, their programmers don't know something
>>>> about Windows.
>>>>
>>>> "greg1x" <greg1x@yahoo.com> wrote in message
>>>> news:OwwfzV0gIHA.1188@TK2MSFTNGP04.phx.gbl...
>>>>> Mr. Roberts!
>>>>>
>>>>>> The ANSWER is to put this into your knowledge base for support calls.
>>>>>> You
>>>>>> can't stop it, and even if you COULD ask all your clients to change
>>>>>> their
>>>>>> configurations for your device, it's going to be something different
>>>>>> the
>>>>>> next time.
>>>>>>
>>>>>> Isochronous pipes do not offer guaranteed delivery. End of story.
>>>>>
>>>>> I didn't mention yet, but this is is an audio-related real-time device
>>>>> used in virtual studios.
>>>>> Professional people using virtual studios (VST hosts, VSTis, ASIO,
>>>>> etc...) are known to maintain an XP installation dedicated to music
>>>>> production. They are setting up their music production XP for nothing
>>>>> else, but low latency error-free music production.
>>>>> They are setting up their production XPs depending on advises on
>>>>> http://www.musicxp.net and Steinberg.net:
>>>>> http://knowledgebase.steinberg.net/91_1.html (setting processor
>>>>> scheduling to background processes). There are plenty of fine-tuning
>>>>> modifications those musicians are performing on their XPs before using
>>>>> it for production.
>>>>> So, answers like use a bulk pipe and use error handling are useless
>>>>> for their situation as both of these "solutions" are significantly
>>>>> increasing latency.
>>>>>
>>>>> I'll have to tell them a new hint: Disable your WiFi card on your
>>>>> production XP.
>>>>> All I'm looking for here is a lighter hint than that. I would like to
>>>>> keep their network still working at production time. Something like:
>>>>> Turn off this, set that..
>>>>> Those people are very special ones and require special solutions
>>>>> without quality loss. Increasing latency is a huge quality loss.
>>>>>
>>>>> So, if anyone had a useful hint on that, I would be very thankful.
>>>>>
>>>>> Regards,
>>>>> Greg1X
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

m
Thu Mar 13 19:44:51 CDT 2008

<snip>
against pure facts.
<snip>

Yes, the _pure_ fact that other people seem not to have trouble writing
software for Windows, without any so called tuning, also called hacking,
that actually does manage to achieve data and transaction rates higher tha
any audio device yet invented ;)



Just call me cynical though.

Ron
Fri Mar 14 18:48:50 CDT 2008

Is that 40MB/s or 40 mb/s

MegaBytes or megabits

Thanks

-Ron-

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:uKjsAA$gIHA.4712@TK2MSFTNGP04.phx.gbl...
> Use bulk pipe. You won't notice any hiccups. A single device on USB can get
> up to 40 MB/s, which is way more than necessary for audio.
> And no, bulk pipe does not increase latency. If you think otherwise, you
> misunderstand USB protocol a bit.
>
> And properly written audio software doesn't require any XP tuning, sorry. If
> Steinberg needs that, their programmers don't know something about Windows.
>
> "greg1x" <greg1x@yahoo.com> wrote in message
> news:OwwfzV0gIHA.1188@TK2MSFTNGP04.phx.gbl...
> > Mr. Roberts!
> >
> >> The ANSWER is to put this into your knowledge base for support calls.
> >> You
> >> can't stop it, and even if you COULD ask all your clients to change their
> >> configurations for your device, it's going to be something different the
> >> next time.
> >>
> >> Isochronous pipes do not offer guaranteed delivery. End of story.
> >
> > I didn't mention yet, but this is is an audio-related real-time device
> > used in virtual studios.
> > Professional people using virtual studios (VST hosts, VSTis, ASIO, etc...)
> > are known to maintain an XP installation dedicated to music production.
> > They are setting up their music production XP for nothing else, but low
> > latency error-free music production.
> > They are setting up their production XPs depending on advises on
> > http://www.musicxp.net and Steinberg.net:
> > http://knowledgebase.steinberg.net/91_1.html (setting processor scheduling
> > to background processes). There are plenty of fine-tuning modifications
> > those musicians are performing on their XPs before using it for
> > production.
> > So, answers like use a bulk pipe and use error handling are useless for
> > their situation as both of these "solutions" are significantly increasing
> > latency.
> >
> > I'll have to tell them a new hint: Disable your WiFi card on your
> > production XP.
> > All I'm looking for here is a lighter hint than that. I would like to keep
> > their network still working at production time. Something like: Turn off
> > this, set that..
> > Those people are very special ones and require special solutions without
> > quality loss. Increasing latency is a huge quality loss.
> >
> > So, if anyone had a useful hint on that, I would be very thankful.
> >
> > Regards,
> > Greg1X
> >
>
>

Tim
Fri Mar 14 21:44:49 CDT 2008

"Ron" <.> wrote:
>
>Is that 40MB/s or 40 mb/s
>
>MegaBytes or megabits

MegaBYTES. A bulk pipe can sustain 40 megaBYTES per seconds.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Alexander
Fri Mar 14 23:45:53 CDT 2008

40 mega BYTES per second. That was used to pull live data from a CMOS camera
module, through Cypress USB interface.

"Ron" <.> wrote in message news:%23Ay503ihIHA.1164@TK2MSFTNGP02.phx.gbl...
> Is that 40MB/s or 40 mb/s
>
> MegaBytes or megabits
>
> Thanks
>
> -Ron-
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:uKjsAA$gIHA.4712@TK2MSFTNGP04.phx.gbl...
>> Use bulk pipe. You won't notice any hiccups. A single device on USB can
>> get
>> up to 40 MB/s, which is way more than necessary for audio.
>> And no, bulk pipe does not increase latency. If you think otherwise, you
>> misunderstand USB protocol a bit.
>>
>> And properly written audio software doesn't require any XP tuning, sorry.
>> If
>> Steinberg needs that, their programmers don't know something about
>> Windows.
>>
>> "greg1x" <greg1x@yahoo.com> wrote in message
>> news:OwwfzV0gIHA.1188@TK2MSFTNGP04.phx.gbl...
>> > Mr. Roberts!
>> >
>> >> The ANSWER is to put this into your knowledge base for support calls.
>> >> You
>> >> can't stop it, and even if you COULD ask all your clients to change
>> >> their
>> >> configurations for your device, it's going to be something different
>> >> the
>> >> next time.
>> >>
>> >> Isochronous pipes do not offer guaranteed delivery. End of story.
>> >
>> > I didn't mention yet, but this is is an audio-related real-time device
>> > used in virtual studios.
>> > Professional people using virtual studios (VST hosts, VSTis, ASIO,
>> > etc...)
>> > are known to maintain an XP installation dedicated to music production.
>> > They are setting up their music production XP for nothing else, but low
>> > latency error-free music production.
>> > They are setting up their production XPs depending on advises on
>> > http://www.musicxp.net and Steinberg.net:
>> > http://knowledgebase.steinberg.net/91_1.html (setting processor
>> > scheduling
>> > to background processes). There are plenty of fine-tuning modifications
>> > those musicians are performing on their XPs before using it for
>> > production.
>> > So, answers like use a bulk pipe and use error handling are useless for
>> > their situation as both of these "solutions" are significantly
>> > increasing
>> > latency.
>> >
>> > I'll have to tell them a new hint: Disable your WiFi card on your
>> > production XP.
>> > All I'm looking for here is a lighter hint than that. I would like to
>> > keep
>> > their network still working at production time. Something like: Turn
>> > off
>> > this, set that..
>> > Those people are very special ones and require special solutions
>> > without
>> > quality loss. Increasing latency is a huge quality loss.
>> >
>> > So, if anyone had a useful hint on that, I would be very thankful.
>> >
>> > Regards,
>> > Greg1X
>> >
>>
>>
>
>