or Connect
Head-Fi.org › Forums › Equipment Forums › Portable Source Gear › Rockbox for iBasso DX50 dual boot with stock firmware
New Posts  All Forums:Forum Nav:

Rockbox for iBasso DX50 dual boot with stock firmware - Page 100

post #1486 of 1976
yah thats what im trying to say, avoid mixed up information like what happened on the main dx50 thread..
post #1487 of 1976
OK but.. Are you saying that there are no sound differences between rockbox and stock firmware?

Because in my case the difference was really BIG! (Mango vs rockbox)
post #1488 of 1976
Quote:
Originally Posted by mp3 View Post
 

I restored ..

 

ETA, got it working.

good to hear)

 

 

Quote:
Originally Posted by saratoga View Post
 

 

he actually did anything.  

Do you have DX50 with some headphones?(headphones is important part because seems like headwhacker has DX50 but does not have any headphones :rolleyes:)

 

 

Quote:
Originally Posted by saratoga View Post
 

 

 its easy to RMAA something like this.  

I'll try to get results in my free time. It's not so easy - windows is needed :)

 

 

Quote:
Originally Posted by ArgelErx View Post
 

 

Yes. Rockbox uses the Android Kernel level ALSA interface. Of the Wolfson DAC.

 

Could please provide link to Android Kernel level ALSA interface of the Wolfson DAC specification?
You couldn't because there is no this kind of specification.

Which profit we have using ALSA? Do you understand that PCM part implemended by you is DAC-independent?
I can "google" for you. http://www.alsa-project.org/main/index.php/ASoC

oh no, where is DAC-dependent code where you use system shell to talk with device specific codec, for example

Quote:
#if defined(DX50)
    FILE *f = fopen("/dev/codec_volume", "w");
#else /* DX90 */
    FILE *f = fopen("/sys/class/codec/es9018_volume", "w");
#endif  /* DX50 */

Do you understand what if you replace your WM8740 with WM8741 your code(and device) will be work? (not sure about volume control :))

 

 

Quote:
Originally Posted by headwhacker View Post
 

 

Sorry to burst your bubble but your are exhibiting the perfect example of expectation bias (A.K.A. placebo effect).

 

You were told a fix was made to improved sound. That is what you wanted to hear. But ignore the fact the change as pointed out could not affect the sound of Rockbox as any of the part being claimed to have change isn't use by Rockbox.

It's funny story, seems like I have similar for you.

 

Sorry to burst your bubble but your are exhibiting the perfect example of expectation bias (A.K.A. placebo effect).
 
You were told a rockbox direct access to DAC. That is what you wanted to hear(natural virgin sound). But ignore the fact a DX50 rockbox is just a music player app hosted on rockchip platform. Yep, it uses own decoders for different audio formats and talks to pcm using tinyalsa driver but that's all. No any direct access to DAC, again.

 

 

Quote:
Originally Posted by headwhacker View Post
 

 

This is easily can be verified as you know rockbox's code is open source and anyone can verify it.

Really? So I already asked you to provide link to code where rockbox access the DAC. You didn't do it but repeated your claim again and again. How we can verify that rockbox sound is virgin and natural.

 

 

Quote:
Originally Posted by sduck View Post
 

I think it's moot, as medmitry has pulled his version of rockbox, at least from this forum, and edited his posts about it. 

 

I edited only one post because some users have problems with uninstalling fw. that's all.

 
Quote:
Originally Posted by sduck View Post
 

As far as I know, and has been reported elsewhere, all the sound unlocked mod does is add a different EQ curve to the signal..

It was was reported by you on the page 94 (smells weird btw :) )

Quote:
Originally Posted by sduck View Post

Isn't this just some kind of added built in EQ setting? Why not just include it as an optional EQ setting, instead of a baked in non-linear setup? One of the primary features of rockbox is how it doesn't color the sound with baked in sound coloring, but does offer a very full featured EQ. Just include an EQ preset, but don't shove this arbitrary coloration down our throats. Or add an option to turn it off.
 

I already answered to you that the signal is bit-perfect. But glad to hear that you can hear SQ difference, please discuss it with headwhacker.

 

 

 

Quote:
Originally Posted by cub0ne View Post

its just that modifying the default sound lib of rockbox doesn't seem right..yes its opensource but its ROCKBOX and it has its own sound lib..

no any modification of rockbox code. ArgelErx & cholero build has been used. rockbox just has own sound decoders, that's all. I'm not sure that you mean "own sound lib".

 

 

 

Quote:
Originally Posted by headwhacker View Post
 

 

It's not about ... That is exactly what I'm trying to avoid. The main DX50 thread is already littered with too much misinformation and subjective bias. That it's very confusing and mostly misleading for a newbie to read.

Dear, please don't forget about your own thread and your claims :) How we can verify that rockbox has natural virgin sound signal? because you said it? rockbox code didn't show whole information. why? see above. 

 

 

At this moment I don't wanna share an information about any modifications for you, have no interest for this.

 

 

Quote:
Originally Posted by CoiL View Post
 

Unsubscribed. 

My fault that I posted RSU build here :) Sorry. Unsubscribed, too!

post #1489 of 1976
Thread Starter 
Quote:
Originally Posted by Hellkitchen View Post

OK but.. Are you saying that there are no sound differences between rockbox and stock firmware?

Because in my case the difference was really BIG! (Mango vs rockbox)

 

No, it's not Mango compared to rockbox. It's the supposed SU mod for rockbox having a difference against the stock rockbox build for DX50.

post #1490 of 1976
Quote:
Originally Posted by headwhacker View Post
 

 

No, it's not Mango compared to rockbox. It's the supposed SU mod for rockbox having a difference against the stock rockbox build for DX50.

Ah ok so I did understood well

post #1491 of 1976

I'm trying to build a simulator build of the DX50 port and when running make I get a lot of "CONFIG_PLATFORM" redefined errors and make fails:

 

 

 

In file included from /home/x/Desktop/rockbox/rockbox/firmware/export/config.h:601:0,
                 from /home/x/Desktop/rockbox/rockbox/apps/main.c:21:
/home/x/Desktop/rockbox/rockbox/firmware/export/config/sim.h:111:0: warning: "CONFIG_PLATFORM" redefined [enabled by default]
 #define CONFIG_PLATFORM (PLATFORM_HOSTED|PLATFORM_SDL)
 ^
In file included from /home/x/Desktop/rockbox/rockbox/firmware/export/config.h:580:0,
                 from /home/x/Desktop/rockbox/rockbox/apps/main.c:21:
/home/x/Desktop/rockbox/rockbox/firmware/export/config/ibassodx50.h:6:0: note: this is the location of the previous definition
 #define CONFIG_PLATFORM (PLATFORM_HOSTED|PLATFORM_ANDROID)
 ^
In file included from /home/x/Desktop/rockbox/rockbox/firmware/export/storage.h:59:0,
                 from /home/x/Desktop/rockbox/rockbox/apps/main.c:25:
/home/x/Desktop/rockbox/rockbox/firmware/export/hostfs.h:64:5: error: #error Unknown storage driver
 #   error Unknown storage driver
     ^
/home/x/Desktop/rockbox/rockbox/tools/root.make:414: recipe for target '/home/x/Desktop/rockbox/rockbox/build-dir/apps/main.o' failed
make: *** [/home/x/Desktop/rockbox/rockbox/build-dir/apps/main.o] Error 1

post #1492 of 1976

I think nobody tried to build the simulator until now :D. I would have been surprised if it worked. What do you need it for? 

post #1493 of 1976
Quote:
Originally Posted by medmitry View Post
 

Could please provide link to Android Kernel level ALSA interface of the Wolfson DAC specification?

You couldn't because there is no this kind of specification.

 

http://opensource.wolfsonmicro.com/

http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-devices

http://opensource.wolfsonmicro.com/node/6

 

Quote:
 Which profit we have using ALSA? Do you understand that PCM part implemended by you is DAC-independent?

 

Did you actually read that? The whole point is to be hardware independent above the kernel level.

 

Quote:
 oh no, where is DAC-dependent code where you use system shell to talk with device specific codec, for example

 

See links above. 

 

Quote:
 Do you understand what if you replace your WM8740 with WM8741 your code(and device) will be work?

 

Again: The whole point is to be hardware independent.

 

Quote:
 You were told a rockbox direct access to DAC. That is what you wanted to hear(natural virgin sound). But ignore the fact a DX50 rockbox is just a music player app hosted on rockchip platform. Yep, it uses own decoders for different audio formats and talks to pcm using tinyalsa driver but that's all. No any direct access to DAC, again.

 

So you implemented a direct access to the Wolfson DAC for Mango, circumventing the kernel and improving the sound of the player. That's really great. Would you please share your modifications with us so that we can improve Rockbox for iBasso?

 

Quote:
 Really? So I already asked you to provide link to code where rockbox access the DAC. You didn't do it but repeated your claim again and again. How we can verify that rockbox sound is virgin and natural.

 

Would you please share your modifications with us so that we can improve Rockbox for iBasso? Please. Pretty, pretty please.

post #1494 of 1976

do you really think it's "Android Kernel level ALSA interface of the Wolfson DAC"? Could you point using those links above where is wm8740 related part?

Anyway I have better link for you - https://github.com/omegamoon/Rockchip-GPL-Kernel/tree/dcfcc2e1b4a147c2f8b6bb8cf9dec3188d5d5836/sound/soc/rk29

 

Quote:
Originally Posted by ArgelErx View Post

 

Did you actually read that? The whole point is to be hardware independent above the kernel level.

 

And you?

 

Quote:

To achieve all this, ASoC basically splits an embedded audio system into 3 components:

  • Codec driver: The codec driver is platform independent and contains audio controls, audio interface capabilities, codec dapm definition and codec IO functions.
  • Platform driver: The platform driver contains the audio dma engine and audio interface drivers (e.g. I2S, AC97, PCM) for that platform.
  • Machine driver: The machine driver handles any machine specific controls and audio events. i.e. turing on an amp at start of playback.

Do you really think all platform code is hardware independent? How do you use capabilities of specific device?

 

 

 

Quote:
Originally Posted by ArgelErx View Post
 

So you implemented a direct access to the Wolfson DAC for Mango, circumventing the kernel and improving the sound of the player. That's really great.

Did I say anything about direct access? It's just your claim :) 

 

It's my last comment for you. I cannot waste my time for this kind of conversation :(

 

 

Quote:
Originally Posted by ArgelErx View Post

Would you please share your modifications with us so that we can improve Rockbox for iBasso?

 

Would you please share your modifications with us so that we can improve Rockbox for iBasso? Please. Pretty, pretty please.

Already answered. See above.


Edited by medmitry - 1/2/15 at 10:47am
post #1495 of 1976
Quote:
Originally Posted by medmitry View Post
 

do you really think it's "Android Kernel level ALSA interface of the Wolfson DAC"? Could you point using those links above where is wm8740 related part?

Anyway I have better link for you - https://github.com/omegamoon/Rockchip-GPL-Kernel/tree/dcfcc2e1b4a147c2f8b6bb8cf9dec3188d5d5836/sound/soc/rk29

 

Of course you did see the includes for the Wolfson DACs? You do realize, that that code is part of ALSA? You do realize that this is the kernel source?

 

Quote:
 Do you really think all platform code is hardware independent? How do you use capabilities of specific device?

 

You overlooked "hardware independent above the kernel level".

 

Quote:
 Did I said anything about direct access? It's just your claim :) 

 

Well actually you did not say anything about your modifications. We had to guess.

 

So i've just looked at you firmware modifications (correct me if i am wrong):

  1. You changed the init scripts disabling unneeded services and replacing Mango Player with your own settings app.
  2. You introduced new configurations of the Mango playback liberies (libparticle...), switching these configurations with your app. Well actually these are component configurations, enabling/disabling available decoders, like FLAC only mode.
  3. You adjust cpu frequency and scaling governor through the cpufreq interface.
  4. You adjust roll off frequencies and iir bandwidth.

 

1. could be done for Rockbox. Effect on sound is questionable.

2. is not relevant for Rockbox. Rockbox replaces these.

3. is already done in Rockbox. Actually adjustable from the Rockbox settings. Effect on sound is questionable.

4. Was considered but abandoned (http://gerrit.rockbox.org/r/#/c/1048/). IIR bandwith likewise.

 

Quote:
 It's my last comment for you. I cannot waste my time for this kind of conversation :(

 

Well this would have been much easier if you just pointed us to a documentation/explanation of your modifications and its relevance for Rockbox.

 

Quote:
 Already answered. See above.

 

Nope you didn't. Had to reverse engineer your firmware.

post #1496 of 1976
Quote:
Originally Posted by cholero View Post
 

I think nobody tried to build the simulator until now :D. I would have been surprised if it worked. What do you need it for? 

 

Ah ok, was just trying it out to check out some themes. I was able to build an iPod Classic and Cowon D2 simulator though.

 

I have a DX50 coming in and planning on loading Rockbox, very satisified with it running on my iPod Classic.

post #1497 of 1976
Quote:
Originally Posted by ArgelErx View Post
 

So i've just looked at you firmware modifications (correct me if i am wrong):

  1. You changed the init scripts disabling unneeded services and replacing Mango Player with your own settings app.
  2. You introduced new configurations of the Mango playback liberies (libparticle...), switching these configurations with your app. Well actually these are component configurations, enabling/disabling available decoders, like FLAC only mode.
  3. You adjust cpu frequency and scaling governor through the cpufreq interface.
  4. You adjust roll off frequencies and iir bandwidth.

 

1. could be done for Rockbox. Effect on sound is questionable.

2. is not relevant for Rockbox. Rockbox replaces these.

3. is already done in Rockbox. Actually adjustable from the Rockbox settings. Effect on sound is questionable.

4. Was considered but abandoned (http://gerrit.rockbox.org/r/#/c/1048/). IIR bandwith likewise.

 

 

Well this would have been much easier if you just pointed us to a documentation/explanation of your modifications and its relevance for Rockbox.

 

 

Nope you didn't. Had to reverse engineer your firmware.

 

So basically, the only actual audio-related change was something I rejected 2 months ago because it was clearly useless.  

 

This is why secrecy is such a bad idea.  It only wastes everyone else's time.  

post #1498 of 1976
Thread Starter 

^ I was clear from the beginning. the first question was exactly what was "changed". But a huge effort was made to evade the simplest question and preferred to go the route of finger wagging. But I guess it works for him because he's got followers. 

post #1499 of 1976

Why are we still talking about this? Let's get on topic by talking about the device as opposed to other members.

 

I'm sure this has been answered before, but does Rockbox decode audio above 44.1/16 differently than the stock firmware? The only reason I ask is I feel like I notice a difference with a higher bit depth and sample rate with stock, but in Rockbox it sounds the same. I could just be crazy, but that is why I'm asking.

post #1500 of 1976
Quote:
Originally Posted by 7S Cameron View Post
 

I'm sure this has been answered before, but does Rockbox decode audio above 44.1/16 differently than the stock firmware? The only reason I ask is I feel like I notice a difference with a higher bit depth and sample rate with stock, but in Rockbox it sounds the same. I could just be crazy, but that is why I'm asking.

 

You are not crazy. A higher bitdepth is used for sound processing but output is allways 44.1/16.

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Portable Source Gear
Head-Fi.org › Forums › Equipment Forums › Portable Source Gear › Rockbox for iBasso DX50 dual boot with stock firmware