<DocScrutinizer05>
ideally you don't have any of that "automatic" obscure stuff and rather add a simple decent manual EQ
<Pali>
(open source, neon optimized and upstreamed)
<DocScrutinizer05>
alas for IHF we need it since the speakers are so ... tiiiiiny
<Pali>
unless we want that apt-x codec :D:D
<freemangordon>
Pali: so there is AEC on BT handsfree devices?
<Pali>
~AEC
<Pali>
what is AEC?
<freemangordon>
acoustic echo cancel...
<DocScrutinizer05>
freemangordon: _any_ speakerphone handsfree device will have built-in AEC. headet BT doesn't need any such thing
<Pali>
if nokia's pulseaudio does not load any other pa module then, bluetooth audio is handled by bluez and upstream bluetooth pa modules
<Pali>
everything is done by bluetooth HW itself
<freemangordon>
Pali: for sure -voice modue does some BT related magic
Kabouik__ has joined #neo900
<Pali>
if it is doing some voice magic, then only what is needed for modem
<Pali>
audio over bluetooth working fine with upstream PA and upstream bluez without any other nokia SW
<Pali>
(both A2DP and HSP profiles)
<freemangordon>
you tried it on n900?
<Pali>
upstream bluez? or new PA?
<Pali>
what exactly?
<freemangordon>
whatever
<freemangordon>
any of those
<freemangordon>
see, we won;t be able to calibrate the algos
<DocScrutinizer05>
PA BT will work on N900 exactly like on PC
<freemangordon>
if we change the implementation
<Pali>
I have luf bluez (new version of bluez, not bluez5)
Kabouik_ has quit [Ping timeout: 250 seconds]
<DocScrutinizer05>
there's no CPU specific bit rotting in PCM data
<Pali>
and Nokia PA did not modified bluetooth code
<freemangordon>
scratch the BT stuff, the biggest problem is the telephony
<Pali>
(I can check)
<Pali>
anyway I think bluetooth is not problem
<freemangordon>
and most of those 300k of binary deals with it
<freemangordon>
(telephony that is)
<freemangordon>
so, my idea:
<DocScrutinizer05>
on the bright side: we _need_ to get rid of almost all of that telephony-specific stuff for modem, since our modem already has all that integrated
<DocScrutinizer05>
incl AEC for IHF
<freemangordon>
RE -voice module in a way so AEC, DRC, EQ, whatever algos are dload-ed from the original binary
<freemangordon>
DocScrutinizer05: :nod: and that fits in what I am trying to say
<freemangordon>
so, we'll have FOSS -voice module which will load the original .so only if needed
<DocScrutinizer05>
dunno about telepathy-sofia
<freemangordon>
(read n900)
<freemangordon>
oh, well, might not work then (voip)
<DocScrutinizer05>
prolly the telepathy stuff relies a lot on "built-in to maemo" AEC+stuff
<DocScrutinizer05>
yep, exactly, might work inferior
<DocScrutinizer05>
for usecases that need lots of processing, like IntegratedHandsFree
<DocScrutinizer05>
aka speakerphone
<DocScrutinizer05>
I dunno how much echo we have on raw mic data with earpiece
<freemangordon>
anyway, the idea still holds on, as we will be able to make -voice module work on upstream kernels
<DocScrutinizer05>
s/with/from/
<DocScrutinizer05>
sounds good
<DocScrutinizer05>
moving stuff to ALSA sounds like a plan for 2018
<freemangordon>
the other option is to find 3 fulltime job devs to work on REing for the next 3-6 months
<freemangordon>
:D
<DocScrutinizer05>
anyway check out http://www.ladspa.org/ - maybe it's way easier than expected
<DocScrutinizer05>
but getting Nokia audio ladspa plugins doesn't buy us much yet
<DocScrutinizer05>
at least for maemo ;-)
<freemangordon>
we will lose all the integration
<DocScrutinizer05>
other OS might benefit a lot ;-P
<DocScrutinizer05>
freemangordon: yep, exactly
<DocScrutinizer05>
which was the main purpose (well one of) to _keep_ maemo and PA abomination
<freemangordon>
no matter it is like spaghetti, actually I like the way it works
<DocScrutinizer05>
yep
<DocScrutinizer05>
unless... you don't like it every now and then, and want to tweak it
<DocScrutinizer05>
which you can't
<freemangordon>
well, actually you can
<DocScrutinizer05>
yeah, with a big pack of Aspirin
<freemangordon>
:D
<freemangordon>
BTW, what about reusng harmattan bits?
<freemangordon>
well, the -voice bit that is
<DocScrutinizer05>
sounds like a honest hacker's best common sense approach
<freemangordon>
iirc the pure PA is FOSS.
<freemangordon>
/me checks
<DocScrutinizer05>
though tuning is way off, due to other hw platform
<DocScrutinizer05>
but then, maybe that tuning is more tangible
<freemangordon>
shoudl be the same, as it is used in meego DE edition
<DocScrutinizer05>
AIUI N9 has mono IHF
<DocScrutinizer05>
but stereo mic
<DocScrutinizer05>
;-)
<DocScrutinizer05>
or was that N950?
<freemangordon>
yes, but meego DE on n900 uses (almost) the same code
<DocScrutinizer05>
:nod:
<freemangordon>
though I have no idea if voice calls work
<DocScrutinizer05>
we need to distinguish between "make stuff work at all" tasks and optimization tasks done by Nokia toprovide outstanding voicecall quality
<DocScrutinizer05>
the latter may cause 90% of R&D effort, to make a product manager nod it off after comparing the N9 proto to a N8 or whatever
<freemangordon>
hmm, well, I tend to disagree. if we can't provide the same or almost the same quality on n900, then we'd better don;t waste time on it. keep in mind I still want "one SW to rule them all" for both n900 and Neo900
<DocScrutinizer05>
sure
<DocScrutinizer05>
but first things first
<DocScrutinizer05>
the keyword in your sentence is "almost". The 90/10 rule applies here
<DocScrutinizer05>
90% of effort for last 10% of quality improvement
<DocScrutinizer05>
this includes tunig of algos
<freemangordon>
jusa_: how do you think, how hard would be to reuse the -voice module from harmattan on fremantle? keeping the binary blobs, just tweaking for the PA version.
<freemangordon>
DocScrutinizer05: I still think we won;t need to tweak the params, assuming that voice calls in meego DE works
<DocScrutinizer05>
sure, it works with said 90% of optimum quality
<DocScrutinizer05>
so maybe you want to rethink your "I tend to disagree"
JesperH has quit [Remote host closed the connection]
che12 has quit [Remote host closed the connection]
che12 has joined #neo900
<DocScrutinizer05>
20ms buffer size makes sense. adjusting in 5ms granularity... not so much
<DocScrutinizer05>
of course a `arecord -D hw:0|aplay -D hw:0,1` for microphone will not yield best results, you need to add at least parameters for a sampling rate spec of 8000 and a buffer size of maybe 20ms
<DocScrutinizer05>
modulo cmt audio is not hw:0,1 on N900
<DocScrutinizer05>
but may be hw:1 on Neo900
<DocScrutinizer05>
and probably with gstreamer you can build niftier audio stacks that for example also convert from 48k sampling rate of main codec to the 8k of modem
<DocScrutinizer05>
and you could toss in all the Nokia AEC and stuff there too
<DocScrutinizer05>
isn't telepathy using gstreamer for VOIP calls?
<DocScrutinizer05>
(mere speculation / wondering. I dunno)
<DocScrutinizer05>
the BB5 audio is "via network" (SSI), which means the APE basically async sends 20ms audio data chunks as messages to modem. Modem has no FIFO for that data, which means the next chunk of data must get transmitted to modem just in time of that 20ms GSM slot so modem codec can encode the audio and send it OTA in next timeslot. To accomplish that the modem sends those "uplink timing adjustment messages"
<DocScrutinizer05>
pretty nasty stuff
<DocScrutinizer05>
and when APE gets out of sync, the far end complains about poor audio quality
<DocScrutinizer05>
since whole 20ms frames get garbled
<DocScrutinizer05>
it's quite possible that BB5 modem wants the new data in a very small time window in that 20ms slot even, namely the time it sends out the encoded last data OTA. while a 3 or 4 ms later it starts processing the new buffer content and doesn't want APE to overwrite that buffer content before it got completely processed and transferred to the radio stack to send the data
<DocScrutinizer05>
so when APE is out of sync with modem in a way so it simply has a certain "ohase difference" aka "3 ms too late / too early", _every_ 20ms frame will get garbled
<DocScrutinizer05>
s/ohase/phase/
<DocScrutinizer05>
haven't looked into cmt_speech and how it handles the "uplink timing adjustment messages", but my assumption would be that they have a recurring 20ms timer there to schedule when audio data messages are sent via SSI to modem, and the adjustment messages just do exactly that: adjust period of that timer like a PLL
<DocScrutinizer05>
start cmt_speech with 20.00ms, for each adjustment telegram that says "you were too late" do timer-period-=0.01ms, for "too early" do timer-period+=0.01ms
vakkov has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
hmm, maybe 0.1ms rather than 0.01
<DocScrutinizer05>
a smart PLL algo may optimize this so called lock-time
<DocScrutinizer05>
i.e the time it needs until PLL locks to target signal
<DocScrutinizer05>
could do 0.1 0.5 1.0 3.0 ... ms adjust and jump back to 0.1 as soon as timing adj msg changes from one to the other signal (early/late)
<DocScrutinizer05>
nm, smart PLL algos are public knowledge, no use in me inventing new one here ;-)
paulk-collins has joined #neo900
vakkov has joined #neo900
<DocScrutinizer05>
hmmm t900:~# ls -l /dev/cmt_speech crw-rw---- 1 root pulse 10, 58 Jan 1 1970 /dev/cmt_speech
freemangordon has quit [Remote host closed the connection]
freemangordon has joined #neo900
vakkov has quit [Ping timeout: 264 seconds]
ashneo76 has joined #neo900
vakkov has joined #neo900
<freemangordon>
Pali: hmm, it is either bme-replacement breaks mass-storage mode or my pretty much ned device has USB port broken. though I doubt it is the device, as g_ether and g_nokia seem to work
<DocScrutinizer05>
(USB broken) check linux PC syslog for ENUM msgs when plugging in powered down N900
<freemangordon>
flasher works
<freemangordon>
I just removed rd flags
<DocScrutinizer05>
then hardly USB defect
<freemangordon>
:nod:
<freemangordon>
and "[ 1623.826609] usb 3-2.2: Product: N900 (Storage Mode)" on the host computer
<DocScrutinizer05>
((bme-repl breaks...)) after ENUM, /sys/devices/platform/musb_hdrc/charger MUST NOT get read
<DocScrutinizer05>
it switches PHY into a state that's not siuted for data on USB
<freemangordon>
../mode says b_idle
<freemangordon>
and that makes osso-usb-mass-storage-enable.sh exit with error "/usr/sbin/osso-usb-mass-storage-enable.sh: usb cable detached after module change"
<DocScrutinizer05>
((must not)) unless Pali changed the kernel driver so it doesn't mess with PHY when USB session active
<freemangordon>
no idea, I am on KP53 with the latest stuff from cssu-devel etc
<freemangordon>
includeing bme-replacement
<DocScrutinizer05>
I'm so happy we won't need all that mess on Neo900
<freemangordon>
we will :)
<DocScrutinizer05>
we won't. Charger detection not done by PHY
<DocScrutinizer05>
even not done by software
<freemangordon>
hmm, yeah
<DocScrutinizer05>
also we don't really need a bme-* that constantly tells charger what to do.
silviof has quit [Ping timeout: 250 seconds]
<freemangordon>
anyway, do you have any idea why the state is b_idle? I guess it should be b_peripheral or something
<DocScrutinizer05>
b_idle is the result of session ending. Dunno why it ended
silviof has joined #neo900
<wpwrak>
DocScrutinizer05: what are you looking for ? a way to get rid of (part of) the ECI circuit ?
<DocScrutinizer05>
no, I think we will want to finally put ECI circuit to a proper purpose
<DocScrutinizer05>
and I hoped for this android driver to implement ECI as well
<DocScrutinizer05>
actually I mixed ECI and ACI
<wpwrak>
there seems to be some ECI protocol engine in there, yet
<DocScrutinizer05>
is there or not?
<wpwrak>
based on some ACI hardware module that seems to do the heavy lifting
<wpwrak>
what i see there are accesses to some I2C registers of ACI / "accessory". don't see anything matching in the TRM. maybe the TPS65950 (TWL5030) is different from the TWL5031 ?
<DocScrutinizer05>
SWCS053E is tps65951 TRM
<DocScrutinizer05>
then my HDD has a file called Feature_Differences_Between_TPS65950_and_TPS65951___swca090.pdf
<DocScrutinizer05>
I'm pretty sure this is just ADCIN10
<wpwrak>
yes, i'm looking at this now
<wpwrak>
(the differences)
<DocScrutinizer05>
anyway checking for register that gets accessed in twl403x should shed some light on what's getting done
<wpwrak>
can't quite make sense of how they calculate the I2C address. the numbers in twl.h seem to bear hardly any relation to the mapping in twl4030-core.c
<DocScrutinizer05>
*AIUI* they set up a IRQ-callback-function and the IRQ is most likely triggered by our notorious comparators. In the IRQ callback they prolly take timestamps to decode
<wpwrak>
ah, wait, different kernels versions
<DocScrutinizer05>
that's android kernel ;-)
<DocScrutinizer05>
you know android stuff hardly ever propagates back into linus linux much
raccoon_ has quit [Ping timeout: 272 seconds]
<DocScrutinizer05>
indeed I'd be a tad wiser when I could grok what means `ret = twl4030_i2c_write_u8(TWL5031_MODULE_ACCESSORY, val, reg);`
<wpwrak>
#define TWL5031_BASEADD_ACCESSORY 0x0074 /* Replaces Main Charge */
<wpwrak>
looks like a non-TWL4030 feature. there are more comments about such differences in the area.
mvaenskae has quit [Ping timeout: 256 seconds]
<DocScrutinizer05>
ummm
<wpwrak>
ah yes, here it is, in the differences document: "Replaced battery charger module with state-machine that controls an external charger. Only USB charger is"
<wpwrak>
and about the registers in question: "GAIA BCI removed and replaced: refer to TPS65951 BCI register description"
<Pali>
I have this info: ADCIN0 - Battery temperature; ADCIN2 - ECI AD; ADCIN4 - Battery size indicator; ADCIN12 - Battery voltage level
<wpwrak>
seems that they added some ECI-ish critter there as well, while they were making massive changes
<Pali>
(for n900)
<DocScrutinizer05>
wpwrak: BCI?
<DocScrutinizer05>
how's that related to ECI?
<DocScrutinizer05>
but yes, possibly they added some shift registers or whatever
<DocScrutinizer05>
we are no weak fools who need a shift register to do some ultr-low-speed serial one wire protocol, right? ;-)
<DocScrutinizer05>
Pali: yes, in schematics I also have ADCIN2, signal labebeld "ECI_AD"
<DocScrutinizer05>
I always thought they meant this in the way I sketched above, just maybe doing direct IRQ, not from comparators
<DocScrutinizer05>
in times with depressed mood I wondered if they do ADC sampling at a sampling rate of dunno 10k/s or whatever
<DocScrutinizer05>
anyway we should have _all_ the hardware bits in our toolbox tomake ECI work
<DocScrutinizer05>
even without support by special UARTs in twl4030
<DocScrutinizer05>
and en passant this piece of c code should teach us exactly how to detect and tell apart cable attachment of type ACI_NOTYPE, ACI_UNKNOWN, ACI_HEADPHONE, ACI_AVOUT, ACI_HEADSET, ACI_ECI_HEADSET, ACI_OPEN_CABLE, ACI_CARKIT,
arcean has quit [*.net *.split]
starseeker has quit [*.net *.split]
chainsawbike has quit [*.net *.split]
trench has quit [*.net *.split]
Sicelo has quit [*.net *.split]
demure has quit [*.net *.split]
<DocScrutinizer05>
yeah wpwrak: /* force reset to ACI ASIC. Disable all ACI irqs by default */
<DocScrutinizer05>
(how to detect...) maybe not when this is once more done in such a "smart core" like MUSB etc
<DocScrutinizer05>
anyway the method is obvious: attach some voltage via a series resistor (i.e. enable MICBIAS), then probe voltage via ADCIN2 to calculate the cable termination impedance
<DocScrutinizer05>
nfc what's carkit in this context
<DocScrutinizer05>
yeah well, CARKIT, analog audio via USB D+/-, but allows it mix in UART serial into the analog audio. A standard the world better keeps ignoring
mvaenskae has quit [Ping timeout: 245 seconds]
sparetire has joined #neo900
vakkov has quit [Ping timeout: 250 seconds]
<wpwrak>
indeed :)
<wpwrak>
besides, USB itself nowadays also has its own extra serial communication path in the PHY (not speaking of power, which of course also ...), so you can take that madness yet some steps further ...
<DocScrutinizer05>
:-/ SWCS053E has no HSMIC_DC
<DocScrutinizer05>
a miracle
<DocScrutinizer05>
wait, we also got a pin number
<DocScrutinizer05>
H4
<DocScrutinizer05>
I2S.DOUT ??!?!!
* DocScrutinizer05
wonders what the heck a chip they used in N9
<DocScrutinizer05>
the pin numbering for N9 TWL4030 is the one of TPS65950, not -51
<DocScrutinizer05>
at least for VHSMIC.OUT pin:E4
<DocScrutinizer05>
H4 (N9: HSMIC_DC) however is ADCIN0
<DocScrutinizer05>
Pali: TI tells me uBoot codebase is also used for MLO/xLoader and they explicitly state that tasks may be shared between the two, so when MLO already sets MPU clock, uBoot may omit to do again
<DocScrutinizer05>
FWIW
<Pali>
ok
<DocScrutinizer05>
maybe the sharing between N900 xLoader and NOLO is not exactly what a standard uBoot build would expect the xLoader should have done already?
<DocScrutinizer05>
(MPU clock was just an example TI used, aiui)