Countless lines of provided code working flawlessly to stream your favorite music with one line missing – Sue Them!. They have provided hundreds of (small) companies with a superb software reference design to derive their own implementation from with a relatively spectacular low investment of time and money. This action takes place in a section (which is indeed part of the USB audio framework) where the XMOS stack is asked to switch bit rate. Again, one simple line of code causes the XMOS stack to crash because it tries to read and write in an illegal memory region. I have noticed some of you have magically sympathetically reasoned towards a timing issue or even brought USB compliance into the equation. Which means other platforms can encounter this issue in the future just as likely. Different behavior is seen on different platforms because they use the same system in a different way. Think of it as an ever-present hidden bug that has surfaced in the field with evolving use cases because the part of the bugged XMOS code is now being addressed more often. You can also look at the bigger picture Just imagine that every company providing Roon-like streaming solutions with USB playback must implement such patches to cover up underlying issues…No Go. As long as the root cause of the issue (mind you - one line of XMOS code) is not fixed there is no point to it. Asking them to implement a workaround is like putting a band aid on an infected wound. Since I am the one who discovered and fixed the bug, I feel entitled to share some thoughts and opinions in the matter hopefully without offending anyone. Thanks to all who have reported this issue.
0 kommentar(er)
