Hi,
yes, i think that is the problem with 16 or 24bit. Today i tried a "no name" product and there is the same. :-(
yes, i think that is the problem with 16 or 24bit. Today i tried a "no name" product and there is the same. :-(
Lorien, I was talking about an open-source UAC2 ASIO driver.
The current version of that driver have been developed for and tested with another unrelated card, but both that card and the driver are trying to comply with the UAC2 standard. As XMOS is also supposed to do. Thus that driver (perhaps with some minor modifications) should eventually work also with XMOS.
If you're not interested in a possible alternative (and open-sourced) ASIO driver that may work for YOUR card, that's another story. But my post was well in-topic.
I must admit that when I look at the open-source driver there seems to be a lot of hardware involved. It seems like a competitor but perhaps I am missing something. If linux and mac support WaveIO and need no driver and windows has a driver that is freely available to end users, who might use that open-source driver with WaveIO?
The point UnixMan is making is that the software stack developed for that hardware could with some contributions be made to support other hardware that is also UAC2 compliant.
A driver that supports UAC2 and is not restricted to specific hardware is something that in my opinion should be valued by the microsoft users, your operating system vendor has not provided such a piece of software yet and seems to show no intention of doing so. I am not familiar with the particular license on the xmos driver but the choice being there is something I think would be terrific!
I have not read the xmos license but the fact is that the driver for windows comes with some terms of use, it is not free in the open source sense of the word. Though I understand that some of those freedoms that an open source user generally values is not always a high priority for a windows user.
My preference is always to chose freedom if I have a choice.
/end rant - I'm off to keep growing my beard/hair in a vain attempt to be more like rms or Papa.
A driver that supports UAC2 and is not restricted to specific hardware is something that in my opinion should be valued by the microsoft users, your operating system vendor has not provided such a piece of software yet and seems to show no intention of doing so. I am not familiar with the particular license on the xmos driver but the choice being there is something I think would be terrific!
I have not read the xmos license but the fact is that the driver for windows comes with some terms of use, it is not free in the open source sense of the word. Though I understand that some of those freedoms that an open source user generally values is not always a high priority for a windows user.
My preference is always to chose freedom if I have a choice.
/end rant - I'm off to keep growing my beard/hair in a vain attempt to be more like rms or Papa.
Last edited:
I appreciate Unixman's point. Windows is not my OS, I run XP, Linux, and Apple boxes at home. I love freedom. Sorry you felt you needed to rant
You have PM!
I check the XMOS site frequently though I didn't see any new releases. There was a problem related to DFU module on multichannel reference design though solved with their latest firmware but does not affect WaveIO since DFU is not used here.
I would be happy to keep problems at minimum
I already encounter few challenges with the revision (from the HW point of view...) so I do not need more Kind regards,
L
Last edited:
Sorry Lucien
I love uncovering, diagnosing, and fixing bugs almost as much as listening to music. I had the joy of sitting in a cubicle next to the most productive bug finder I ever met and diagnosing Linux 'insects'. Many were true instabilities resulting in machine checks and processor wedges so there were not even memory dumps to examine. My job was diagnosing those. He spotted and reported more than a thousand bugs in one distro for one vendor. Ah, the good old daze!
I love uncovering, diagnosing, and fixing bugs almost as much as listening to music. I had the joy of sitting in a cubicle next to the most productive bug finder I ever met and diagnosing Linux 'insects'. Many were true instabilities resulting in machine checks and processor wedges so there were not even memory dumps to examine. My job was diagnosing those. He spotted and reported more than a thousand bugs in one distro for one vendor. Ah, the good old daze!
Major clue
PNP is sending us a message here. An object that is being refreshed during this cycle either contains corrupted state or a side effect of initialization has refreshed state held elsewhere. It still might be difficult to root cause this but the ease of repeatability is extremely helpful.
PNP is sending us a message here. An object that is being refreshed during this cycle either contains corrupted state or a side effect of initialization has refreshed state held elsewhere. It still might be difficult to root cause this but the ease of repeatability is extremely helpful.
Similar corner case
I have a similar situation. Not to be construed in any way a problem with WaveIO as it relates to running in a highly modified XP build.
I run CMP/CPLAY on XP which has been slimmed down to the minimum so it runs like an appliance. Sound quality unbelieveable. Somewhere as I cut XP to the bone, 2 things start to happen. 1. I can no longer bring up the ASIO control panel. 2. After playing one cue sheet, exiting CPLAY, WaveIO is no longer functional. Turn off WaveIO and restart and it works fine. There must be something it needs to gracefully exit that I killed. I'll find it, but if anyone has suggestions, I'm all ears.
I have a similar situation. Not to be construed in any way a problem with WaveIO as it relates to running in a highly modified XP build.
I run CMP/CPLAY on XP which has been slimmed down to the minimum so it runs like an appliance. Sound quality unbelieveable. Somewhere as I cut XP to the bone, 2 things start to happen. 1. I can no longer bring up the ASIO control panel. 2. After playing one cue sheet, exiting CPLAY, WaveIO is no longer functional. Turn off WaveIO and restart and it works fine. There must be something it needs to gracefully exit that I killed. I'll find it, but if anyone has suggestions, I'm all ears.
Hi Wlowes,
First, I don't know why you're cutting that windows OS to the bone. If there's no crap installed, just a bare XP install it should run without any issues. I've been in the computer field for over 20 years, have seen the bads and the goods!
Unless your CPU is under powered or your ram is not enough and it is swapping, I can understand cutting down on the OS services. Otherwise, this will not give you better sound. You can give your program a higher thread priority if you think it will make a difference.
I just think you're wasting too much efforts on that side. Might as well just run a lean Linux distro instead.
Anyways, hope you find your answer!
Do
I agree 98% with that but . . . if that makes a difference then your machine would indeed be very slow. The culprit is the way interrupts are handled under the WinNT kernel. Prior to WinNT the code required to handle interrupts would run when the hardware handled the peripheral interrupt. If that code consumed too much time it could delay other time dependent processes so the Deferred Procedure Call (DPC) was used as part of the WinNT kernel. Properly written drivers, including all drivers for XMOS, respond ASAP to the interrupt but delay time consuming code to a procedure called later, hence the name DPC.
The code in that later procedure is the potential culprit. Most peripherals and their drivers require a sufficiently short amount of time to do the necessary work or they schedule another DPC. Some 3rd party products cause significant delays, i.e. their latency is high, and the buffers run dry causing short pauses in audio streams. Much greater detail on this is available in DPClat.pdf and a tool for measuring latencies on your computer, DPClat.exe, is available free from Thesycon.
All kernel and kernel device driver code runs at a higher priority than any application. The only way Microsoft could have eliminated the possibility of such long latencies would have been to restrict the peripherals that would be supported the way Apple and HA server vendors have.
Please apply the "yammy test" by unplugging and replugging USB and reporting results.