-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
SMSL M500 - Owners' Thread
- Thread starter TC!!
- Start date
SMSL has already withdrawn this firmware version (2.01) weeks ago from the homepage.
Certainly not without reason.. should probably not be installed at the moment.
Do you realy want the magenta provenance indicator? This is probably not an issue of the firmware/ device.
Read here: https://www.audiosciencereview.com/...l-m500-dac-and-hp-amp-review.9606/post-387387
Shoaibexpert
Addicted to Fun and Learning
- Joined
- Apr 28, 2019
- Messages
- 525
- Likes
- 198
Hi @SMSL-Mandy and @SMSL_Liu can we know why some of us can update to SW 1.8/2.01 while others are stuck at 1.5 like myself? Are you guys doing something to sort your SW issues or should people just start looking elsewhere for reliable products? Thanks
As Albocan has advised , after updating to ver 2.01 , the software defaults back to ver 1.05 SW / 1.2 HW -Although appearing and having confirmation that update of ver 2.01 was successful.
Functionality on the M500 does not appear to have been effected so far.
Functionality on the M500 does not appear to have been effected so far.
SwampyDude
Member
- Joined
- Apr 21, 2020
- Messages
- 9
- Likes
- 0
apart from can,t select 32 bit
I have tested the MQA functionality on the M500 , by using test files from 2L.no/hires/
Selecting an MQA file from the available options for test, proved that an MQA file is not being recognised and is played as a HIGH RES 384KHz file , but no decoding or rendering of the MQA unfolding is being executed.
Surely this is not correct , or am I missing something?
OK changed the rate and bit depth in Windows 10 sound settings .
MQA now recognised !!
Selecting an MQA file from the available options for test, proved that an MQA file is not being recognised and is played as a HIGH RES 384KHz file , but no decoding or rendering of the MQA unfolding is being executed.
Surely this is not correct , or am I missing something?
OK changed the rate and bit depth in Windows 10 sound settings .
MQA now recognised !!
Last edited:
I also emailed SMSL about 3 weeks ago.
However, SMSL has never answered this question.
I can't feel sincerity for the user.
Topping will always send us a reply email.
What is the difference between the two companies?
I have a question.
Where can't 32bit be selected?
What is your PC's playback environment? Foober2000? , Windows audio?
Shoaibexpert
Addicted to Fun and Learning
- Joined
- Apr 28, 2019
- Messages
- 525
- Likes
- 198
I guess my next DAC is Topping then...a little more money...but better quality materials and some one replies to emails...is that too much to ask I wonder...
If SMSL wants to compete with Topping it needs to step it up. Hire a native english speaking person to run SM/PR/CS. Mandy seems busy with sales.
Can't just throw a product out there with the same price and expect people to cartwheel their way over to your company.
mon2
Member
Hello all. First time here. I am a senior, independent developer with XMOS devices and a hardware developer with 35+ years of experience at our company here in Windsor, Ontario, Canada.
Coming here from the XMOS user forum after a discussion with another SMSL customer:
https://www.xcore.com/viewtopic.php?f=26&t=7915
Fairly confident that there is now an understanding on what is the issue with these boxes that are reverting back to the 1.05 firmware and refuse to accept an update after this upgrade procedure.
At this time, do not believe it will be possible to fix via software although still researching the tools that are most likely embedded inside your firmware.
Hardware fix is logical and respectively why the factory is asking for the product to be returned back to their office in Shenzhen.
Have some questions and welcome feedback:
1) Are there any owners of this product and also happen to be hardware developers (with respective tools)?
2) Any chance someone is in (Ontario?) Canada with one of these boxes? We really do not wish to purchase a unit off Amazon for R&D to debug this case unless we can at least recover the product cost. We are not audio developers but tossing around the idea of building such products. If you are comfortable with the idea, send us a private email and the unit for loan, we will then repair the unit and return back to you at our expense - best if you are in Canada but USA would work as well.
Our company has been designing h/w products for 35+ years and supporting XMOS designs for the past 10 years.
The root cause is related to the XMOS DFU tool having a bug that demands that the upgrade firmware be compiled on a specific version (or higher) of the compiler.
The fix is to locate the 8 pin SMD (surface mount flash IC) -> desoldering it is best -> make a backup of the firmware -> locate the corrupt firmware inside this flash -> erase the sectors containing the corrupt upgrade image. Solder back the flash device. Upgrade again to the latest version.
The alternate plan is to use a zero force 8 pin spring clip (SOIC) adapter to piggy-back the same soldered part -> place the entire PCB into #RESET mode (ie. ACTIVE LOW so ground it) -> this will then tri-state (high impedance) the 8 pin FLASH device so that an external SPI bus master can be used to re-flash the same corrupt flash device.
The above process has to be confirmed with a true corrupted M500 but very confident this to be the root cause and immediate resolution.
In hindsight, it would have been wise to incorporate a rather simple onboard SPI flash programmer for such corner cases like this one to fix "bricked" firmware.
Bye for now.
Adding what is believed to be the root cause document (summary: external SPI flash is now corrupt for the upgrade image and the DFU tool is confused and using the factory original & known good firmware @ 1.05 but also preventing the use of the DFU tool to further upgrade the box):
https://axxonshare.s3.amazonaws.com...returned-in-libflash-and-libquadflash_1.0.pdf
Coming here from the XMOS user forum after a discussion with another SMSL customer:
https://www.xcore.com/viewtopic.php?f=26&t=7915
Fairly confident that there is now an understanding on what is the issue with these boxes that are reverting back to the 1.05 firmware and refuse to accept an update after this upgrade procedure.
At this time, do not believe it will be possible to fix via software although still researching the tools that are most likely embedded inside your firmware.
Hardware fix is logical and respectively why the factory is asking for the product to be returned back to their office in Shenzhen.
Have some questions and welcome feedback:
1) Are there any owners of this product and also happen to be hardware developers (with respective tools)?
2) Any chance someone is in (Ontario?) Canada with one of these boxes? We really do not wish to purchase a unit off Amazon for R&D to debug this case unless we can at least recover the product cost. We are not audio developers but tossing around the idea of building such products. If you are comfortable with the idea, send us a private email and the unit for loan, we will then repair the unit and return back to you at our expense - best if you are in Canada but USA would work as well.
Our company has been designing h/w products for 35+ years and supporting XMOS designs for the past 10 years.
The root cause is related to the XMOS DFU tool having a bug that demands that the upgrade firmware be compiled on a specific version (or higher) of the compiler.
The fix is to locate the 8 pin SMD (surface mount flash IC) -> desoldering it is best -> make a backup of the firmware -> locate the corrupt firmware inside this flash -> erase the sectors containing the corrupt upgrade image. Solder back the flash device. Upgrade again to the latest version.
The alternate plan is to use a zero force 8 pin spring clip (SOIC) adapter to piggy-back the same soldered part -> place the entire PCB into #RESET mode (ie. ACTIVE LOW so ground it) -> this will then tri-state (high impedance) the 8 pin FLASH device so that an external SPI bus master can be used to re-flash the same corrupt flash device.
The above process has to be confirmed with a true corrupted M500 but very confident this to be the root cause and immediate resolution.
In hindsight, it would have been wise to incorporate a rather simple onboard SPI flash programmer for such corner cases like this one to fix "bricked" firmware.
Bye for now.
Adding what is believed to be the root cause document (summary: external SPI flash is now corrupt for the upgrade image and the DFU tool is confused and using the factory original & known good firmware @ 1.05 but also preventing the use of the DFU tool to further upgrade the box):
https://axxonshare.s3.amazonaws.com...returned-in-libflash-and-libquadflash_1.0.pdf
Last edited:
- Joined
- Oct 25, 2019
- Messages
- 12,103
- Likes
- 16,980
Dont upsample? OR upsample to lower rates
I thought M500 could that
- Joined
- Oct 25, 2019
- Messages
- 12,103
- Likes
- 16,980
Play 768khz pcm? It can. With pops. Or possibly the pops are a result of the cpu intensive upsampling you are doing on your computer.I thought M500 could that
But I'm interested to know what you are trying to achieve by upsampling? Especially to such a high degree. And what is your source file?
I play all my files through ROON and up-sampling done by HQPlayer. for all sources of files
- Joined
- Oct 25, 2019
- Messages
- 12,103
- Likes
- 16,980
Right. But you didn't answer the main part of my question (why are you upsampling) and barely answered what your source was. In fact, you didn't do that either. You said what your player was.
To improve it, and sometime I use upsampling to DSD256 to give it more smooth and more body
Similar threads
