[linuxworks]

disclaimer: I am a software and firmware developer (but not for fiio)
 
fiio: I am willing to bet I know why your scroll wheel is slow and sloppy.  if you want to see the better algorithm for how to scan the rotary encoder, PM me.  I have a table-driven bit of code that works very well and does not have the slop that most commercial rotary encoders seem to have.
 
I'm happy to just give you the code and explain how to use it (its regular C).  would you be willing to have your engineers try this version out, even on a limited alpha test?

 

[linuxworks]

my wish-list for the x3-2:
 
I'd like to have CTIA remote control function (on the left hand side trrs jack) even when the right-hand side is inserted and running either line-out or coax/spdif out.
 
I'd like to see the scroll wheel be more responsive and not show the 'bounce' problem it now has.
 
OTG support should be improved.
 
there are some issues with spdif-out.  I have not figured it out yet, but sometimes I am not able to get lock on my external spdif switches and dacs.  I could help you debug this if you are interested.
 
more on remote control: it would be great if there was a usb interface for full remote control (getting current song info, playlist info, shuttle control, etc).  not audio thru usb (you already have that) but using usb as a CONTROL CHANNEL.  I may be the only one wanting it (lol) but it would be a major product differentiator.
 
I'm not sure yet, but I am seeing something that looks like dc-offset on the phones-out jack.   I'll have to look further.  I'm feeding the phones-out into my preamp (because of the remote control feature that I want) and when I am getting closer to 0db on my preamp, I'm hearing a LOT of clicks (my preamp is relay based).  this almost always indicates dc offset issues.  maybe its ok for phones-out; and I'm not saying line-out has offset issues; but does the phones-out block dc well enough?  I think you guys just use simple caps for blocking.  if that's the case, I should not see any dc offset.  so I'm slighly puzzled.
 
I'd like a simple screen background WITHOUT any texture to it.  I'm a simple UI person (lol) and would like to have just a black background with green or amber text.  old school vt220 style
 
 
that's it for my current wish-list.

 

[ngs428]

disclaimer: I am a software and firmware developer (but not for fiio)

fiio: I am willing to bet I know why your scroll wheel is slow and sloppy.  if you want to see the better algorithm for how to scan the rotary encoder, PM me.  I have a table-driven bit of code that works very well and does not have the slop that most commercial rotary encoders seem to have.

I'm happy to just give you the code and explain how to use it (its regular C).  would you be willing to have your engineers try this version out, even on a limited alpha test?

Send a pm to JamesFiiO or Joe Bloggs just to make sure they see it if you like.

I would like them to see it!

 

[DDDamian]

I'll throw in a couple of requests:
 
- ReplayGain processing: the shuffle and playlists have been available since the first-gen products but can lead to some scrambles to adjust volumes when genres or recording levels change as they will. Would be glad to point out open-sourced code samples as it's easy to implement once the tags are read
 
- Larger fonts: the X5ii improved a lot as far as screen brightness over other models and has a larger size than the X3ii, but I purchased an X3ii for my father in his 70's and heck, I can't read it very well. I realize this may be hard to do depending on how the GUI software is structured, but I'll throw it out there
 
- Cross-feed: another easy-to-implement feature. Again, would be happy to supply open-sourced code. I have my own which I'd be happy to donate if the original code-base is C++ and you're using floating-point processing. If it's integer-processing I can only wish

 

[Zweistein]

Bug report: equalizer can't make up its mind when switching to line-out. I noticed this with the stable firmware, upgraded to 1.16beta, and it's slightly worse. To reproduce:
1. Have the "Multifunctional outputs" set to Line out, but don't plug that in yet.
2. Listen on headphone out, with an active equalizer profile that you can easily recognize.
3. Plug in the line-out cable while playing. Output is rerouted to line-out and the equalizer switches off automatically (which is a feature I like). As an aside: in 1.1, the "now playing" screen makes this clear by switching the EQ tag to Off; in 1.16 it's stuck on the previously active equalizer profile.
4. Switch to normal 44.1kHz sample rate files (CD rips, flac, mp3, m4a encoded...). The equalizer still doesn't interfere with the line out signal.
5. Switch to a file with 48kHz or 32kHz sampling rate. Now the equalizer kicks back in. It continues equalizing if you switch back to the files from step 4.
6. Switch to a very high-res file that the equalizer doesn't support a (e.g. 96kHz sampling rate). Of course the equalizer backs off again.
7. Switch to the same files as in step 5. This time they're played without equalization.
 
It doesn't make sense to me why this should happens, but in any case, if you're comparing a modestly equalized headphone out signal with the line out signal, be aware that the equalizer may be fooling you, regardless of what the screen says. Explicitly turning off the equalizer when switching to line-out seems safe. But that is hard with firmware 1.1: it's only possible to choose the equalizer if you're already in the equalizer settings while plugging into line-out. In 1.16, you can reactivate it at will.

 

[420204]

  - Cross-feed: another easy-to-implement feature. Again, would be happy to supply open-sourced code. I have my own which I'd be happy to donate if the original code-base is C++ and you're using floating-point processing. If it's integer-processing I can only wish

we need more people like you!
@JamesFiiO @Joe Bloggs do you ever consider third party development? because somewhere in this thread there was someone else offering you his code for faster scrolling. two new features, your customer requested.

 

[linuxworks]

I never heard from anyone at fiio about the scroll wheel issue.
 
the issue is that rotary encoders have 4 states as you turn the knob and a lot of the wheel devices out there only seem to track the 2 obvious main states, but by taking that short-cut you miss the middle states and those help stabilize the wheel.
 
you also need to be able to get interrupts OR poll the wheel (2 digital lines) fast enough.  if they are polling and their big poll loop can't 'come around' fast enough, you'll lose events and there may not be much that can be done about it.
 
otoh, if they have coded the wheel with 2 states and are willing to try it with 4, its not a lot of code and I'd be happy to help out if that's possible.
 
here is the big hint:
 
https://www.circuitsathome.com/mcu/reading-rotary-encoder-on-arduino
 
and the special sauce:
 

 [color=#993333]int8_t[/color] read_encoder[color=#009900]([/color][color=#009900])[/color] [color=#009900]{[/color] [color=#993333]static[/color] [color=#993333]int8_t[/color] enc_states[color=#009900][[/color][color=#009900]][/color] [color=#339933]=[/color] [color=#009900]{[/color][color=#0000dd]0[/color][color=#339933],-[/color][color=#0000dd]1[/color][color=#339933],[/color][color=#0000dd]1[/color][color=#339933],[/color][color=#0000dd]0[/color][color=#339933],[/color][color=#0000dd]1[/color][color=#339933],[/color][color=#0000dd]0[/color][color=#339933],[/color][color=#0000dd]0[/color][color=#339933],-[/color][color=#0000dd]1[/color][color=#339933],-[/color][color=#0000dd]1[/color][color=#339933],[/color][color=#0000dd]0[/color][color=#339933],[/color][color=#0000dd]0[/color][color=#339933],[/color][color=#0000dd]1[/color][color=#339933],[/color][color=#0000dd]0[/color][color=#339933],[/color][color=#0000dd]1[/color][color=#339933],-[/color][color=#0000dd]1[/color][color=#339933],[/color][color=#0000dd]0[/color][color=#009900]}[/color][color=#339933];[/color] [color=#993333]static[/color] [color=#993333]uint8_t[/color] old_AB [color=#339933]=[/color] [color=#0000dd]0[/color][color=#339933];[/color] [i][color=#808080][i]/**/[/i][/color][/i] old_AB [color=#339933]<<=[/color] [color=#0000dd]2[/color][color=#339933];[/color] [i][color=#666666][i]//remember previous state[/i][/color][/i] old_AB [color=#339933]|=[/color] [color=#009900]([/color] ENC_PORT [color=#339933]&[/color] [color=#208080]0x03[/color] [color=#009900])[/color][color=#339933];[/color] [i][color=#666666][i]//add current state[/i][/color][/i] [color=#b1b100]return[/color] [color=#009900]([/color] enc_states[color=#009900][[/color][color=#009900]([/color] old_AB [color=#339933]&[/color] [color=#208080]0x0f[/color] [color=#009900])[/color][color=#009900]][/color][color=#009900])[/color][color=#339933];[/color] [color=#009900]}[/color]

 
 
I use that code, myself, in my own devices and firmware and even without interrupts, I never miss any rotary events, no matter how fast the user turns the wheel.
 
perhaps the fiio guys could look at this and see if its how they do their decoding of the rotary.  otoh, if they are already doing this, then they could be limited by lots of other reasons.
 
sure wish the rotary 'feel' was given first priority when spec'ing out the system architecture.  crispness of a UI seems to be a forgotton or lost art in today's consumer electronics ;(

 

[ngs428]

I never heard from anyone at fiio about the scroll wheel issue.

the issue is that rotary encoders have 4 states as you turn the knob and a lot of the wheel devices out there only seem to track the 2 obvious main states, but by taking that short-cut you miss the middle states and those help stabilize the wheel.

you also need to be able to get interrupts OR poll the wheel (2 digital lines) fast enough.  if they are polling and their big poll loop can't 'come around' fast enough, you'll lose events and there may not be much that can be done about it.

otoh, if they have coded the wheel with 2 states and are willing to try it with 4, its not a lot of code and I'd be happy to help out if that's possible.

here is the big hint:

https://www.circuitsathome.com/mcu/reading-rotary-encoder-on-arduino

and the special sauce:

[COLOR=993333]int8_t[/COLOR] read_encoder[COLOR=009900]([/COLOR][COLOR=009900])[/COLOR]
[COLOR=009900]{[/COLOR]
 [COLOR=993333]static[/COLOR] [COLOR=993333]int8_t[/COLOR] enc_states[COLOR=009900][[/COLOR][COLOR=009900]][/COLOR] [COLOR=339933]=[/COLOR] [COLOR=009900]{[/COLOR]0[COLOR=339933],-[/COLOR][COLOR=0000DD]1[/COLOR][COLOR=339933],[/COLOR][COLOR=0000DD]1[/COLOR][COLOR=339933],[/COLOR]0[COLOR=339933],[/COLOR][COLOR=0000DD]1[/COLOR][COLOR=339933],[/COLOR]0[COLOR=339933],[/COLOR]0[COLOR=339933],-[/COLOR][COLOR=0000DD]1[/COLOR][COLOR=339933],-[/COLOR][COLOR=0000DD]1[/COLOR][COLOR=339933],[/COLOR]0[COLOR=339933],[/COLOR]0[COLOR=339933],[/COLOR][COLOR=0000DD]1[/COLOR][COLOR=339933],[/COLOR]0[COLOR=339933],[/COLOR][COLOR=0000DD]1[/COLOR][COLOR=339933],-[/COLOR][COLOR=0000DD]1[/COLOR][COLOR=339933],[/COLOR]0[COLOR=009900]}[/COLOR][COLOR=339933];[/COLOR]
 [COLOR=993333]static[/COLOR] [COLOR=993333]uint8_t[/COLOR] old_AB [COLOR=339933]=[/COLOR] 0[COLOR=339933];[/COLOR]
 [I][COLOR=808080][I]/**/[/I][/COLOR][/I]
 old_AB [COLOR=339933]<<=[/COLOR] [COLOR=0000DD]2[/COLOR][COLOR=339933];[/COLOR] [I][COLOR=666666][I]//remember previous state[/I][/COLOR][/I]
 old_AB [COLOR=339933]|=[/COLOR] [COLOR=009900]([/COLOR] ENC_PORT [COLOR=339933]&[/COLOR] [COLOR=208080]0x03[/COLOR] [COLOR=009900])[/COLOR][COLOR=339933];[/COLOR] [I][COLOR=666666][I]//add current state[/I][/COLOR][/I]
 [COLOR=B1B100]return[/COLOR] [COLOR=009900]([/COLOR] enc_states[COLOR=009900][[/COLOR][COLOR=009900]([/COLOR] old_AB [COLOR=339933]&[/COLOR] [COLOR=208080]0x0f[/COLOR] [COLOR=009900])[/COLOR][COLOR=009900]][/COLOR][COLOR=009900])[/COLOR][COLOR=339933];[/COLOR]
[COLOR=009900]}[/COLOR]

I use that code, myself, in my own devices and firmware and even without interrupts, I never miss any rotary events, no matter how fast the user turns the wheel.

perhaps the fiio guys could look at this and see if its how they do their decoding of the rotary.  otoh, if they are already doing this, then they could be limited by lots of other reasons.

sure wish the rotary 'feel' was given first priority when spec'ing out the system architecture.  crispness of a UI seems to be a forgotton or lost art in today's consumer electronics ;(

JamesFiiO Joe Bloggs. Hope you are able to reply to the post I am quoting. If this will help operation of the scroll wheel then you were given a nice gift!

 

[linuxworks]

well, like I said, its a long-shot and lots depends on how their system is designed to work and how they read the encoder.
 
but it does seem very much like when I tried reading rotaries and only used two states instead of 4.  that, and lack of frequent enough polling of the 2 lines on the rotary would cause events to be missed if the user turned too fast.  and also, I think that the 4 states style helps reduce edge noise or false state-changes.
 
so, we might get lucky and maybe they could use this algorithm.  otoh, if they are already using it, then there's not much else that I can think of that would help with missed rotary events.

 

[Joe Bloggs]

well, like I said, its a long-shot and lots depends on how their system is designed to work and how they read the encoder.

but it does seem very much like when I tried reading rotaries and only used two states instead of 4.  that, and lack of frequent enough polling of the 2 lines on the rotary would cause events to be missed if the user turned too fast.  and also, I think that the 4 states style helps reduce edge noise or false state-changes.

so, we might get lucky and maybe they could use this algorithm.  otoh, if they are already using it, then there's not much else that I can think of that would help with missed rotary events.

Hello linuxworks,

Thanks a lot for your input and I have forwarded your suggestion to the programmers. Hope they are able to make use of it


Joe

 

[Romani]

I'm curious how many people would be upset if the default action of the scroll wheel on the now playing screen was to change volume rather than to scroll through the album? It seems like this would make much more sense.

Perhaps allow the user to choose which setting they are changing in some menu?

I've been wanting that since my original X5. I would be over the moon if that was implemented. My biggest gripe continues to be fast scrolling through letters in the Category menu.

 

[Romani]

I am of the opinion that the scroll wheel responsiveness on the X3 2nd gen is spot on. If anyone thinks it's below par, go and try the X5 2nd gen with the Equaliser switched on. I ended up with my X3 in the last 48 hours because of the UI and sound improvements. Strange considering the X5 is supposed to be the top end device.

 

[linuxworks]

there are two tell-tales about incorrect rotary encoder handling:
 
1) turning too fast causes skipped events, possibly even moving you backwards
 
2) turning too slow causes false events and 'bounce'
 
 
sadly, both of those problems exist on the x3-2 wheel.  pretty odd that even turning it slow and carefully causes bounce and double/partial events.  I keep saying this, but my gut feeling is that if they were using 4 states in the state-table, that the slow-term bug would not happen.
 
the fast-turn bug mostly depends on having a fast enough polling loop to keep checking for value changes on the A and B encoder lines.
 
I often expect to see the 'too fast' bug but its upsetting to see the too-slow bug, as well.
 
 
I'll say this: if it was my product and I was the QA guy or product release guy on a device like this, I would hold back shipment until either the scroll wheel 'feels good' to an average user; OR I'd dump the whole idea and go back with up/down style buttons.
 
to me, the user interface is defined and implemented first.  you test the UI to see if it feels snappy enough.  if not, you don't move on to step-2 (building the rest of the player); you stay at the UI design and test phase UNTIL the ui feels as good as you can make it.  maybe you find that you need 2 extra pin-change interrupts.  perhaps you need a co-processor to keep track of the wheel and other buttons.  maybe you need multi buffering.  maybe you need shared memory.  lots of things to think about to 'fix' a slow UI.
 
my point is that the ui snappiness is often ignored by all the vendors, these days.  google, apple, you name it.  they do NOT design a UI and test its responsiveness first; they think they are good engineers (well, they think so, anyway) and so their hubris stops them from admitting that X or Y or Z is slowing things down and the user experience is not as good as it could have been.  marketing and business guys also force shipment schedules that are not realistic and sometimes engineers are caught in the middle; even if they want to do the right thing and redesign the UI system, the business guys will often say 'its good enough, just ship it!'.  and this is what we get...
 
I design and build product (one-off stuff, not high volume) but I DO spend time on the UI and I won't even continue with the rest of the system if the UI does not feel quick, responsive and even fun.  I will go back and try other UI elements if the ones I first tried are too slow or need too much cpu time to get things done.  but this approach is very rare in the 'time to market!' industry we are in.
 
still, it would be nice to find a vendor who spends time on the UI and won't move to the 2nd phase until the UI is as responsive as possible, within human factors levels of speed.
 
I'm reminded of the logitech duet (I still have 2 full duet systems that I am not using; anyone looking for one?  lol) remote.  they also had the world's worst rotary encoder and it was the most un-fun thing to use that I had, at the time.   with all the money logitech had (r/d, existing product design knowledge base) they STILL shipped one of the worst rotary encoder products on the earth.  and for a high priced luxury item, they really pulled an 'amazon fire-phone' (LOL, sorry) on that one.
 
 
now, if the player was open-source, it might be interesting to see if the users could fix some of the design and implementation issues.  but I am not holding my breath; and I know that if the company has not done an open source toolkit for their players in the past, they are unlikely to in the future.   sure wish this player was rock-box friendly. 

 

[Joe Bloggs]

there are two tell-tales about incorrect rotary encoder handling:

1) turning too fast causes skipped events, possibly even moving you backwards

2) turning too slow causes false events and 'bounce'


sadly, both of those problems exist on the x3-2 wheel.  pretty odd that even turning it slow and carefully causes bounce and double/partial events.  I keep saying this, but my gut feeling is that if they were using 4 states in the state-table, that the slow-term bug would not happen.

Maybe it's not sad... it might mean your piece of code already holds the key to improvement, as opposed to there being some other obscure problem If that does the trick we have a lot to thank you for

Now, as for open-sourcing the player, that would have meant designing the product from the ground up with parts that would agree to be open-sourced

 

[linuxworks]

Now, as for open-sourcing the player, that would have meant designing the product from the ground up with parts that would agree to be open-sourced

it does not have to be all-or-nothing.  you could make a linkable library available (or just some .o files) and some headers and draw a line where the source ends and binary blob begins.  it happens enough that its an understood problem.
 
talking to the SoC chips is asking a lot; so give an api that abstracts things and gives enough control so that a user (programmer) could write an event loop and handle things that they want, display to the screen what they want, etc.
 
it would take some work to create that abstraction; but on the plus side, once you did that, you could spend less effort and time on the UI since that part could be open and you'd get many volunteers to add neat features at the UI side.  you guys would spend your time fixing bugs that are below the api level and getting that layer rock solid.
 
the vendor has to want that and see value in it, and budget for its people and how the source code control system works, how the bug reporting system works, etc.  a public and private 'view' would be useful; but this is all already solved and many companies do this.  hell, the android model is like this; they give api access to things but we'll NEVER see real access to the radio and gfx system.  that part will be closed source and always will be.  but if the api abstraction is sufficient, it would not be a problem.
 
anyway, something to think about.  if you got some open source guys on the payroll and ones that had done this before, you could pull it off.