Greetings, dear sound modifications developers for Android OS. We want to ask you a few questions about feasibility and performance of some components inside your audio mods. We are very interested in features and their structure, resources & components. We are not great experts in the .nix systems. Simply, there are some situations what uncertainty is obvious even to a child. Let's start in order:
For the convenience of questions will be numbered
#1. The first thing we would like to know, what is the point from the availability of binaries and libraries of application-players in system/lib? Even if it is working, why would you add a library from Onkyo HF? This media application is an exclusive for their headphones & amplifiers, as well as their player app. It does not have unique properties such as hi-res audio, and other "goodies". And we didn't find any circuits and connections, including those libs. Neither of the players does not become system directories, and if treated - what for? For the purpose of hardware decoding built by resampler at the level of the system to replace a core staff of the mixer? After all, the application has its own lib, furthermore - it was is not able to originally bypass ALL system. Only FX chain. This problem seems very paradoxical.
#2.Beats Audio. The first thing you need to consider - is deep binding of Beats api in flinger and srsfx library. If we open the original file from the M7 - we see that the effect starts with reference to sub_16A44 (substream?), and then goes on distributing multi-channels. And that's just for the first observations. In any case, even just to "rip" these lines is not possible (the only one who did something on porting it was @sun_dream). Well, we can replace the HTC M8 flinger with beats one entirety – it will work (probably the same trick will work with other 801qualc's). But this trick works only under 5.0 OS – why did you say it is confirmed for MM? Besides, if we can set a modification to smartphone that already has beats by default the same configs replace themselves and this trick is not fully presented in the updater scripts. Furthermore – we are embarrassed with presence of "dummy-binaries" / bin / beatsbass, / bin / beatsnormal, / bin / spkamp, / bin / snd… etc. System will work safely without them, and their presence is not giving any help to set effects (beats, sony, etc) working.
#3.SRS. From small analyze dozen all-different versions, we have not seen a competent implementation of this technology. As well as previously mentioned beats, srs is proc-dependent (and any other libs) – so this will never work on Exynos or Mediatek as most of the technologies are deeply tied the same libaudioflinger. For samopisny or donorskiy. Even if it is working properly there are very interesting thing going in configs, for example Project Yume (probably all other mods by @PDesire) the eg compressor value is 15000. Why?? While the maximum is only 1! We consider these (and most of the libs) just "hanging" in the system and wasting its space. After al, speaking of SRSl, we should not forget that the SRS prefers Little Endian, while some fashion mods exhibit Float_64 (sic!) with unrealistic resampling.
#4.Sony DSEE-HX, Sony LDAC and other software technologies by Sony. Why it is presented for universal modifications, as its various types are unique for devices based on qualcomm? Or have you forced to work DSEE-HX, wired directly into the hardware libraries sony? If secret - how? There are no deep links with the system, or any other implementation. The only truly working tech port srom sony is – but even with this thing you should be careful. LDAC is hw implementation only.
#5. Alsa. As the developers, you know that Mediatek and Exynos does not have full alsa (the one you stick in your mods). In the low-level code at the kernel level they work within tinyalsa. While "usr" folder in your mods is designed to work in Qualcomm
environment. So there will never be any sampling above those, that MTK or Exynos got by default!
№ 6.Stegefright-decoders are not spelled out in media_codecs.Simple presence in system will not give an effect.
№ 7. 24/192 is impossible without touching a "true-low-level".Alsa isnt working on 90% devices,we was talking about this in previous number
We don't want to discredit anyone - maybe we missed something. We really wonder how mod authors have coped with porting many libraries. However, at this moment it looks more like a fraud and exorbitant increase in the system partition with a bunch of garbage files.
Sorry for our bad English.
With regards,
Android Modders from the Other Side.If you have questions-ask me.
@ahrion @Ben Feutrill @guitardedhero @PDesire @androidexpert35 @DeadRod @anandmore @A.R.I.S.E. Sound Systems @TheRoyalSeeker @mrchezco1995 @Hani K. and others.
For the convenience of questions will be numbered
#1. The first thing we would like to know, what is the point from the availability of binaries and libraries of application-players in system/lib? Even if it is working, why would you add a library from Onkyo HF? This media application is an exclusive for their headphones & amplifiers, as well as their player app. It does not have unique properties such as hi-res audio, and other "goodies". And we didn't find any circuits and connections, including those libs. Neither of the players does not become system directories, and if treated - what for? For the purpose of hardware decoding built by resampler at the level of the system to replace a core staff of the mixer? After all, the application has its own lib, furthermore - it was is not able to originally bypass ALL system. Only FX chain. This problem seems very paradoxical.
#2.Beats Audio. The first thing you need to consider - is deep binding of Beats api in flinger and srsfx library. If we open the original file from the M7 - we see that the effect starts with reference to sub_16A44 (substream?), and then goes on distributing multi-channels. And that's just for the first observations. In any case, even just to "rip" these lines is not possible (the only one who did something on porting it was @sun_dream). Well, we can replace the HTC M8 flinger with beats one entirety – it will work (probably the same trick will work with other 801qualc's). But this trick works only under 5.0 OS – why did you say it is confirmed for MM? Besides, if we can set a modification to smartphone that already has beats by default the same configs replace themselves and this trick is not fully presented in the updater scripts. Furthermore – we are embarrassed with presence of "dummy-binaries" / bin / beatsbass, / bin / beatsnormal, / bin / spkamp, / bin / snd… etc. System will work safely without them, and their presence is not giving any help to set effects (beats, sony, etc) working.
#3.SRS. From small analyze dozen all-different versions, we have not seen a competent implementation of this technology. As well as previously mentioned beats, srs is proc-dependent (and any other libs) – so this will never work on Exynos or Mediatek as most of the technologies are deeply tied the same libaudioflinger. For samopisny or donorskiy. Even if it is working properly there are very interesting thing going in configs, for example Project Yume (probably all other mods by @PDesire) the eg compressor value is 15000. Why?? While the maximum is only 1! We consider these (and most of the libs) just "hanging" in the system and wasting its space. After al, speaking of SRSl, we should not forget that the SRS prefers Little Endian, while some fashion mods exhibit Float_64 (sic!) with unrealistic resampling.
#4.Sony DSEE-HX, Sony LDAC and other software technologies by Sony. Why it is presented for universal modifications, as its various types are unique for devices based on qualcomm? Or have you forced to work DSEE-HX, wired directly into the hardware libraries sony? If secret - how? There are no deep links with the system, or any other implementation. The only truly working tech port srom sony is – but even with this thing you should be careful. LDAC is hw implementation only.
#5. Alsa. As the developers, you know that Mediatek and Exynos does not have full alsa (the one you stick in your mods). In the low-level code at the kernel level they work within tinyalsa. While "usr" folder in your mods is designed to work in Qualcomm
environment. So there will never be any sampling above those, that MTK or Exynos got by default!
№ 6.Stegefright-decoders are not spelled out in media_codecs.Simple presence in system will not give an effect.
№ 7. 24/192 is impossible without touching a "true-low-level".Alsa isnt working on 90% devices,we was talking about this in previous number
We don't want to discredit anyone - maybe we missed something. We really wonder how mod authors have coped with porting many libraries. However, at this moment it looks more like a fraud and exorbitant increase in the system partition with a bunch of garbage files.
Sorry for our bad English.
With regards,
Android Modders from the Other Side.If you have questions-ask me.
@ahrion @Ben Feutrill @guitardedhero @PDesire @androidexpert35 @DeadRod @anandmore @A.R.I.S.E. Sound Systems @TheRoyalSeeker @mrchezco1995 @Hani K. and others.
from xda-developers http://ift.tt/2ashcYe
via IFTTT
Aucun commentaire:
Enregistrer un commentaire