Rockbox Technical Forums
Support and General Use => Hardware => Topic started by: hd321kbps on December 13, 2015, 04:30:20 PM
-
Is Rockbox for the player Xduoo x3?
Maybe someone will take? Now such a stir on the forums!
Built on a powerful processor Ingenic JZ4760B and has an analog DAC CS4398 from Cirrus Logic, and operational amplifiers OPA1612 and LMH6643
More about him can be found here (http://www.xduoo.com/xduoo/EnProductShow.asp?ID=62).
-
Is Rockbox for the player Xduoo x3?
No, just the devices on the front page.
If you're interested in working on rockbox, see:
http://www.rockbox.org/wiki/NewPort
-
Hi,
this is interesting. Me and Marcin Bukat are working on porting Rockbox to the Fiio X1 that uses the JZ4760B, PCM5142 DAC and OPA2322 + ISL28291 amplifiers: http://www.rockbox.org/wiki/FiioX1 (http://www.rockbox.org/wiki/FiioX1)
The first step would be to document the player on the wiki, in a similar fashion to the Fiio X1: describe components, upload PCB pictures if you have some. Then try to get the firmware, possibly using a firmware update and try to extract it using our packtools in our repository (utils/jz4760/packtools). You can also come on our IRC channel to discuss: see http://www.rockbox.org/irc/ (http://www.rockbox.org/irc/) and my peudo is pamaury.
-
I have created a wiki page to gather some information about the device, it can be found at http://www.rockbox.org/wiki/XDuooX3 (http://www.rockbox.org/wiki/XDuooX3). I don't have the device so it's all based on the firmware update released.
-
If someone can add me to the Wiki users group I can edit there directly. No-one was available on IRC.
To get to recovery mode, turn the device off, press and hold the Esc/Home button and plug in a USB cable. The device appears in Windows Device Manager as a JZ4760 USB Boot Device, USB\VID_601A&PID_4760\7&1ea98c86&0&4 USB class FF USB protocol 50 (i.e vendor ID 601A, product ID 4760 as in the wiki). To return to normal operation, disconnect the USB cable and press the recessed reset button on the right side.
To update the device, navigate to TopMenu->Setting->Upgrade->Yes. The new firmware must be a file named 'update.zip' placed in the root directory of a uSD card formatted with FAT32.
-
https://infinit.io/_/j7zJqy4
some inside pics.
-
Hi,
I have updated the wiki page http://www.rockbox.org/wiki/XDuooX3 (http://www.rockbox.org/wiki/XDuooX3) to add the PCB scans. Using this and some binary reverse engineering, I have concluded that similarly to the Fiio X1, it uses a SLC NAND + mobile DDR RAM MCP. The RAM size is 64MiB and the NAND size is 128MB.
-
Hi to all.
Hmm. It looks like a good platform for experiments on rockbox porting. But I do not see any uart pins on the board. Serial output is helpful for debugging.
-
Hmm. It looks like a good platform for experiments on rockbox porting. But I do not see any uart pins on the board. Serial output is helpful for debugging.
MP3 players usually don't have any deug pins on retail versions. The first part to a port is usually to make the screen work, to display some information. That's what I plan to do first anyway. I bought the player but I won't have it until another 10 to 15 days:
-
I'm very interested in this port. However, I have not much knowledge about embedded development.
Can I do anything to support this?
-
Hi,
sorry I wanted to answer earlier. If you have no knowledge of embedded systems, it's gonna be tough for you to help with the development. However when (I hope) the port is in early stage, heavy testing and reporting problems is much appreciated.
-
Is there any info about X3 GPIO's and OLED interface?
-
Hi,
short answer: no.
So far I haven't played much with the X3. I sent an email to xDuoo to ask them for the source of the Linux Kernel, but I admit I am not overly confident.
Otherwise, the obvious way to go is to hack the firmware upgrade image to include a custom program (or possibly a remote shell) and basically poke in /sys or /proc to see what kind of information is there. I expect I'll have to do some reverse engineering of binary-only modules anyway but if I could avoid disassembling the kernel that would much better.
For the LCD, the nicest outcome would be to find the exact controller used and get the datasheet but this is not always possible, we'll see how it goes.
Another thing is that they are using uboot, so maybe they display some splash screen from uboot in which case some LCD code will be in uboot, which will be much easier to disassemble (again uboot is GPL but it's not clear if they will provide any source code).
-
I've checked u-boot and I did not find any LCD/OLED code or any fonts/sprites in it.
This code is somewhere in internal kernel module.
-
What kind of programmer do you guys need? C++ expert? C?
How about the answers from Xduoo? are they collaborating?
I'd like to apply for beta tester. also for paying some beers to those who can make this possible.
-
Hi,
I didn't get any answer from Xduoo so I guess we will have to reverse engineer everything.
The first step will be to make the lcd display something. I always begin ports by playing with the device through a remote usb connection and some lua scripting. When we got that working, we will write some C code.
-
Maybe it will help...
I did some RE on kernel and found a signs of SSD1305 (https://www.adafruit.com/datasheets/SSD1305.pdf) LCD driver.
-
Hi All.
Here is remote script runner for X3. Now you can run various scripts on the device, play with gpio's, oled_ioctl etc.
How to use:
1) unzip x3_remote.zip to sd-card.
2) edit script.sh
(SD card mounted on /mnt/sdcard0/ so you can use it to get results or run external programs etc).
3) insert SD-card into SD1 slot and choose "Upgrade".
4) Player reboots into recovery mode then runs "script.sh".
5) When the script is completed, player reboots into normal mode.
Here is some findings.
uname -a
Linux (none) 2.6.31.3 #399 PREEMPT Fri Nov 20 17:31:16 CST 2015 mips GNU/Linux
/proc/cpuinfo
system type : JZ4760B
processor : 0
cpu model : Ingenic JZRISC V4.15 FPU V0.0
BogoMIPS : 393.21
wait instruction : yes
microsecond timers : no
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
/proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "BOOT"
mtd1: 00100000 00020000 "MISC"
mtd2: 00400000 00020000 "KERNEL"
mtd3: 00600000 00020000 "RECOVERY"
mtd4: 00800000 00020000 "CONFIG_RO"
mtd5: 03200000 00020000 "ROOTFS"
mtd6: 02a00000 00020000 "CONFIG_RW"
mtd7: 00800000 00020000 "CACHE"
x3_remote.zip (https://mega.nz/#!1982iBwa!KGfl7zeca2d7ee6IhlQcUKvaEfZhX1z7aUQGDwpGheY)
-
I've found a UART TX pin on the X3 board. See the attached picture:
(http://i023.radikal.ru/1602/4b/efe54b8b23a7.png)
CPU UART1, TTL levels, 3.3V, 57600 8N1 for stock firmware.
Upper pin probably RX pin, does not checked exactly. Pulled-up to 3.3V, no out signals.
I think the UART should help us at the first time.
Here is stock fw boot log (boot-up / playing two songs / shutdown):
NAND Secondary Program Loader
X00000004
00000001
Starting U-Boot ...
U-Boot 1.1.6 (Nov 20 2015 - 17:24:35)
Board: Ingenic IDREAM (CPU Speed 492 MHz)
DRAM: 64 MB
Error: Unknown flash ID, force set to 'SST_ID_39SF040'
Flash: 512 kB
NAND:128 MiB
NORMAL Booting ...
*** Warning - bad CRC or NAND, using default environment
In: serial
Out: serial
Err: serial
Net: JZ ETHERNET
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x200000, size 0x300000
3145728 bytes read: OK
## Booting image at 80600000 ...
Image Name: Linux-2.6.31.3
Image Type: MIPS Linux Kernel Image (gzip compressed)
Data Size: 2824266 Bytes = 2.7 MB
Load Address: 80010000
Entry Point: 80015a20
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
Starting udevd ...
[ 4.210000] fat_get_cluster: invalid cluster chain (i_pos 0)
fat_get_cluster: invalid cluster chain (i_pos 0)
fat_get_cluster: invalid cluster chain (i_pos 0)
fat_get_cluster: invalid cluster chain (i_pos 0)
killall: ihifiplay: no process killed
~ # [PRT|libinicfg.c|139]:auxpath=
[PRT|libinicfg.c|140]:country=0
[PRT|libinicfg.c|141]:cycmode=0
[PRT|libinicfg.c|142]:volumes=75
[PRT|libinicfg.c|143]:ledtime=30
[PRT|libinicfg.c|144]:offtime=10
[PRT|libinicfg.c|145]:cyclist=2
[PRT|libinicfg.c|146]:baklight=4
[PRT|libinicfg.c|147]:gain=1
[PRT|libinicfg.c|148]:filter=1
[PRT|libinicfg.c|149]:slppower=0
[PRT|libinicfg.c|150]:autoup=0
[ERR|libioport.c|32]:access /sys/class/gpio/gpio48
fid0=1000, fid1=1001, fid2=1002
filetag.c|357 /mnt/sdcard0/44100.flac------------------------>0
[musicplay.c|1207]----------------->g_load_tid:3
filetag.c|357 /mnt/sdcard0/48000.flac------------------------>0
[musicplay.c|1207]----------------->g_load_tid:3
receive cmd: pause
no power connected!
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system poweroff
-
Hi,
those are very interesting findings :) I am quite byst right now but I should try it by myself. Do you know if the update script executed as root ?
-
Yes, there are all executed as root. But to dig out from Linux is not interesting.
Now I'm playing with SPL - peekpoking a GPIO's. Here is some findings:
Buttons:
47 - BTN_LOCK (0=unlock; 1=lock)
30 - BTN_POWER (1->0)
113 - BTN (1->0) BOOT_SEL0
SD card:
29 - SD1_INSERT (1->0)
28 - SD2_INSERT (1->0)
Other:
44 - LINEOUT_DETECT (1->0)
43 - HEADPHONE_DETECT (1->0) (?)
48 - MUTE_RELAY
-
First steps on real device:
(http://s019.radikal.ru/i643/1602/96/4bd6ca476d46t.jpg) (http://s019.radikal.ru/i643/1602/96/4bd6ca476d46.png)
-
OMG, First steps to rockbox on xduoo x3, I'm so happy with this :)
-
Bravo! Your recent progress is very heartening. Wish I had the skills to help. Keep at it, cannot wait to have Rockbox of this fine little player.
-
Good news and congratulations for the job.
-
I have nothing technical to add but if you need hardware resources to aid this port please ask.
Thanks for your dedication to the cause, really great to see the progression!
This player has some great raw attributes but is let down by shocking software, I'd go as far as saying stock Sansa Fuse+ software is better than Xduoo's offering, a collaborative effort would benefit both sides so much especially the pitch issue.
-
Quite sure you have probably looked over the datasheet for the cirrus logic cs4398, but figured it might help having it on the wiki. http://alsa-project.org/~james/datasheets/www.cirrus.com/en/pubs/proDatasheet/CS4398-2.pdf
-
Yes. Thanks. The first public beta of the Rockbox for X3 will be released very soon.
-
I will just leave it here: http://xvtx.ru/rockbox
-
If you're going to link binaries, you should also provide the source code (ideally on the same page). Otherwise it is very hard for other people to contribute.
-
I'm sure Vortex is arranging this via Bitbucket. :-)
-
I really appreciate the hard work on the port but forcing me to create account on bitbucket just to see the sources is impolite really.
-
I really appreciate the hard work on the port but forcing me to create account on bitbucket just to see the sources is impolite really.
at the moment the repo there is private but you can request access and the man page indicates XVertex will make it public soon enough
@XVertex, can we please have a build incorporating the SD card changes here (although i'm not sure they're applicable to x3)
http://git.rockbox.org/?p=rockbox.git;a=commit;h=a24abd2a4769b9217a584c46a0c23e26e1efe467
http://git.rockbox.org/?p=rockbox.git;a=shortlog (I'm not sure about the specific commits but Michael indicated these can help random track skipping mid song that I experience on X3 and clip+)
ps amazing work indeed.
-
Hi,
I am sorry to insist but this is really quite impolite: you are using our source code, our logo, you are even accepting donations for yourself and distributing binaries, the least you could do is to make the source publicly available for download without having to request access or to create account on another website.
-
Give him some time, as said we are pretty sure it's being arranged, so please calm down a wait a little.
-
This is really cool. Very appreciative, there's always a but though...
Anyone else getting a lot of hiss/white noise on high res flac files? Tried adjusting the oversampling but no change, all other formats seem great.
-
xDuoo X3 Rockbox source code has been released on Github (https://github.com/xvortex/rockbox).
I'll be glad if you join to improve the project.
-
xDuoo X3 Rockbox source code has been released on Github (https://github.com/xvortex/rockbox).
Code quality looks excellent, but someone familiar with the JZ should review.
Also, the copyright notices should be your real/legal name, not your screen name.
-
Thanks. Nevertheless port still has some USB-stack issues and unfinished NAND ops.
Everything else works. A successful public launch this confirms.
-
Thanks. Nevertheless port still has some USB-stack issues and unfinished NAND ops.
Everything else works. A successful public launch this confirms.
Hello,
Is it stable? Will it support Rockbox Utility? I currently have a Sansa Clip+ which I'd like to replace with something better with Rockbox, thinking about the Xduoo X3. If everything works as it should, I'll get it.
-
Thanks. Nevertheless port still has some USB-stack issues and unfinished NAND ops.
Everything else works. A successful public launch this confirms.
Hi,
first off all, a big "thank you" for the port!
I installed the most recent version (7658c23-160321) and it worked very well for the most part. Some minor issues tough:
- There is about a 3 second delay between selecting a file and playback starting
- When using a 128 GB micro SD formatted to FAT32 things go a little bit off the hook:
I put about 80GB of music and the system folder on the card. The system boots and does not seem to misbehave. When trying to build the library, the system first panicked ("Stkov dircache"), on the second attempt a library was built but it contained only a single Artist. After a few attempts it successfully built the library, even tough navigation was rather sluggish (~2sec delay for selecting an entry)
Trying to play songs either from the folder-view or the library instantly skips about 90% of selected songs, only a few are playable.
This behaviour does not seem to change when the system is booted from a 32GB card in the first slot and the 128 GB card is inserted into the second.
Is the issue with 128 GB cards expected for this built? Any more information I could provide to help diagnose this further?
Edit April 03, 2016, 07:41:58: Just tried the same SD-card on a Sansa Clip Zip running Rockbox 3.13 and varying the partiton size. No change in the behaviour of Rockbox on xduoo, the clip zip has no issues tough. Also the stock firmware of the xduoo can read/play the files
Edit April 05: Regarding the issue with non-playable songs: I was jumping to conclusions regarding the memory card being at fault, this only happens (reliably) for ogg-files, no matter the medium. Mostly it will just skip them but for a particular speex-encoded file it panics with LTB refill handler at 0x83E045F4 [0x0]. mp3, aac, opus and wma work fine.
-
Please forgive my lack of understanding, but what happens now with XVortex's ROCKbox port - how does it become "officially" adopted by ROCKbox?
-
It looks good. Already. This was definitely worth a donation.
I noticed the start-play-delay , but I think that's hard too overlook.
Does the X3 hardware support USB Connections, or can it just charge? (Transfer also didn't work with the original firmware)
-
Hi guys,
I'm not hurrying anyone, I'd just like to know how much work left.. Do you know how much time it can take until this port will be released for typical users and it will have stable status on wiki page?
Thank you!
K
-
You are right, just switched to RB. It's works very well and in case of problem we can boot to original soft any time. I hope RSS will be available for soft updates so I could be notified. Definitely will donate after using some time.
K
-
Hi guys,
I'm putting this here for visibility. I've raised some issues and proposals for enhancement here: https://github.com/xvortex/rockbox/issues
Also I can see sometimes I can access SD card while device is charging via USB and sometimes not.. This is quite strange, I will keep eye on it.
K
-
@XVortex,
Noob here. I just downloaded update-to-rockbox-d312ba8M-160316.zip and changed the name to update.zip.
I am stuck in boot screen saying
"Loading firmware...
Error: File not found"
Any help would be appreciated. Thanks.
You must have the SD card formatted with FAT32 and with 4096 (4KB) cluster, not important what is the SD capacity.
-
@XVortex,
Noob here. I just downloaded update-to-rockbox-d312ba8M-160316.zip and changed the name to update.zip.
I am stuck in boot screen saying
"Loading firmware...
Error: File not found"
Any help would be appreciated. Thanks.
You must have the SD card formatted with FAT32 and with 4096 (4KB) cluster, not important what is the SD capacity.
Thanks for the reply. Which format should I change to? Right now it stuck in error screen.
-
You must have the SD card formatted with FAT32 and with 4096 (4KB) cluster, not important what is the SD capacity.
Thanks for the reply. Which format should I change to? Right now it stuck in error screen.
What do you mean? Use a tool to format the SD card (I used succesfully the free AOMEI Partition Assistant Standard Edition 6.0) as I posted before...
-
Bought one of these just because of this port! Rockbox runs very well on it, and it's SO good to have it on a nicer player again (my ailing iRiver H320 is unhappy these days).
I have run into a panic! error a few times where the player will freeze until I can reset it. It usually happens a few seconds after boot when I try pressing a button or two. It may have something to do with having recently connected via USB (under the OFW) to manage files. Once I reset, though, it behaves.
Thank you Vortex and everyone else who helped make this possible.
-
Kokos, I think you're right--I set my player to boot into the WPS and have had no issues, probably because I don't try navigating the menu so soon on boot.
I have run into the issue where Ogg files won't play, though. This is less than ideal, since over half my music is Ogg Vorbis. :-\ I'm going to try stripping the comments from a few and see if that helps. There's OFW for that I suppose, but compared to Rockbox, the OFW is very limited.
-
I'm putting this here for visibility. I've raised some issues and proposals for enhancement here: https://github.com/xvortex/rockbox/issues
I'm still not sure developer can see these requests, whether this is right place to submit them.
-
I'm assuming since this isn't an official Rockbox port (yet), xVortex is simply making his own port available for others to use/modify/review. If he doesn't use Ogg Vorbis, pause on headphone plug out, etc., it's likely he's not interested in troubleshooting these issues.
It is possible to contact him via his website, but he does refer Rockbox support questions to the Head-Fi forum devoted to the port. If I get sassy (or drunk) I may contact him and ask, but for now I'm just happy the X3 runs Rockbox.
-
Does Rockbox currently work well with the Xduoo X3.
As I'm thinking of getting the Xduoo X3 (Rockboxed) as an improvement, over my Sony NWZ-E464 player.
-
That depends on how forgiving your definition of "well" is. The Xduoo X3 is responsive, sounds great, and has very few issues running Rockbox.
The only two real bugs I've run into consistently are lack of Ogg Vorbis support (the X3 skips any .ogg files) and the "stkov dircache" panic error. If you don't use Ogg Vorbis for your music, then no problem there. And the panic error doesn't seem to happen often (usually when I try navigate the menu immediately on boot). All I have to do is let the X3 boot and leave it alone for five or ten seconds, then it's fine.
Another note: Use a card reader or boot into OFW to transfer music to the device. USB connectivity is a little strange with Rockbox. I use a card reader anyway, just for the speed boost.
If you can live with these bugs, then grab an X3. Even with the bugs, Rockbox is so much better than the original firmware.
-
For those of you you are using a Rockboxed Xduoo, what is the largest capacity SDXC card you've used successfully?
-
For those of you you are using a Rockboxed Xduoo, what is the largest capacity SDXC card you've used successfully?
Now I use a 128Gb in slot 1 and a 64Gb in slot 2.
I don't think there is any problem with two 128Gb cards in both slot: many user on head-fi report that this is possible.
I don't know about larger microSd...
-
I use 2x 128gb cards in mine no problem. I've read reports of 2x 200gb ones working.
Alas this has very little to do with Rockbox dev. so I shall run.
-
So what's the state of this port?
Are the source changes (re)integrated in the main rockbox repository?
Or are the source changes for the xduoo device only available at xvortex repository fork at github?
That would it make harder to reintegrate it to the "normal" rockbox repo because xvortex' changes are more than five months old... :(
Is any dev with commit access here in contact with xvortex to reintegrate the changes?
-
So what's the state of this port?
Are the source changes (re)integrated in the main rockbox repository?
Or are the source changes for the xduoo device only available at xvortex repository fork at github?
That would it make harder to reintegrate it to the "normal" rockbox repo because xvortex' changes are more than five months old... :(
Is any dev with commit access here in contact with xvortex to reintegrate the changes?
maybe try to mail the developer?
http://xvtx.ru/rockbox/contact.htm
-
Hello folks,
I just purchased an Xduoo X3 and have successfully installed rockbox on the player as I really like this firmware on my old Sansa Clip+.
However there is a strange behaviour when moving down through the menus using the > arrow. The menus get automatically selected like I have pressed the play / select button. It happens fairly often so I have taken to just using the < arrrow to move upwards through the menus as it doesn't happen when I do that.
I booted into the stock firmware and this doesn't appear to happen in the stock firmware. Perhaps this is just a coincidence though and the cause is a problem with a dodgy play button that is too sensitive and is essentially getting randomly triggered for some reason when I use the > button.
Perhaps I got a defective unit?
Any thoughts or help would be greatly appreicated!
Cheers in advance.
-
Hello folks,
I just purchased an Xduoo X3 and have successfully installed rockbox on the player as I really like this firmware on my old Sansa Clip+.
However there is a strange behaviour when moving down through the menus using the > arrow. The menus get automatically selected like I have pressed the play / select button. It happens fairly often so I have taken to just using the < arrrow to move upwards through the menus as it doesn't happen when I do that.
I booted into the stock firmware and this doesn't appear to happen in the stock firmware. Perhaps this is just a coincidence though and the cause is a problem with a dodgy play button that is too sensitive and is essentially getting randomly triggered for some reason when I use the > button.
Perhaps I got a defective unit?
Any thoughts or help would be greatly appreicated!
Cheers in advance.
This also happens to me occasionally. It's hard to determine what brings it about and for a while I thought the new version of the firmware solved the problem.
It'd probably be better to post this on the headfi page as the maintainer of the firmware seems to read it https://www.head-fi.org/threads/rockbox-xduoo-x3.803844/page-123
Thanks
-
I don't know if anyone cares or not, but I just rebased the seemingly-abandoned xvortex rockbox tree against master, cleaned up the commits a little bit, and ported the X3's sdcard driver to the new thread-free sdcard API.
This tree encompasses xvortex's unofficial ports for the xDuoo X3 (mipsel jz4760), as well as the Xuelin iHIFI 770, 770C, and 800 (arm rk27xx). I don't have any of the hardware, so I have no way of actually testing this beyond basic compilation. Anyone out there have one or more of these devices, and willing to be a guinea pig?
(It would be nice to get this merged into master; no sense in letting it bitrot and it's always nice to have targets that are still commercially relevant...)
-
I don't think the author has given a real name to attribute his or her code to, and as such, we can't merge it yet.
-
Should ask him for his name and add him to the credits.
-
Should ask him for his name and add him to the credits.
Email sent. I guess we'll see if anything comes back..
Assuming that "vortex" supplies an attributable name, what's next? Push the commits to gerrit for review? (I'm assuming they'll need some further work, and I'm willing to do it..)
-
Email sent. I guess we'll see if anything comes back..
I now have the author's real name, and his blessing to get this stuff mainlined.
How should I proceed?
-
Push to gerrit for review. However without device to test I don't think it is worth the hassle.
-
Push to gerrit for review. However without device to test I don't think it is worth the hassle.
For some time, I've wanted to meaningfully contribute something back to rockbox, and this seemed like a relatively simple way to get familiar with rockbox's codebase -- and one that will yield both immediately useful results and provide a stepping stone to other ports.
I'm no stranger to working with bare-metal embedded code, low-level OS tinkering, and writing device drivers after reverse-engineering efforts, so this sort of stuff is right up my alley.
I have a few more things to clean up and then I'll push the commits to gerrit so they can be bled on.
-
The patches are now in gerrit:
http://gerrit.rockbox.org/r/1854
http://gerrit.rockbox.org/r/1855
Should I add anyone specifically to do reviews?
-
For 1885 I can review the patch. For 1854 I think me (wodz) and pamaury.
-
I commented on gerrit.
-
The patches are now in gerrit:
http://gerrit.rockbox.org/r/1854
http://gerrit.rockbox.org/r/1855
Should I add anyone specifically to do reviews?
If I understand correctly, these are updates to the 170609? If so, I'd be interested in testing it out. Please let me know what i need to do.
Thank you,
- m
-
Those are patches that merge the source code into the rockbox tree. No idea if this is even safe to try on a real device, but here is a binary for the x3:
http://mit.edu/mgg6/www/rockbox-x3.zip
Compiled using:
http://gerrit.rockbox.org/r/#/c/1747/
http://gerrit.rockbox.org/r/1854
-
Looks like the X3 has been succeeded:
https://www.xtenik.com/xduoo-x3-ii-lossless-music-player/
2.4" color screen, different DACs, bluetooth, and somewhat saner button layout.
(...I have a strong suspicion that this is another hibi_player-on-Linux device..)
-
The claim of playback time being improved to more than 13 hours is the number that most interests me as that would mean being to able to use it for a whole work shift without recharging.
-
Those are patches that merge the source code into the rockbox tree. No idea if this is even safe to try on a real device, but here is a binary for the x3:
http://mit.edu/mgg6/www/rockbox-x3.zip
Compiled using:
http://gerrit.rockbox.org/r/#/c/1747/
http://gerrit.rockbox.org/r/1854
Tried your build and got an error.
*PANIC*
exception occured:
Reserved Instructi
on [0Xfffffff] at
0x800e0da8 (stack a
t 0x8000391c)
-
Tried your build and got an error.
*PANIC*
exception occured:
Reserved Instructi
on [0Xfffffff] at
0x800e0da8 (stack a
t 0x8000391c)
Well, crap, that was unexpected.
If I'm reading this correctly, it's trying to execute an instruction from an address within the scroll stack. That doesn't sound right.
I just generated a new build, this time with full debug, from the current git HEAD plus the two commits that saratoga referenced. Please let me know how this goes; I'll be better able to dig into whatever goes wrong with this one.
http://www.shaftnet.org/~pizza/rockbox-x3-gf39149e834.zip
-
*PANIC*
Exception occured:
Reserved Instructi
on [0xfffffffff] at
0x800e5b08 (stack a
t 0x8000391c)
no logf data
-
Hi; I was looking at the code that's now been merged into rockbox master and trying to see how it lines up with the version that's downloadable from the xvtx.ru site. There seem to be some differences, so are we still missing some parts? In particular, the xvtx.ru rockbox.bin that you flash into the NAND starts with the expected 0xaaaaaaaa/0x55555555 headers that the JZ4760 requires to be able to do an initial boot-from-NAND, whereas the rockbox.x3 in the zipfile that pizza provided for download doesn't. I also can't find anything in either the rockbox-merged code or the https://github.com/xvortex/rockbox repo that's implementing the "if hold switch is in hold position, chainload the original firmware rather than booting rockbox" feature, which should be happening in the very-early-boot phase.
I'm probably missing something obvious here -- if somebody could point me in the right direction it would be appreciated.
(I'm playing about with writing a QEMU model for the XDuoo-X3, because it seemed like it might be a helpful debug tool. This would be easier if I had the sources corresponding to the binary I'm trying to get it to run :-) I have the hardware and it runs the xvortex install fine, but it would be nice to be able to move to upstream at some point.)
-
The "rockbox.x3" image is chain-loaded by the bootloader, and is intended to be loaded into (and executed from) RAM. The bootloader is a separate compilation target that is intended to be executed directly from flash by the SoC.
The code in bootloader/xduuox3.c doesn't seem to do any button checking/manipulation -- including USB mode and optional verbose output that is typically present. It appears as if there is no dualboot support for the X3 anywhere in the xvortex sources. Most targets put their dualboot support under rbutil/, as part of the original firmware patching functionality.
The x3's bootloader build (bootloader-x3.bin) doesn't prepend the 64 bytes of AAAA/5555 headers either. That is easily rectified, but I'm not sure I'd trust flashing the resulting image.
-
Ah, that makes sense. So the xvortex "rockbox.bin" that goes into the NAND is actually the bootloader, and rockbox proper lives on the SD card. Looking at rockbox.bin with "strings" it seems like it's a combination of (a) an "SPL Stage 1" part that does some basic setup and figures out whether it's booting rockbox or the stock firmware (b) the "SPL Stage 2" rockbox bootloader from bootloader/xduoox3.c (c) a complete copy of u-boot for booting the stock firmware. If we're missing the sources for the most recent bootloader perhaps we could ask the original author for them?
Is there documentation for what the boot protocol for loading and starting rockbox.x3 is (where it needs to be loaded, CPU state, etc)? I might skip ahead from trying to get QEMU to be able to run the bootloader (which turns out to be painful because it expects to be able to execute directly out of dcache/icache and write to the SDRAM via the equivalent uncached address without overwriting itself, and QEMU doesn't emulate caches...)
-
Is there documentation for what the boot protocol for loading and starting rockbox.x3 is (where it needs to be loaded, CPU state, etc)? I might skip ahead from trying to get QEMU to be able to run the bootloader (which turns out to be painful because it expects to be able to execute directly out of dcache/icache and write to the SDRAM via the equivalent uncached address without overwriting itself, and QEMU doesn't emulate caches...)
You mean main rockbox binary? It is copied to ram @0x80000000 (KSEG0). First 16k (0x80000000 - 0x80003fff) is used for IRAM section which contains also iterrupt vectors. Consult https://git.rockbox.org/?p=rockbox.git;a=blob;f=firmware/target/mips/ingenic_jz47xx/app.lds;h=85c332b1820fd6421bfe0b9236bff3e63af5872f;hb=HEAD for details.
I think I know why X3 merged in rockbox crashes but I don't have device to test. If you want to help we may arrange IRC debug session.
Besides writing support for new SOC in qemu is huge task. I started such work for ATJ213x https://github.com/wodz/qemu-atj. Never finished but maybe one day I'll come back to this as writing emulator is fun.
-
I think I know why X3 merged in rockbox crashes but I don't have device to test. If you want to help we may arrange IRC debug session.
I just managed to snag a second-hand unit via eBay for half the price of a new unit. Should be delivered before the end of the week.
-
You mean main rockbox binary? It is copied to ram @0x80000000 (KSEG0). First 16k (0x80000000 - 0x80003fff) is used for IRAM section which contains also iterrupt vectors. Consult https://git.rockbox.org/?p=rockbox.git;a=blob;f=firmware/target/mips/ingenic_jz47xx/app.lds;h=85c332b1820fd6421bfe0b9236bff3e63af5872f;hb=HEAD for details.
Thanks. (I have a fair amount of experience with writing QEMU device/SoC emulation; I agree it's not a small task, but if you can live with not having complete coverage of functionality it's not too insurmountable. My prototype can currently boot SPL1 up to the point where it wants to load SPL2 off the NAND, which isn't bad for a couple of days' work. The datasheets are pretty good too as SoC datasheets go, though I haven't been able to find a spec for the JZ4760B-only extensions that aren't in the 4760.)
I just managed to snag a second-hand unit via eBay for half the price of a new unit. Should be delivered before the end of the week.
I got mine cheap off eBay too -- it turned out to be new-old-stock so the version with the less-capacious battery, and also one of the internal screws holding the circuit board down was rattling around loose inside the case. It works fine now I've removed the loose screw, though :-)
-
Thanks. (I have a fair amount of experience with writing QEMU device/SoC emulation; I agree it's not a small task, but if you can live with not having complete coverage of functionality it's not too insurmountable. My prototype can currently boot SPL1 up to the point where it wants to load SPL2 off the NAND, which isn't bad for a couple of days' work. The datasheets are pretty good too as SoC datasheets go, though I haven't been able to find a spec for the JZ4760B-only extensions that aren't in the 4760.)
Would you mind publishing jz4760 qemu sources somewhere so I can have a look?
-
I just managed to snag a second-hand unit via eBay for half the price of a new unit. Should be delivered before the end of the week.
It arrived. I dropped in the last xvortex build to prove everything worked. Tonight (or more likely, sometime over the weekend) I'll be able to start prodding.
-
It arrived. I dropped in the last xvortex build to prove everything worked. Tonight (or more likely, sometime over the weekend) I'll be able to start prodding.
During my lunch break, recreated the original panic with current rockbox master. Just as a sanity check, I recompiled the pristine vortex sources, and that also blew up:
*PANIC*
TLB refill handler
at 0x800712A4!
[0x4]
This was with the GCC 4.9 toolchain from master, not the ancient GCC 4.1.2 that vortex was using. Still need to rebuild that older toolchain to make sure the original sources are indeed complete/functional.
-
Newer compiler exposes bug in mips threading code. Thats why vortex's sources compiled with 4.9 crash. I fixed this bug in rockbox but I am almost sure something during agptek merge broke it again.
-
Would you mind publishing jz4760 qemu sources somewhere so I can have a look?
https://github.com/pm215/qemu.git xduoo (watch out, that branch will rebase in future).
That has enough to be able to get through SPL1 and into where SPL2 tries to talk to the SD card. There's some sd-controller code in there but it's half-finished. README.XDUOO gives a command line and how to sort out the various data files it wants.
If anybody knows the relation between the "rockbox.bin" bootloader file in the xvtx.ru installer and what actually ends up on the NAND that would be interesting. (I think "nprog" must be doing some equivalent of relocating segments of the .bin file into different parts of the first NAND partition.)
-
Newer compiler exposes bug in mips threading code. Thats why vortex's sources compiled with 4.9 crash. I fixed this bug in rockbox but I am almost sure something during agptek merge broke it again.
http://gerrit.rockbox.org/r/#/c/1905/
Lifted from the Fiio X1 WIP code. It boots, but success was short-lived. When attempting to play:
*PANIC*
Stkov codec
Work-in-progress, eh? :)
-
http://gerrit.rockbox.org/r/#/c/1905/
Lifted from the Fiio X1 WIP code. It boots, but success was short-lived. When attempting to play:
*PANIC*
Stkov codec
Work-in-progress, eh? :)
codec stack overflow - pretty easy to fix. Just increase codec stack size definition and check if that helps.
-
codec stack overflow - pretty easy to fix. Just increase codec stack size definition and check if that helps.
I bumped it from its default 9KB (ie 1KB "default" + 8KB codec) to a combined total of 24KB, and it's now playing music. Working my way back down to find the threshold. (EDIT: 10KB is too small, 11KB is okay)
Unfortunately, it's not able to sustain realtime playback, pausing for about 1 second roughly every 5 seconds on a 320KB mp3. The entire player goes unresponsive during these pauses.
I'll keep poking at it next time I take a break from household cleaning.
EDIT: Dropping the updated mips thread code onto the original vortex tree allows it to work, with realtime playback and a responsive UI.
EDIT2: Just after I wrote said that, the player hung in the fft plugin, requiring a hard reset.
-
Unfortunately, it's not able to sustain realtime playback, pausing for about 1 second roughly every 5 seconds on a 320KB mp3. The entire player goes unresponsive during these pauses.
From what I can tell, the inability to do realtime playback is due due to _very_ poor SD read speeds..
(Looking at the buffering thread debug output, it seems to take about ~1s to fill ~180KB of buffer data, even when starting a new track..)
-
Could try some video game music. NES or SNES files are a few kilobytes :)
-
Could try some video game music. NES or SNES files are a few kilobytes :)
I tossed a couple of 25-year-old protracker .MODs on the X3, and it's puttering along with no effort whatsoever. Granted, that's a lot less CPU-intensive than decoding mp3s, but it supports the theory that the SD driver is the culprit.
The X3's jz4760's SD code was something I substantially altered from the vortex sources when forward-porting to rockbox mainline -- necessary due to the SD/storage thread rework that landed a while back -- but the result was nearly identical to the jz4740 SD driver, with the differences due to the '60 having two SD controllers & slots. Consequently, I suspect that the Onda VX7x7 and other '40 targets also share this SD problem.
-
Still poking. Found out we're driving the SD peripheral off the wrong clock source and likely using the MAX divider too. Fixing that seemed to improve things marginally. Heavily updated the debug menu. Accumulating a small pile of minor fixes things here and there that should be safe to apply..
Another data point is that the player can barely manage slightly better than realtime playback if we're on the final track of a folder (with repeat off).
It could still be the threading code isn't sane; taking to long to context switch or schedule, or perhaps not managing cache invalidation sanely.
(It would be really nice if we had someone with one of the jz7440 targets that could provide additional data points...)
-
Okay, found the culprit. Part of the AGPTek Rocker merge was a change that disabled compiler optimizations for libmad, thus trashing mp3 decoding performance (and smashing its stack!)
flac, wmv, m4a worked fine. (vorbis is being stupid, but I'll get to that later..)
I have a series of patches in gerrit now, awaiting review and merging. Two are essential,:
http://gerrit.rockbox.org/r/1905
http://gerrit.rockbox.org/r/1907 (EDIT: #1907 has been committed)
but I think all of the patches in that series are worth applying. I think that this fix from the X1 series is also advised:
http://gerrit.rockbox.org/r/#/c/1797/
Gerrit won't let me add any reviewers, and I have no commit rights, so this is all I can do.
-
Threading error fixed in #1905 was spotted by me but who cares :-) Anyway I lost ability to merge patches from gerrit :-/
-
xDuoo X3-II got a Rockbox port: https://vk.com/wall-85070453_8323
-
Pretty frustrating they didn't bother to contact rockbox team in any way.
-
If anybody knows the relation between the "rockbox.bin" bootloader file in the xvtx.ru installer and what actually ends up on the NAND that would be interesting. (I think "nprog" must be doing some equivalent of relocating segments of the .bin file into different parts of the first NAND partition.)
Here is reply from xvotex regarding bootloader update image:
Hi.
You're right, X3 boot combined from header, SPL1, rockbox bootloader and uBoot.
This was done manually in a binary editor and a very long time ago.
Unfortunately, I did not have any information on this except what already in repo. sorry.
Regards,
Roman.
-
(vorbis is being stupid, but I'll get to that later..)
The failure is in the ogg frame checksum code -- and the underlying cause is due to the mips asm memset() routine being defective.
Threading error fixed in #1905 was spotted by me but who cares :-) Anyway I lost ability to merge patches from gerrit :-/
I'm not trying to claim credit for code that's not mine.. but someone has to do the work to get things merged...
-
The failure is in the ogg frame checksum code -- and the underlying cause is due to the mips asm memset() routine being defective.
That is strong statement. AFAIK this implementation is copied from some respected source. It has some quirks (like byte copy for small sizes).
-
That is strong statement. AFAIK this implementation is copied from some respected source. It has some quirks (like byte copy for small sizes).
Be that as it may, the empirical evidence points to memset() not working properly. Disabling the asm memset() allows the vorbis code to work.
(It's setting a 4 byte unaligned buffer to 0 before running a checksum algorithm)
-
That is strong statement. AFAIK this implementation is copied from some respected source. It has some quirks (like byte copy for small sizes).
Be that as it may, the empirical evidence points to memset() not working properly. Disabling the asm memset() allows the vorbis code to work.
(It's setting a 4 byte unaligned buffer to 0 before running a checksum algorithm)
Could you pop up on IRC for live discussion?
-
Could you pop up on IRC for live discussion?
Just as a heads-up for the lurkers -- wodz fixed a bug in the mips memset() code, and also merged the threading fixes, so it is now possible to build a working Xduoo X3 rockbox image from git master.
(As I've been putting this thing through daily-use paces, I've accumulated a growing pile of additional improvements that IMO are worth merging. Ah, progress..)
-
From my POV the main blocker now is the lack of SPL1 code vortex used to prepare bootloader install package. I disassembled this binary and it looks very similar to https://github.com/ingenic-src-android/xboot/blob/jz-4780-4775-common/spl/ so maybe we can cleanly recreate it. Interestingly SPL1 in vortex's package is different to anything I could grab from xduoo site.
I've accumulated a growing pile of additional improvements that IMO are worth merging. Ah, progress..)
Do not do that. Put small changes in gerrit (or commit directly if you are brave). You can always abandon patch/revert commit. Big pile of changes is a pain to merge and even bigger to debug later if some bug surfaces.
-
I've accumulated a growing pile of additional improvements that IMO are worth merging. Ah, progress..)
Do not do that. Put small changes in gerrit (or commit directly if you are brave). You can always abandon patch/revert commit. Big pile of changes is a pain to merge and even bigger to debug later if some bug surfaces.
No worries, I know to keep the individual patches as small and self-contained as possible.
(I have 15 patches staged in my tree, eight of which are already in Gerrit)
-
Hi all. Finally I found it:
Here is sources/binaries/script for X3 stock+rockbox stage1: https://mega.nz/#!tlVzGAZK!8lMWGP0WEo_gnVuLLrS2q4yH2BnG2v6TNSTxeCU_LY8 (https://mega.nz/#!tlVzGAZK!8lMWGP0WEo_gnVuLLrS2q4yH2BnG2v6TNSTxeCU_LY8)
-
Great thanks!
I have a question however - the script simply concatenates spl1, r-boot and u-boot. In bootloader install file you provide there is definitely padding between spl1, r-boot and u-boot so r-boot starts @0x2000 and u-boot is aligned on nand blocksized offset. Since r-boot is searched @0x40000 and u-boot @0x60000 and nand blocksize is 0x20000 I think flasher puts 2 copies of spl1 @0x0 and @0x20000 (block0 and block1), rockbox bootloader is placed @0x40000 (block2) and u-boot @0x60000 (block3). Could you confirm my understanding of this?
-
Yes there are couple of a spare spl areas at the begin of the flash and flasher deals with it automatically.
If you dump the NAND you will get them all. but only one (without errors) is used at boot time.
-
Interestingly provided spl1 code is terribly broken. gp is not initialized in startup code but is used since .sbss and .sdata sections are not empty.
-
Hello guys, I have xduoo x3 with Rockbox and recently I have been having issues with the gadget. When I try to turn it on (or when on charger) it just shows the boot logo of Rockbox .. it clicks (makes that sound) .. flashes and all over again .. with a 1 sec interval ... logo-click-flash-logo-click-flash ... all over again ...
hard reset (via button on the side) does not work at all .. do you know what it could be?
-
Hello guys, I have xduoo x3 with Rockbox and recently I have been having issues with the gadget. When I try to turn it on (or when on charger) it just shows the boot logo of Rockbox .. it clicks (makes that sound) .. flashes and all over again .. with a 1 sec interval ... logo-click-flash-logo-click-flash ... all over again ...
Pull out the SD card(s), what happens? (bootloader should report an error about not finding an SD card..)
Also, does the OF start up if you power it on with the lock switch set?
If the OF works, and the bootloader errors out as expected without the card(s) present, then your problem is probably a corrupted SD card, and using the latest daily build on a blank SD card would be a worthwhile test.
-
Hello, I tried:
format the SD card to FAT32 ...
use the default firmware (update.zip file)
Tried to start without SD card and the lock on
this gives the following message:
xDuoo Audio
Digital audio player
Tried to start without SD card and the lock off
this gives the following message:
xDuoo X3 Rockbox Boot
Version d312ba8M-1603
Mounting disk ...
No partition found
Tried to start it with the SD card and the lock on
this gives the following message:
xDuoo Audio
Digital audio player
It even started once here ... that got off again .. via "hard reset" button I was able to make it until "Updating .. do not power off" but then it went off again :( and the same story..
the initial screen just flashes and the gadget turns off after a sec .. when with lock off (see below)
Tried to start it with the SD card and the lock off
this gives the following message:
xDuoo X3 Rockbox Boot
Version d312ba8M-1603
Mounting disk ...
Loading firmware ...
Error: File not found
btw: re Rockbox version ...
is it ok to use this version:
http://xvtx.ru/rockbox/download.htm
or this one:
https://build.rockbox.org/data/rockbox-xduoox3.zip
https://download.rockbox.org/daily/xduoox3/rockbox-xduoox3.zip
the size differs dramatically
-
Tried to start it with the SD card and the lock on
this gives the following message:
xDuoo Audio
Digital audio player
It even started once here ... that got off again .. via "hard reset" button I was able to make it until "Updating .. do not power off" but then it went off again :( and the same story..
This tells me that your player itself has most likely suffered a hardware failure, if the OF can't even boot up and run properly. (BTW there was no need to re-flash the firmware..)
btw: re Rockbox version ...
is it ok to use this version:
http://xvtx.ru/rockbox/download.htm
or this one:
https://build.rockbox.org/data/rockbox-xduoox3.zip
https://download.rockbox.org/daily/xduoox3/rockbox-xduoox3.zip
the size differs dramatically
the xvortex "initial setup" is the only working OF image patched with the bootloader, so that is necessary to get going. Once that is flashed, however, use the rockbox daily builds, as they are much newer than what xvortex has on his web site.
-
well I somehow made it work ... I can boot to the original one (even tho it still tries to look for the Rockbox - dunno why - when I have the lock off)
with the daily builds -> can I use them right away? or as an update on top of the vortex?
-
with the daily builds -> can I use them right away? or as an update on top of the vortex?
I'd recommend just nuking the .rockbox directory entirely and starting over with the latest daily build.
Another option is to use one of the builds put out by Igor Poretsky -- His builds are generally stable, but his tree has a lot of additional patches that aren't upstreamed. (I've merged many of those patches in one form or another, but many remain..)
(There's nothing wrong with the vortex build; it's just quite old at this point. Also, because it was built from an unknown source tree, I can't promise there won't be any subtle issues doing an in-place upgrade due to stale files)
-
thx I will try it tmrw and let you know .. thx a lot for the help :)
-
hmm weird but it's working :) I used the daily build and it seems to be fine ... thx a lot !!
-
(I'll try posting here but would be happy to told of a better place - it might not be X3-specific)
I have an X3 which I seem to have bot in a funny state. It was a while ago and I am revisiting it now, so I am not fully sure how it happened.
I have Rockbox on an SDcard and with the lock switch set to UNLOCKED I can boot to RB fine. But if try to boot to the stock firmware (switch LOCKED), nothing happens, the screen stays blank.
Presumably there is a problem with the bootloader?
I would like to have the option to boot to stock (accessing 2nd SDcard, and USB access seems better). But I think this needs me to boot the stock firmware to update the bootloader ... which I can't do.
What are my best options here please? Thanks a lot
-
D'oh - strike the above - I got it sorted. Typically, not long after making the posting.
I ended up getting X3-USBBurntool working; it was a bit of a faff because I had to do it under a VM, and getting the USB drivers etc. installed took a while. But I am back where I want to be.
Apologies for the noise.
-
I ended up getting X3-USBBurntool working; it was a bit of a faff because I had to do it under a VM, and getting the USB drivers etc. installed took a while. But I am back where I want to be.
I'm glad you managed to get X3-USBBurntool working and recovered the OF on your unit.
But given that rockbox doesn't touch the onboard flash at all, it's most likely that the flash was corrupted by something within the OF itself.
(BTW, recent dev builds should be _faster_ with respect to SD and USB operation than the OF, and exporting/mounting both SD cards WorkForUs(tm) just fine too..)
-
Hallo
I have a one question. I would like to ask if somebody else noticed issue with audio quality with sample rate 44,1kHz. If I compare it with original firmware there is noticable less treble and less details. Old XVortex version of Rockbox sound similar like original firmware (better then last versions, I have on one SD card XVortex version and on second SD new version). It is also very easy noticable if you have file with sample rate 88kHz and switch it to 44kHz, but this problem is also with original files 44kHz. I listen on senn HD600 with external headamp (through line out from xDuoo X3). Sorry for my English..
-
^^^ usually more helpful if you get a 3.5 mm cable and measure the output in RMAA. The it is obvious what is wrong.
-
I suspect what's going here is that rockbox currently enables the de-emphasis filter of the X3's CS4398 DAC.
(see https://statics.cirrus.com/pubs/proDatasheet/CS4398_F2.pdf, section 7.3.2)
Whether or not this is "correct" is a matter of how the source material was mastered, but generally speaking, if it was mastered for CDs or DAT (ie just about everything) then use of this filter is appropriate (and expected!) to bring the frequency response back to neutral.
I'm willing to change this, but first I'm going to need to see some sort of test evidence (eg a total sweep run through RMAA) that shows that this behaviour is wrong..
In the mean time, Rockbox has a built-in equalizer function that you can use to tune the output to your liking.
-
I'm willing to change this, but first I'm going to need to see some sort of test evidence (eg a total sweep run through RMAA) that shows that this behaviour is wrong..
To follow up to myself, it seems that "modern" [1] audio CDs rarely use pre-emphasis, so this filter probably shouldn't be enabled by default.
[1] loosely meaning "mastered digitally", ie not from an analog recording. Nearly everything since the late 80s qualifies, with the notable exception of classical music which still tends to be pre-emphasized.
-
Yes. I can corfim that this issue was the de-emphasis filter. Now it sounds OK (i am not able notice any difrence between original and rockbox). I read taht this re-emphasis filter used to be aplay on very old CD with only 14 bits resolution. I think that it is not necessary have this optional turn it on.. Thank you very much for your quick solution.
-
I have one more question. How it is with hi-res 24bit files. Are they converted to 16bit before sending to DAC or full path is 24 bit?
-
Also there is still problem with 192kHz (also 176,4kHz) files. Some of them are skip, some of them „only“ crackle, and sometime xDuoo X3 use complete to freeze. Maybe if there is not posible alocate more memory (or other necesseary sources), would by better switch them automaticaly to 96 or 88kHz (if I swith frequency manualy then crackle is away, but skiping fiels are still skipping).
-
I have one more question. How it is with hi-res 24bit files. Are they converted to 16bit before sending to DAC or full path is 24 bit?
Decoding is done at 32 bit precision but everything is dithered down to 16 bit for playback because we never had a device that could actually play back the 17bit or greater above the noise floor. Adding support for this would be neat, but would make little difference in practice.
Also there is still problem with 192kHz (also 176,4kHz) files. Some of them are skip, some of them „only“ crackle, and sometime xDuoo X3 use complete to freeze.
Depending on the format, the CPU is probably not fast enough to decide those files, respect on MIPS where there are few cosec optimizations. The test_codec tool can be used to benchmark codecs, although it forces you to compile your own build.
-
I confirm the crackle @ 192kHz. I checked the Buffering Thread in the debug menu. The bar is always >= 95%, i.e. constantly refilling. I suppose this is what keeps the device too busy.
Edit: the X3 only shows PCM (which for the X3ii also is always close to 100%).
The other two bars in the X3ii are not shown for X3.
Edit2: Not that I care too much about such sampling rates ...
-
Also there is still problem with 192kHz (also 176,4kHz) files. Some of them are skip, some of them „only“ crackle, and sometime xDuoo X3 use complete to freeze. Maybe if there is not posible alocate more memory (or other necesseary sources), would by better switch them automaticaly to 96 or 88kHz (if I swith frequency manualy then crackle is away, but skiping fiels are still skipping).
The reason for the "crackle" at higher data rates is that the the X3 can't keep the audio codec fed under high loads -- by the time we are able to start servicing the interrupt that tells us the audio buffer needs more data, it's already too late.
(Basically, we need double-buffered DMA at the hardware level, and the DMA controller in the jz4760 does _not_ support this.. but their newer SoCs do. There are some other games we can still try to work around this but they all require a significant rework of the low level asm interrupt handling)
-
Hallo
I would like to ask if bootloader are the same like Vortext version or if it is new one. I noticed in „major changes“ these sentence: „2021-08-26: xduoox3: Disable bootloader USB mode entirely, Bootloader improvements“. But the rockbox utility (1.5.1 and 1.5.0) shut down (without any error message) after I try install bootloader. I think that it is the same problem like in this article: https://www.reddit.com/r/rockbox/comments/10quizp/help_installing_on_xduoo_x3/
-
I wonder what happened, worked fine for 3 year and now i tried everything cant make it work,any help?