I already put the question in section Q&A, but maybe I should put it on “technical discussion section” and give some more information about my problem.
Just got new Metrum acoustics DAC - Pavane. When I switched off my mac or it goes to sleep mode and then I turn it on, “M2Tech hiFaceTwo” is no more visible in Mac sound preferences. I downgraded from El Capitan to Yosemite as Metrum acoustics team suggested me in first place, but nothing changed. Mac mini does not recognise “M2Tech hiFaceTwo”.
In further communication Metrum acoustics team explain to me that:
“this is typical for Xmos chips, that they have a sleeping mode and in a case there is no music playing for long time the Xmos go into sleep mode and resetting is only possible by switching “off” the Pavane and to “on” again. But in a normal situation that both computer and Pavane is starting up and you start listening this situation cannot happen. An exception is the sleeping mode of your computer which can give problems and should be switched off.”
And actually this is really the only way (!?) that “M2Tech hiFaceTwo” become visible to the computer operating system - only in that case “M2Tech hiFaceTwo” then appeared in mac mini audio devices and I can set (and save) it as audio output. But this is unpractical and almost unacceptable method? For example, in case of my previously DAC’s I used to turned off & on computer but DAC’s were always on so they were immediately ready for peak performance. In case of hi-end Pavane this scenario isn't practical.
As I already said, more logical to me it would be, If you shut off the computer, the next time you start it up, the XMOS chip (in its' own sleep mode) receives the 5V charge and should be reset to connect and become visible to the computer operating system. The System audio Preferences then recognises the DAC and all is well. But not in my case?
Do you think this is really typical for XMOS chips, and the most important question - is turning “off” and turning “on” DAC really only way to solve problem?
How to get XMOS chip out of sleeping mode
-
- Junior Member
- Posts: 6
- Joined: Fri Mar 25, 2016 2:21 pm
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Not sure if this dialog will help your case but certainly interested to learn more about what you are facing. We are in the design phase of a list of USB products..
Once the MAC goes to sleep -> so does your XMOS based audio widget. You are fine to wake up your MAC but the XMOS widget is no longer present ? Is this accurate ?
So how exactly do you get the XMOS audio device which is asleep to be detected (enumerated) again ? By unplugging the dongle / USB cable attached to this audio device ?
Not to step on any toes here but from our low level understanding, the USB protocol is based on software present inside the XMOS design. Respectively there is a software handshake that places the external widget to enter sleep mode to conserve the power drain of your battery (if you are not AC powered). Likewise another similar event should tickle the same widget to exit this sleep or deep sleep mode and allow for the use of the product once again. If you are not seeing this then there is some disconnect in the configuration of the software, perhaps the OS you are using and yes possibly the implementation of the XMOS software. Once approach you may be able to take to validate whether the XMOS code is the issue is to test on a PC and allow for the same scenario - allow the PC to go to sleep and then wake it up and see if the widget comes back to life.
Is your observation common with other users of this audio device ? (others are noting the same issue ?)
If we recall correctly from past readings, once the widget enters sleep mode, the gadget is obligated to consume very little current (power) and only enough as to not lose any vital settings / configuration data. Once the host PC wishes to wake up the device, the external device then is required to power up again all required circuits to operate as normal. If the external device loses complete power then that could be an issue (unless your device is self powered with an AC adapter - do you have an external power supply for your audio device ?).
Once the MAC goes to sleep -> so does your XMOS based audio widget. You are fine to wake up your MAC but the XMOS widget is no longer present ? Is this accurate ?
So how exactly do you get the XMOS audio device which is asleep to be detected (enumerated) again ? By unplugging the dongle / USB cable attached to this audio device ?
Not to step on any toes here but from our low level understanding, the USB protocol is based on software present inside the XMOS design. Respectively there is a software handshake that places the external widget to enter sleep mode to conserve the power drain of your battery (if you are not AC powered). Likewise another similar event should tickle the same widget to exit this sleep or deep sleep mode and allow for the use of the product once again. If you are not seeing this then there is some disconnect in the configuration of the software, perhaps the OS you are using and yes possibly the implementation of the XMOS software. Once approach you may be able to take to validate whether the XMOS code is the issue is to test on a PC and allow for the same scenario - allow the PC to go to sleep and then wake it up and see if the widget comes back to life.
Is your observation common with other users of this audio device ? (others are noting the same issue ?)
If we recall correctly from past readings, once the widget enters sleep mode, the gadget is obligated to consume very little current (power) and only enough as to not lose any vital settings / configuration data. Once the host PC wishes to wake up the device, the external device then is required to power up again all required circuits to operate as normal. If the external device loses complete power then that could be an issue (unless your device is self powered with an AC adapter - do you have an external power supply for your audio device ?).
-
- Junior Member
- Posts: 6
- Joined: Fri Mar 25, 2016 2:21 pm
Not sure if this dialog will help your case but certainly interested to learn more about what you are facing. We are in the design phase of a list of USB products..
Once the MAC goes to sleep -> so does your XMOS based audio widget. You are fine to wake up your MAC but the XMOS widget is no longer present ? Is this accurate?
Yes.
We are talking about internally powered “m2Tech OEM module with XMOS interface”, and this module / board in integrated in DAC (see picture attached - the XMOS USB module is clearly visible ), so this “XMOS USB device” is not powered by mac mini but is powered by DAC.
So how exactly do you get the XMOS audio device which is asleep to be detected (enumerated) again? By unplugging the dongle / USB cable attached to this audio device?
Unplugging and again plugging USB cable does not help. Only thing that can “wake up” XMOS is switching “off” and then again switching “on” the DAC.
Not to step on any toes here but from our low-level understanding, the USB protocol is based on software present inside the XMOS design. Respectively a software handshake places the external widget to enter sleep mode to conserve the power drain of your battery (if you are not AC powered).
DAC and XMOS USB device/board which is integrated in the DAC are not battery powered.
Likewise, another similar event should tickle the same widget to exit this sleep or deep sleep mode and allow for the use of the product once again. If you are not seeing this then there is some disconnect in the configuration of the software, perhaps the OS you are using and yes possibly the implementation of the XMOS software.
I downgraded to Yosemite as company which sale that DAC’s suggested, but nothing changed.
They also said they are using the latest “M2Tech” firmware but this cannot bypass the internal Xmos sleeping mode as they said.
People from forums says, “it is likely an issue that M2Tech needs to address in their code for their XMOS implementation.” However, I do not understand what these things (code?) mean. I just think that very expensive DAC-s (which have integrated “XMOS USB device”) should simply work.
Once approach you may be able to take to validate whether the XMOS code is the issue is to test on a PC and allow for the same scenario - allow the PC to go to sleep and then wake it up and see if the widget comes back to life.
Switching off and on mac mini or allowing mac mini to go to sleep…doesn’t “wake up” “XMOS USB device” in DAC. (Switching off or sleep mode of the mac mini actually causes that “XMOS USB device” lost connection as described before)
Is your observation common with other users of this audio device? (others are noting the same issue ?)
I have only four opinions from forum:
1. “I don’t think that this behavior you have is typical for Xmos chips. Xmos chips are very common and I have never heard of this type of problem before. I also agree with your logic.”
2. “I have the same issue with this DAC Pavane and a Macbook Air. The OS level on the Mac makes no difference; the behaviour is exactly the same. You have to avoid the Mac going to sleep while plugged into an active DAC Pavane.”
3. “It is not an XMOS issue. Likely a issue that M2Tech needs to address in their code for their XMOS implementation.”
4. “Note that the USB3 board Metrum use is an OEM-version of an M2Tech board, so I think Metrum will have to request a code change from M2Tech; so it could be a while before it shows up in actual units.”
And instructions from official DAC Metrum acoustic company / seller:
1. Typical for Xmos chips is that they have a sleeping mode as well so in a case that no music is playing for long time the Xmos go into sleep mode and resetting is only possible by switching off the Pavane and to on again. But in a normal situation that both computer and Pavane is starting up and you start listening this situation cannot happen. An exception is the sleeping mode of your computer which can give problems and should be switched off. For your information the Xmos chip is powered internal by the Pavane. Next you should avoid that other audio devices are available for the OS like the internal audio chip
If we recall correctly from past readings, once the widget enters sleep mode, the gadget is obligated to consume very little current (power) and only enough as to not lose any vital settings / configuration data. Once the host PC wishes to wake up the device, the external device then is required to power up again all required circuits to operate as normal. If the external device loses complete power then that could be an issue (unless your device is self-powered with an AC adapter - do you have an external power supply for your audio device?).
DAC is self-powered. “XMOS USB device/board” which is integrated in DAC is powered by DAC. Everything is under electricity, but “XMOS USB device/board” immediately lost connection with mac mini, when mac mini is switched off or it goes to sleep mode. And only switching off and switching on the DAC helps to “wake up” the “XMOS USB device, so the interface of that device show up in mac mini audio preferences, where I can then selected it as an audio output
I'm giving one example where there may be a similar case - link
Once the MAC goes to sleep -> so does your XMOS based audio widget. You are fine to wake up your MAC but the XMOS widget is no longer present ? Is this accurate?
Yes.
We are talking about internally powered “m2Tech OEM module with XMOS interface”, and this module / board in integrated in DAC (see picture attached - the XMOS USB module is clearly visible ), so this “XMOS USB device” is not powered by mac mini but is powered by DAC.
So how exactly do you get the XMOS audio device which is asleep to be detected (enumerated) again? By unplugging the dongle / USB cable attached to this audio device?
Unplugging and again plugging USB cable does not help. Only thing that can “wake up” XMOS is switching “off” and then again switching “on” the DAC.
Not to step on any toes here but from our low-level understanding, the USB protocol is based on software present inside the XMOS design. Respectively a software handshake places the external widget to enter sleep mode to conserve the power drain of your battery (if you are not AC powered).
DAC and XMOS USB device/board which is integrated in the DAC are not battery powered.
Likewise, another similar event should tickle the same widget to exit this sleep or deep sleep mode and allow for the use of the product once again. If you are not seeing this then there is some disconnect in the configuration of the software, perhaps the OS you are using and yes possibly the implementation of the XMOS software.
I downgraded to Yosemite as company which sale that DAC’s suggested, but nothing changed.
They also said they are using the latest “M2Tech” firmware but this cannot bypass the internal Xmos sleeping mode as they said.
People from forums says, “it is likely an issue that M2Tech needs to address in their code for their XMOS implementation.” However, I do not understand what these things (code?) mean. I just think that very expensive DAC-s (which have integrated “XMOS USB device”) should simply work.
Once approach you may be able to take to validate whether the XMOS code is the issue is to test on a PC and allow for the same scenario - allow the PC to go to sleep and then wake it up and see if the widget comes back to life.
Switching off and on mac mini or allowing mac mini to go to sleep…doesn’t “wake up” “XMOS USB device” in DAC. (Switching off or sleep mode of the mac mini actually causes that “XMOS USB device” lost connection as described before)
Is your observation common with other users of this audio device? (others are noting the same issue ?)
I have only four opinions from forum:
1. “I don’t think that this behavior you have is typical for Xmos chips. Xmos chips are very common and I have never heard of this type of problem before. I also agree with your logic.”
2. “I have the same issue with this DAC Pavane and a Macbook Air. The OS level on the Mac makes no difference; the behaviour is exactly the same. You have to avoid the Mac going to sleep while plugged into an active DAC Pavane.”
3. “It is not an XMOS issue. Likely a issue that M2Tech needs to address in their code for their XMOS implementation.”
4. “Note that the USB3 board Metrum use is an OEM-version of an M2Tech board, so I think Metrum will have to request a code change from M2Tech; so it could be a while before it shows up in actual units.”
And instructions from official DAC Metrum acoustic company / seller:
1. Typical for Xmos chips is that they have a sleeping mode as well so in a case that no music is playing for long time the Xmos go into sleep mode and resetting is only possible by switching off the Pavane and to on again. But in a normal situation that both computer and Pavane is starting up and you start listening this situation cannot happen. An exception is the sleeping mode of your computer which can give problems and should be switched off. For your information the Xmos chip is powered internal by the Pavane. Next you should avoid that other audio devices are available for the OS like the internal audio chip
If we recall correctly from past readings, once the widget enters sleep mode, the gadget is obligated to consume very little current (power) and only enough as to not lose any vital settings / configuration data. Once the host PC wishes to wake up the device, the external device then is required to power up again all required circuits to operate as normal. If the external device loses complete power then that could be an issue (unless your device is self-powered with an AC adapter - do you have an external power supply for your audio device?).
DAC is self-powered. “XMOS USB device/board” which is integrated in DAC is powered by DAC. Everything is under electricity, but “XMOS USB device/board” immediately lost connection with mac mini, when mac mini is switched off or it goes to sleep mode. And only switching off and switching on the DAC helps to “wake up” the “XMOS USB device, so the interface of that device show up in mac mini audio preferences, where I can then selected it as an audio output
I'm giving one example where there may be a similar case - link
You do not have the required permissions to view the files attached to this post.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Interesting. Agree that if the external device is self-powered as is the case for your audio device (ie. local AC power supply for the audio design) then there are no savings to allow this audio device to enter sleep mode. The sleep mode is to save on the power that is being drawn from the host PC. In your case, there is no benefit to enter sleep mode.
The obvious work around is to not allow your PC (MAC) to enter the sleep mode. Clunky but should work.
Once you wake up the PC, can you attach another USB device onto the same port as used by the audio unit ? For example, any USB thumb drive, etc. - does that freshly attached device get enumerated and is found by your Apple OS ? If yes then really cannot blame the OS since the OS is properly enumerating a docked product.
This takes the fault back to the audio unit which once the unit enters sleep mode, it cannot wake up till cold reset / power cycled. Not sure on how much customization M2Tech would have applied on this XMOS reference design but something sounds to be broken in the code. The XMOS device is a chip with multiple processors ('logical' = look like separate computers on a single chip). The USB interface is a program running on this component. Respectively, it is the responsibility of the program that is stored on the module you show in your photo to read / write USB commands to / from the host PC. Going to sleep is one of the commands to conserve energy. Respectively another command or event should allow the program to wake up the unit properly. For some reason, this stage of the code appears to be broken either by the manufacturer of this module or perhaps from the original XMOS reference design. Again, no idea of who is supplying whom but let us ask around. Being software driven (on the external XMOS design), it should be possible to reflash the module to correct the fault (assuming that is where the fault lies).
Be sure that your USB cables are of quality (not meaning you need to source $20 - $30 cables) but as designers, we have seen a lot of junk being shipped from offshore companies. It is vital that you have the proper wiring on the cable. If possible, try to test with at least another fresh cable (different make will be ideal). Not sure where you are located but you can try a 'brand name' like Belkin, etc. - perhaps even through Digikey. Best if you can return after testing if you do not require the spare cable.
Any chance you are aware of a 'low cost' audio product that displays this same quirk ? Openly we do not wish to purchase such an expensive widget but really interested to learn what is the root cause of this fault. We have some very nice USB analyzers in the building that should offer some clues of the issue but do not wish to invest too much on this audio line. For now, that is not on our product roadmap with XMOS devices. We see some XMOS audio modules on Aliexpress, etc. - would you know if they have this same quirk ? We can certainly order one of those to experiment against our Apple computers in the lab.
The obvious work around is to not allow your PC (MAC) to enter the sleep mode. Clunky but should work.
Once you wake up the PC, can you attach another USB device onto the same port as used by the audio unit ? For example, any USB thumb drive, etc. - does that freshly attached device get enumerated and is found by your Apple OS ? If yes then really cannot blame the OS since the OS is properly enumerating a docked product.
This takes the fault back to the audio unit which once the unit enters sleep mode, it cannot wake up till cold reset / power cycled. Not sure on how much customization M2Tech would have applied on this XMOS reference design but something sounds to be broken in the code. The XMOS device is a chip with multiple processors ('logical' = look like separate computers on a single chip). The USB interface is a program running on this component. Respectively, it is the responsibility of the program that is stored on the module you show in your photo to read / write USB commands to / from the host PC. Going to sleep is one of the commands to conserve energy. Respectively another command or event should allow the program to wake up the unit properly. For some reason, this stage of the code appears to be broken either by the manufacturer of this module or perhaps from the original XMOS reference design. Again, no idea of who is supplying whom but let us ask around. Being software driven (on the external XMOS design), it should be possible to reflash the module to correct the fault (assuming that is where the fault lies).
Be sure that your USB cables are of quality (not meaning you need to source $20 - $30 cables) but as designers, we have seen a lot of junk being shipped from offshore companies. It is vital that you have the proper wiring on the cable. If possible, try to test with at least another fresh cable (different make will be ideal). Not sure where you are located but you can try a 'brand name' like Belkin, etc. - perhaps even through Digikey. Best if you can return after testing if you do not require the spare cable.
Any chance you are aware of a 'low cost' audio product that displays this same quirk ? Openly we do not wish to purchase such an expensive widget but really interested to learn what is the root cause of this fault. We have some very nice USB analyzers in the building that should offer some clues of the issue but do not wish to invest too much on this audio line. For now, that is not on our product roadmap with XMOS devices. We see some XMOS audio modules on Aliexpress, etc. - would you know if they have this same quirk ? We can certainly order one of those to experiment against our Apple computers in the lab.
-
Verified
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Hello Mac20,
The XMOS chip that you see is a programmable micro-controller. So its function depends on the program (the firmware) that is loaded into it. The firmware is stored in a flash-chip, at a guess that may be labelled 'IC4' on the picture.
The firmware in that flash chip can make the XMOS chip do different things. In your case, the people who developed the module will have programmed the flash chip with firmware that implements USB-AUDIO. None of the USB functionality is hard-coded in the XMOS device; it is the firmware that makes the XMOS device into a USB-AUDIO device. With different firmware, the XMOS device could implement an LCD controller, a heating-thermostat, or something else that is unrelated to USB/Audio.
So the problem that you observe could be one of the following:
(a) a problem with the firmware that the module manufacturer has put in the flash device
(b) a problem with how the XMOS chip is integrated into the module design
(c) a problem with some other part of the module design
If the problem is (a), and if the module manufacturer has fixed it in a new version of the firmware, and the module manufacturer has enabled Firmware Upgrade (through, for example, DFU) then you can upgrade the firmware.
The XMOS chip that you see is a programmable micro-controller. So its function depends on the program (the firmware) that is loaded into it. The firmware is stored in a flash-chip, at a guess that may be labelled 'IC4' on the picture.
The firmware in that flash chip can make the XMOS chip do different things. In your case, the people who developed the module will have programmed the flash chip with firmware that implements USB-AUDIO. None of the USB functionality is hard-coded in the XMOS device; it is the firmware that makes the XMOS device into a USB-AUDIO device. With different firmware, the XMOS device could implement an LCD controller, a heating-thermostat, or something else that is unrelated to USB/Audio.
So the problem that you observe could be one of the following:
(a) a problem with the firmware that the module manufacturer has put in the flash device
(b) a problem with how the XMOS chip is integrated into the module design
(c) a problem with some other part of the module design
If the problem is (a), and if the module manufacturer has fixed it in a new version of the firmware, and the module manufacturer has enabled Firmware Upgrade (through, for example, DFU) then you can upgrade the firmware.
-
- Junior Member
- Posts: 6
- Joined: Fri Mar 25, 2016 2:21 pm
I only know, the USB3 board my “Metrum acoustic Pavane” use is an OEM-version of an “M2Tech” board. (it is shown as a “hiFaceTWO UAC2” in mac mini audio preferences).
I already asked manufacturer who produces these “Metrum acoustic Pavane” audio devices, if this “M2Tech / hiFaceTWO” firmware have to be somehow upgraded.
They answered me:
“we are using the latest firmware, but this cannot bypass the internal XMOS sleeping mode”
I already asked manufacturer who produces these “Metrum acoustic Pavane” audio devices, if this “M2Tech / hiFaceTWO” firmware have to be somehow upgraded.
They answered me:
“we are using the latest firmware, but this cannot bypass the internal XMOS sleeping mode”
-
Verified
- XCore Legend
- Posts: 1150
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
I'm afraid the information that your manufacturer is giving you is completely false. There is no sleep code that kicks in after "no music playing for a long time" in the code at all (I should know, I wrote it...)
The XMOS reference boards are fully capable of supporting USB suspend etc.
The XMOS reference boards are fully capable of supporting USB suspend etc.
-
- Junior Member
- Posts: 6
- Joined: Fri Mar 25, 2016 2:21 pm
I talked again to DAC manufacturer (who is integrating M2Tech Xmos based USB board in the DAC) and first I got the similar information:
“Normally in case of cheaper DAC models the power is coming from the PC and if present the Xmos will start. Now in case of our DAC's having its own linear power supply it do not notice the start of the computer and stays in sleep mode. As we order hundreds of Xmos modules from M2tech every month we have influence on the internal firmware however M2tech has no influence on the hardware made by Xmos. The only solution is switching of the DAC for one second. The result of this that power is removed from the USB so it will reset. We know recording studios having exactly the same problems with their mixing consoles but also a huge manufacturer like Meridian.”
After that, I really had to tell them about your opinions, and I got an answer:
“We will contact M2tech by mail and ask them to reply to me. However, we know that the device as it is programmed now has many functions and therefore chosen by us. But we have to wait for their reply first and let you know when answers are coming back.”
Well it would be interesting to see if there will be the answer form M2Tech. At this point, I would like to thank for sharing technical / expert information with me. Finally yet importantly, it is also going in one side, about consumer awareness and in the other side, about fair play between different manufacturers or producers.
Kind regrades
“Normally in case of cheaper DAC models the power is coming from the PC and if present the Xmos will start. Now in case of our DAC's having its own linear power supply it do not notice the start of the computer and stays in sleep mode. As we order hundreds of Xmos modules from M2tech every month we have influence on the internal firmware however M2tech has no influence on the hardware made by Xmos. The only solution is switching of the DAC for one second. The result of this that power is removed from the USB so it will reset. We know recording studios having exactly the same problems with their mixing consoles but also a huge manufacturer like Meridian.”
After that, I really had to tell them about your opinions, and I got an answer:
“We will contact M2tech by mail and ask them to reply to me. However, we know that the device as it is programmed now has many functions and therefore chosen by us. But we have to wait for their reply first and let you know when answers are coming back.”
Well it would be interesting to see if there will be the answer form M2Tech. At this point, I would like to thank for sharing technical / expert information with me. Finally yet importantly, it is also going in one side, about consumer awareness and in the other side, about fair play between different manufacturers or producers.
Kind regrades
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Mac20 - would you forward your comments on the below ?
1) Power down your MAC. Remove the audio USB device after the computer is powered off.
2) Leave the USB device disconnected and power the MAC up again.
3) After reaching your desktop / OS boot, insert the USB cable for your Audio widget. Does the external USB Audio device get detected ? Are you able to use this external USB device ok ?
4) Remove the Audio USB cable once again and repeat to confirm if the USB device is removed and then detected (enumerated) by the host OS. The attach / removal of the USB device should allow the OS to detect the same conditions of this external device.
5) Allow the MAC to enter suspend / sleep mode. Remove the USB cable once again -> allow the MAC to wake up to the desktop - then attach the USB cable - does the USB device wake up ? Fearing that it does not at this stage of testing.
1) Power down your MAC. Remove the audio USB device after the computer is powered off.
2) Leave the USB device disconnected and power the MAC up again.
3) After reaching your desktop / OS boot, insert the USB cable for your Audio widget. Does the external USB Audio device get detected ? Are you able to use this external USB device ok ?
4) Remove the Audio USB cable once again and repeat to confirm if the USB device is removed and then detected (enumerated) by the host OS. The attach / removal of the USB device should allow the OS to detect the same conditions of this external device.
5) Allow the MAC to enter suspend / sleep mode. Remove the USB cable once again -> allow the MAC to wake up to the desktop - then attach the USB cable - does the USB device wake up ? Fearing that it does not at this stage of testing.
-
- Junior Member
- Posts: 6
- Joined: Fri Mar 25, 2016 2:21 pm
In case of 1-2-3 instruction USB Audio device get detected and I can use it. But when I reproduce the same 1-2-3 steeps and left MAC switch of for longer time (approximately 5 minutes or more) then Audio USB device is not detected by the host OS anymore.
In case of your instruction No. 5, Audio USB device is not detected by the host OS. I attach USB cable immediately after I wake up MAC but no success.
But, the director and main developer of the company who produces “DAC” with installed “M2Tech OEM XMOS USB board”, said to me again, that:
“there can be a reason that this sleeping mode cannot be switched off due to the content of the firmware which is quite special.”
And he also sad to me, that they have send my question/comments to M2tech and that this can take some time before I will get the answer. He also offered me new USB XMOS USB board from M2Tech but he warned me that the behaviour of new M2Tech board will be exactly the same.
I will wait to see where is the “secret” of this “unpractical” firmware that M2Tech put in the XMOS chip. I hope M2Tech answer wont point the finger to the XMOS sleeping mode again :-) But I think they wont, maybe here is really some reason for such behaviour. I will inform you if (?) I get some answers.
In case of your instruction No. 5, Audio USB device is not detected by the host OS. I attach USB cable immediately after I wake up MAC but no success.
But, the director and main developer of the company who produces “DAC” with installed “M2Tech OEM XMOS USB board”, said to me again, that:
“there can be a reason that this sleeping mode cannot be switched off due to the content of the firmware which is quite special.”
And he also sad to me, that they have send my question/comments to M2tech and that this can take some time before I will get the answer. He also offered me new USB XMOS USB board from M2Tech but he warned me that the behaviour of new M2Tech board will be exactly the same.
I will wait to see where is the “secret” of this “unpractical” firmware that M2Tech put in the XMOS chip. I hope M2Tech answer wont point the finger to the XMOS sleeping mode again :-) But I think they wont, maybe here is really some reason for such behaviour. I will inform you if (?) I get some answers.