[Touch Pro2, Tilt 2 Android Development] phhusson:
The thing is that, it's really a "chance", I'll try to explain detailed situation after your quotings.

Okay, first, don't miss 3D GPU (3D hardware), and video acceleration(ADSP), it has no common stuff. (but perhaps the fix :( )

If it works in sense, then it's not a matter of driver, but of frameworks, basically driver exists, but no app can use it. And it does seem so from what I've seen from the ADSP.

Android has msm7k accelerated video and 3D drivers and ""proper"" (a bit better than windows, but don't ask coreplayer's devs :p) frameworks. The closed-source acceleration code should be the same for all msm7k devices, so we're fine here.

Anyway, only H264 as a video codec is handled, I'm not sure it's worth it.

Yeah I've got a Liquid, and hum well... It's slow as hell :o

Don't worry, even with GPU acceleration, we won't have good performances.

How many android msm7k devices have WVGA screen ? None, I'm pretty sure it's because of the lack of power of this SoC.

The problem is that we're simply stuck, like we were for GPS, so it can really be from one day to never, anyone giving a timeframe has some hidden pieces of information I don't have.

I think I just answered it ? (if not, yell again :p)

We had the same situation for GPS (being just stucked), and we got the problem and solution in really little time (just a stupid callback to be properly setted.)

No clue, I've never written drivers for WinMo :p

I don't think anyone ever used JTAG for this project yet.

Anyway, no the OS doesn't matter, almost everything is documented on the wiki on htc-linux.org. It's just that the only implementation of those docs is linux (it's even in the webpage name :p)

I haven't heard of BinaryDroid yet, but that he dismantled his TP2...

Well, the first BIG problem is to understand what's going on, that's everything but simple (there is no proper documentation for that, we use android devices's driver almost as is)

The solution could be really simple. For GPS, the fix could be written in less than 10 lines. (Then I had to make all the "real" code, but that's another story)

So, technical explanation for ADSP (I haven't plaid with it for a while now, so I might have some details wrong.):

Here is the "full" path of playing audio in the code:

audio_open in audio_out.c

- audmgr_open (sets tx/rx sampling rate, method, and codec through RPC)

audio_ioctl(audio_start) in audio_out.c on audio device calls audio_enable()

- calls audmgr_open again, then audpp_enable,

-- calls msm_adsp_get("AUDPPTASK");

--Send an RPC to ADSP through A9A radio:

rpc_adsp_rtos_app_to_modem(got_it, REGISTER, RPC_ADSP_RTOS_PROC_APPS, 0x03/*AUDPPTASK id*/);

which loads AUDPPTASK into ADSP(audio playback task on the ADSP, that's what does audio decoding (either raw pcm or aac, mp3 or whatever handled)

-- calls msm_adsp_enable( audpptask)

Sends RPC

rpc_adsp_rtos_app_to_modem(got_it, ENABLE, RPC_ADSP_RTOS_PROC_APPS, 0x03/*AUDPPTASK id*/);

( Actually enable and start AUDPP task)

wait for a rpc callback (received in handle_adsp_rtos_mtoa_app), and for the AUDPP READY signal.

-- sends AUDPP_CMD_CFG ENABLE ADSP command.

This time, it's no longer RPC, it directly writes into ADSP register (called AD5 in the sources), through msm_adsp_write

--- msm_adsp_write

There is a lot of synchronisation "magic" in there, what's important, is that according to logs, this function does receive ACK from ADSP (so adsp somehow works.)

Now, audpp_enable has "succesfully" (ie no error and ADSP seems alive) accomplished its duty, same goes for audio_enable, now the program starts writing audio data.

audio_write waits for the audio->wait lock to be risen up, which happens when audio_dsp_event is triggered, which is called by audpp_dsp_event, itself called by adsp_rtos_read_ctrl_word_cmd_tast_to_h_v, which is called by adsp_get_event, which is called on ADSP interrupt.

The thing is that no ADSP interrupt is triggered, so the write waits for ever.

Of course, we tried to fake the interrupt, without much luck, which means according to the sources, that there is no message for us from ADSP, while we should have received a READY message (not the one from RPC, another one through the ADSP registers)