Well, after a day or two of Windows Mobile feel good, we return back to some issues which are unnecessarily plaguing our devices.
It appears that driver are once again affecting selected HTC devices, including all of the high end current generation devices like the HTC Touch Diamond, Touch Pro, HD, and Xperia. When sound is played either through headphones or speakers periodically (usually once every 5 minutes) you will hear a short "skip" in the audio. The sound has been described as a lag/skip/hiccup/tick/blip. The problem appears to be deep in the wave device driver or possibly the hardware wave device itself (Qualcomm in action again?) The problem does not seem to be present in A2DP.
The problem mainly affects third party players, as HTC appears to have solved the problem, but only for themselves, by building a custom wave driver.
The Conduits Pocket Player team has been looking into the issue and have come back discouraged. This is what that have had to say on the subject.
We have done extensive tests regarding the HTC audio skipping issue, and have come to the conclusion that it is not something that Conduits can address. After analyzing the HTC Audio Manager program, and several other files (such as HTCâ€™s DirectShow Audio Renderer HTCRenderFlt2.dll and HTCADXRenderer4.dll), we found that both are making some very special system calls into the WaveOut driver.
Here are some technical details for what we have found. First, we donâ€™t think that thread or process priority have anything to do with the problem. Normal audio application use a cycle of â€˜waveOut buffersâ€™ that keep the audio output â€˜fullâ€™ with audio data for the system to pull from and play. Applications use standard waveOutWrite functions to fill these buffers. From Pocket Playerâ€™s standpoint, these buffers are always full, and adjusting the priorities wonâ€™t affect this. One way to improve audio skips (that has affected the HTC TyTN) was to boost the thread priority of the WaveOut driver by editing a registry value under HKLM\Drivers\Builtin\WaveOut. This approach did not work here. Interestingly enough, these skipping problems occur on desktop PCâ€™s. There, the problem is related to realtime drivers that take â€œtoo longâ€ in their processing, which prevents the audio driver from processing the next batch of sound. This happens in Vista with some MacBook drivers.
The Audio Manager uses a different output mechanism from the standard waveOut calls â€“ it uses the DirectShow audio renderer filter, which is another way to send audio. Looking in the internals of how it works, it is using a completely different mechanism. It is using a proprietary waveOutMessage call to open a new message queue, which audio is then â€œstreamedâ€ through.
Pocket Player (and other applications) could possibly resolve this issue by using the HTC Audio Renderer instead of their own waveOut routines, but then we would lose cross fading and other Pocket Player â€“specific features. We did some initial tests of creating a DirectShow filter graph (complete with their Audio Renderer) but still experienced the skipping, so there must be additional steps.
As a result, Conduits is now regarding this as a device-specific problem that the manufacturer is obligated to fix. Alternatively, if HTC wants to document their special â€œstreaming modeâ€ for their audio output driver, we could look into adapting to that model.
If you extract the Wavedev.dll from a ROM, you will see countless debugging messages regarding â€œMP3 Streamsâ€ and the like, indicating an entirely separate audio path for music coming from their software. If need be, we will rewrite our WaveOut output plug-in (our output routines use a private plug-in architecture just like our other plug-in types) that uses the DirectShow output.
HTC has declined to document how they solved the issue, saying they did not support 3rd party software.
Of course XDA-Developers are never ones to let a situation like this lie. Thx1200 is starting a bounty for developers who can produce an open source solution to this problem and make it available to the community. Currently the bounty is only a small $30, but I am sure we can generate many more donations to address this vexing issue for anyone who uses a 3rd party audio software.
Read the full thread at XDA-Developers here, and don’t forget to add your pledge also if you feel at all this is a situation which needs correcting.