Hello,
I have designed a board around the XU216-512-TQ128 chip.
I started from a Dev Kit suppplied by a third party and with the kit I received also the Driver for Windows.
The firmware with the Dev Kit reports:
#define VENDOR_STR "xxx"
#define PRODUCT_STR_A1 "yyyyyyyyy"
#define PRODUCT_STR_A2 "yyyyyyyyy"
#define SERIAL_STR "" // default to empty serial number - a value can be loaded into the str table from the OTP at runtime
#define VENDOR_ID (0x1CBA) // Xmos VID so as to use the drivers installed with the Xmos tools
#define PID_AUDIO_2 (0x----)
#define PID_AUDIO_1 (0x----)
I prefer to hide the information about his third party.
I received my PID and the related driver a few days ago.
I introduced the PID received in the following way:
// #define VENDOR_STR "xxx"
// #define PRODUCT_STR_A1 "yyyyyyyyy"
// #define PRODUCT_STR_A2 "yyyyyyyyy"
// #define SERIAL_STR "" // default to empty serial number - a value can be loaded into the str table from the OTP at runtime
// #define VENDOR_ID (0x1CBA) // Xmos VID so as to use the drivers installed with the Xmos tools
#define PID_AUDIO_2 (0x30B3)
#define PID_AUDIO_1 (0x30B3)
I have installed the driver on a Win10 PC and the behaviour is strange:
1) Wasapi works 2) direct sound works 3) ASIO KO
I have installed the same driver on a Win7pro PC and the driver is signalled with a question mark and a yellow triangle in the device manager of the control panel of Win7pro and, of course, the board doesn't start.
If I flash the exactly the same board with the firmware used when the board was designed and I use the driver received with the Dev Kit of the third party everything is perfect.
Any suggestion?
USB Audio 2.0 Stereo Driver for Windows 10 Update
-
- Member++
- Posts: 16
- Joined: Sat Apr 08, 2017 6:19 pm
- Location: Venice ITA
-
- Member++
- Posts: 16
- Joined: Sat Apr 08, 2017 6:19 pm
- Location: Venice ITA
I uninstalled the driver of the third party before to install the driver with my PID.
The behaviour is exactly the same with the 3.34 driver too.
And 3.34 is the release of the driver of the third party too.
The behaviour is exactly the same with the 3.34 driver too.
And 3.34 is the release of the driver of the third party too.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hello. Believe the issue is...
1) Windows 10 now has native support for USB Audio 2.0 so this class of drivers are supported regardless of the VID / PID details.
2) Windows 7 still links the INF file to the VID / PID details. Also, if these IDs change then the .CAT file will be invalid. You will have to get the INF file signed with the IDs you have applied.
In the meantime, you can test by bypassing the signature check on Windows 7 to confirm:
https://www.raymond.cc/blog/loading-uns ... 4-bit-x64/
https://social.technet.microsoft.com/Fo ... rohardware
1) Windows 10 now has native support for USB Audio 2.0 so this class of drivers are supported regardless of the VID / PID details.
2) Windows 7 still links the INF file to the VID / PID details. Also, if these IDs change then the .CAT file will be invalid. You will have to get the INF file signed with the IDs you have applied.
In the meantime, you can test by bypassing the signature check on Windows 7 to confirm:
https://www.raymond.cc/blog/loading-uns ... 4-bit-x64/
https://social.technet.microsoft.com/Fo ... rohardware
-
- Member++
- Posts: 16
- Joined: Sat Apr 08, 2017 6:19 pm
- Location: Venice ITA
Hello,
I am not a Windows expert.
On the other hands I found a folder where the driver from the Dev Kit supplier was saved.
Inside it there is a vendor.cer and a setup.bmp.
After I have received the driver from XMOS with my PID, what have I to do?
Where can I find the vendor.cer and the setup.bmp fro "my" driver?
Do have I to collect them in a separated folder? its name? position?
If I don't understand bad the followign rows are not enough
// #define VENDOR_STR "xxx"
// #define PRODUCT_STR_A1 "yyyyyyyyy"
// #define PRODUCT_STR_A2 "yyyyyyyyy"
// #define SERIAL_STR "" // default to empty serial number - a value can be loaded into the str table from the OTP at runtime
// #define VENDOR_ID (0x1CBA) // Xmos VID so as to use the drivers installed with the Xmos tools
#define PID_AUDIO_2 (0x30B3)
#define PID_AUDIO_1 (0x30B3)
Thank you.
... at least now it is not a mystery why with a different driver the board works or doesn't work.
I am not a Windows expert.
On the other hands I found a folder where the driver from the Dev Kit supplier was saved.
Inside it there is a vendor.cer and a setup.bmp.
After I have received the driver from XMOS with my PID, what have I to do?
Where can I find the vendor.cer and the setup.bmp fro "my" driver?
Do have I to collect them in a separated folder? its name? position?
If I don't understand bad the followign rows are not enough
// #define VENDOR_STR "xxx"
// #define PRODUCT_STR_A1 "yyyyyyyyy"
// #define PRODUCT_STR_A2 "yyyyyyyyy"
// #define SERIAL_STR "" // default to empty serial number - a value can be loaded into the str table from the OTP at runtime
// #define VENDOR_ID (0x1CBA) // Xmos VID so as to use the drivers installed with the Xmos tools
#define PID_AUDIO_2 (0x30B3)
#define PID_AUDIO_1 (0x30B3)
Thank you.
... at least now it is not a mystery why with a different driver the board works or doesn't work.
-
- Member++
- Posts: 16
- Joined: Sat Apr 08, 2017 6:19 pm
- Location: Venice ITA
"You will have to get the INF file signed with the IDs you have applied"
can you explain better?
can you explain better?
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi. Here are some comments we believe to be accurate for your request. XMOS or someone else can probably expand on these topics.
We use a (paid) s/w company who is an expert on device driver development for our custom design on Windows.
1) You are using an USB device which is based on custom VID and / PID IDs. If these IDs are different than the supplied signed driver package from XMOS or whomever, then the driver package is technically now broken on at least Windows 7 and older.
2) Why? The reason the driver breaks is because you have changed the hardware IDs. Respectively, now you are required to make a copy of the linked INF file (is text / ASCII file) with your new IDs and perform a mix of Microsoft tests (believe it is HLK). These tests MUST pass and the test tool will create log files for submission to Microsoft. Sometimes these tests can take days to run without interruption. Only if you pass the test, then you must use your Microsoft account (free) and submit to Microsoft for their signature (we call this "for their blessings"). Before you can submit, you need your own kernel mode (device driver) signing certificate. That is a small pain in itself but must be done to validate your company details to show ownership and responsibility of this new driver submission. This certificate is not free and the pricing varies with the wind direction. The company driver vetting (approval) also takes some time and steps to be granted the certificate. Often you can buy a 1 year kernel mode signing certificate but sometimes it may make business sense to buy 3 year versions before they expire. Once you pass the testing AND sign with your certificate -> then upload to Microsoft for their review. Then they will also sign with the Microsoft signature. Upon return of these signed files, you will have a package of device drivers which will then load onto Windows 7 just fine.
BTW: The Microsoft test tool is a royal pain and demanding on which computer hardware which must be used to even keep testing without other issues. We invested over 2 weeks in the lab to stabilize the equipment and could not. In the end, we paid our device driver consultant company to build up the proper box for the "stable" testing. The test tool will mimic power up / down, plugging / unplugging, stress testing, etc. of your hardware. This was years ago. BTW, we supply Microsoft, HP, Dell and many other industry giants with our hardware. We do have many custom device drivers that must be supported so our case may be different than yours.
I know that we purchased a 1 year signing certificate last year for our products but note sure if it has yet expired. Also, once the process is complete, the signed drivers do not expire. Just a FYI.
Now on Windows 10, from our brief reading, you can use the CLASS CODE of the hardware to install the driver but on Windows 10 only. So for example, if your class code is for Audio devices, then Windows does not care if you are from another planet and with random IDs, the driver and hardware will install just fine. On older OS, the IDs must match. Not sure on Windows 8.x at this time but believe it is like Windows 7 and older.
So other examples are CDC = basic USB UART; HID = keyboard, mouse, etc. = are classes of widgets that will install without ID concerns.
Sometimes it makes sense to swallow some pride and use a known working package of IDs for initial testing of your hardware before moving to paid driver signing, etc. It can get expensive quickly and is very time consuming. Check around with google on this topic as we have seen more details on Microchip, FTDI, etc. on USB driver signing.
Also, consider to contact the same company used by XMOS for their audio driver development:
http://www.thesycon.de/eng/usbio.shtml#features
In closing and just common advice, do not support a company that does not raise your confidence on the level of support. We have seen far too many companies keen to sell expensive and broken tools and then ignore requests for even email support after the purchase.
After all of this, you must ask if it is worth to use IDs on your project. If you are not supplying custom device drivers with your hardware then the only benefit we can see is in the branding of the product. Consider to use the silicon vendor supplied signed drivers and use the same IDs as theirs to move forward.
Fairly sure the above details are correct and current but as noted, do continue to ask around for additional advice. Hope this helps.
====
Adding more (perhaps too much coffee this morning:)
Believe you will want this same driver that was promoted through XMOS:
http://www.thesycon.de/eng/usb_audiodriver.shtml
Email them with the details of your case -> they will want your IDs for your custom hardware and in return send you back a driver package that will be signed but time bombed since you have not yet paid them :)
This returned package should allow you to use your hardware with the customized IDs on Windows 7 or others without issues. Till the driver purposely crashes as it is a time limited demo.
Again, have to ask why you cannot just remain with the XMOS IDs for both the VID & PID on the USB gadget since in the end, you will use the USB Audio 2.0 driver for all of these Windows installations? It will be without cost and this is what most of the industry is doing -> just use the XMOS driver package.
We use a (paid) s/w company who is an expert on device driver development for our custom design on Windows.
1) You are using an USB device which is based on custom VID and / PID IDs. If these IDs are different than the supplied signed driver package from XMOS or whomever, then the driver package is technically now broken on at least Windows 7 and older.
2) Why? The reason the driver breaks is because you have changed the hardware IDs. Respectively, now you are required to make a copy of the linked INF file (is text / ASCII file) with your new IDs and perform a mix of Microsoft tests (believe it is HLK). These tests MUST pass and the test tool will create log files for submission to Microsoft. Sometimes these tests can take days to run without interruption. Only if you pass the test, then you must use your Microsoft account (free) and submit to Microsoft for their signature (we call this "for their blessings"). Before you can submit, you need your own kernel mode (device driver) signing certificate. That is a small pain in itself but must be done to validate your company details to show ownership and responsibility of this new driver submission. This certificate is not free and the pricing varies with the wind direction. The company driver vetting (approval) also takes some time and steps to be granted the certificate. Often you can buy a 1 year kernel mode signing certificate but sometimes it may make business sense to buy 3 year versions before they expire. Once you pass the testing AND sign with your certificate -> then upload to Microsoft for their review. Then they will also sign with the Microsoft signature. Upon return of these signed files, you will have a package of device drivers which will then load onto Windows 7 just fine.
BTW: The Microsoft test tool is a royal pain and demanding on which computer hardware which must be used to even keep testing without other issues. We invested over 2 weeks in the lab to stabilize the equipment and could not. In the end, we paid our device driver consultant company to build up the proper box for the "stable" testing. The test tool will mimic power up / down, plugging / unplugging, stress testing, etc. of your hardware. This was years ago. BTW, we supply Microsoft, HP, Dell and many other industry giants with our hardware. We do have many custom device drivers that must be supported so our case may be different than yours.
I know that we purchased a 1 year signing certificate last year for our products but note sure if it has yet expired. Also, once the process is complete, the signed drivers do not expire. Just a FYI.
Now on Windows 10, from our brief reading, you can use the CLASS CODE of the hardware to install the driver but on Windows 10 only. So for example, if your class code is for Audio devices, then Windows does not care if you are from another planet and with random IDs, the driver and hardware will install just fine. On older OS, the IDs must match. Not sure on Windows 8.x at this time but believe it is like Windows 7 and older.
So other examples are CDC = basic USB UART; HID = keyboard, mouse, etc. = are classes of widgets that will install without ID concerns.
Sometimes it makes sense to swallow some pride and use a known working package of IDs for initial testing of your hardware before moving to paid driver signing, etc. It can get expensive quickly and is very time consuming. Check around with google on this topic as we have seen more details on Microchip, FTDI, etc. on USB driver signing.
Also, consider to contact the same company used by XMOS for their audio driver development:
http://www.thesycon.de/eng/usbio.shtml#features
In closing and just common advice, do not support a company that does not raise your confidence on the level of support. We have seen far too many companies keen to sell expensive and broken tools and then ignore requests for even email support after the purchase.
After all of this, you must ask if it is worth to use IDs on your project. If you are not supplying custom device drivers with your hardware then the only benefit we can see is in the branding of the product. Consider to use the silicon vendor supplied signed drivers and use the same IDs as theirs to move forward.
Fairly sure the above details are correct and current but as noted, do continue to ask around for additional advice. Hope this helps.
====
Adding more (perhaps too much coffee this morning:)
Believe you will want this same driver that was promoted through XMOS:
http://www.thesycon.de/eng/usb_audiodriver.shtml
Email them with the details of your case -> they will want your IDs for your custom hardware and in return send you back a driver package that will be signed but time bombed since you have not yet paid them :)
This returned package should allow you to use your hardware with the customized IDs on Windows 7 or others without issues. Till the driver purposely crashes as it is a time limited demo.
Again, have to ask why you cannot just remain with the XMOS IDs for both the VID & PID on the USB gadget since in the end, you will use the USB Audio 2.0 driver for all of these Windows installations? It will be without cost and this is what most of the industry is doing -> just use the XMOS driver package.
-
- Member++
- Posts: 16
- Joined: Sat Apr 08, 2017 6:19 pm
- Location: Venice ITA
thank you for the explanation.
I haven't used the XMOS IDs for both the VID & PID because I don't know if I can.
What are the XMOS IDs?
At the moment I am using the VID & PID of the third party is supplying its dev kit.
I would like to use mine. But this is not important.
I have only to use the driver from XMOS without the beep every minute.
I haven't used the XMOS IDs for both the VID & PID because I don't know if I can.
What are the XMOS IDs?
At the moment I am using the VID & PID of the third party is supplying its dev kit.
I would like to use mine. But this is not important.
I have only to use the driver from XMOS without the beep every minute.
-
- XCore Addict
- Posts: 185
- Joined: Tue Mar 26, 2013 12:10 pm
Hi Revenac,
Full details of how to get our production driver (and associated PID) are available here : https://www.xmos.com/support/usb-audio-driver-support.
All the best,
John
Full details of how to get our production driver (and associated PID) are available here : https://www.xmos.com/support/usb-audio-driver-support.
All the best,
John
-
- Member++
- Posts: 16
- Joined: Sat Apr 08, 2017 6:19 pm
- Location: Venice ITA
Hello,
I followed all the instructions, suggestions and information found about the "how to install the XMOS driver".
The USB interface designed works perfectly with the driver supplied by MQA Ltd., of course I specify the PID and VID of MQA Ltd.
Everything is fine, works well on Windows 10, 8, 7, XP ... and of course MAC OSX or Ubuntu.
The USB interface is installed on a Digital Analog Converter for the consumer market, so the user will use Mac OSX, Ubuntu or Windows, and Windows will be mainly 10, 8 or 7 but I cannot exclude somebody will use Vista or XP.
The user is in almost in all the cases without any skill with the computer, the operating system and similar.
I must use my PID when I sell my product. The matter is the license.
I changed PID and VID on the firmware in Xtime Composer using mine (gave me from XMOS).
#define VENDOR_STR "CanEver Audio"
#define PRODUCT_STR_A1 "ZeroUno DAC"
#define PRODUCT_STR_A2 "ZeroUno DAC"
#define SERIAL_STR ""
#define VENDOR_ID (0x20B1
#define PID_AUDIO_2 (0x30B3)
#define PID_AUDIO_1 (0x30B3)
I say again the interface works perfectly with the driver with the MQA codes.
When I install the XMOS driver with my PID:
Win 10 Pro PC - everything works fine. The USB interface is totally integratyed.
Win 7 Ult 32bit PC - the driver installs regularly, but the USB interface is not seen. In the control panel - device manager - the message is "the device cannot start"
Win 7 Ult 64bit PC - the driver is refuised since the beginning because Win 7 wants "a digitally signed driver is needed"
To solve the matter of the digitally signed software I know how to do, but the users are not familiar with the PC and NEVER they will manage the Windows register by RegEdit or similar.
But to solve the matter about "the device cannot start" really I don't know how to do.
Cause the USB interface works well with the MQA driver I think the problem is the XMOS driver and >>>> how I declare in XTime Composer <<<<.
After all the efforts done I have to stop the launch of the new USB interface cause the XMOS driver.
I need an help.
I followed all the instructions, suggestions and information found about the "how to install the XMOS driver".
The USB interface designed works perfectly with the driver supplied by MQA Ltd., of course I specify the PID and VID of MQA Ltd.
Everything is fine, works well on Windows 10, 8, 7, XP ... and of course MAC OSX or Ubuntu.
The USB interface is installed on a Digital Analog Converter for the consumer market, so the user will use Mac OSX, Ubuntu or Windows, and Windows will be mainly 10, 8 or 7 but I cannot exclude somebody will use Vista or XP.
The user is in almost in all the cases without any skill with the computer, the operating system and similar.
I must use my PID when I sell my product. The matter is the license.
I changed PID and VID on the firmware in Xtime Composer using mine (gave me from XMOS).
#define VENDOR_STR "CanEver Audio"
#define PRODUCT_STR_A1 "ZeroUno DAC"
#define PRODUCT_STR_A2 "ZeroUno DAC"
#define SERIAL_STR ""
#define VENDOR_ID (0x20B1
#define PID_AUDIO_2 (0x30B3)
#define PID_AUDIO_1 (0x30B3)
I say again the interface works perfectly with the driver with the MQA codes.
When I install the XMOS driver with my PID:
Win 10 Pro PC - everything works fine. The USB interface is totally integratyed.
Win 7 Ult 32bit PC - the driver installs regularly, but the USB interface is not seen. In the control panel - device manager - the message is "the device cannot start"
Win 7 Ult 64bit PC - the driver is refuised since the beginning because Win 7 wants "a digitally signed driver is needed"
To solve the matter of the digitally signed software I know how to do, but the users are not familiar with the PC and NEVER they will manage the Windows register by RegEdit or similar.
But to solve the matter about "the device cannot start" really I don't know how to do.
Cause the USB interface works well with the MQA driver I think the problem is the XMOS driver and >>>> how I declare in XTime Composer <<<<.
After all the efforts done I have to stop the launch of the new USB interface cause the XMOS driver.
I need an help.
-
- Respected Member
- Posts: 275
- Joined: Fri Mar 12, 2010 6:03 pm
Could you try 4.13.0 please?