HTC DriverGate – ljudversionen

Tja, efter en dag eller två av Windows Mobile-känslan återvänder vi till några problem som plågar våra enheter i onödan.

Det verkar som att drivrutinerna återigen påverkar utvalda HTC-enheter, inklusive alla avancerade nuvarande generationsenheter som HTC Touch Diamond, Touch Pro, HD och Xperia. När ljud spelas upp antingen via hörlurar eller högtalare med jämna mellanrum (vanligtvis en gång var 5:e minut) kommer du att höra ett kort "hopp" i ljudet. Ljudet har beskrivits som en lagg/hopp/hicka/tick/blip. Problemet verkar ligga djupt i wave-enhetsdrivrutinen eller möjligen själva hårdvaruvågenheten (Qualcomm i aktion igen?) Problemet verkar inte finnas i A2DP.

Problemet drabbar främst tredjepartsspelare, eftersom HTC verkar ha löst problemet, men bara för sig själva, genom att bygga en anpassad wave-drivrutin.

Conduits Pocket Player-teamet har tittat på frågan och har kommit tillbaka avskräckta. Detta är vad de har att säga om ämnet.

Vi har gjort omfattande tester angående HTC-ljudhoppningsproblemet och har kommit fram till att det inte är något som Conduits kan ta itu med. Efter att ha analyserat programmet HTC Audio Manager och flera andra filer (som HTC:s DirectShow Audio Renderer HTCRenderFlt2.dll och HTCADXRenderer4.dll), fann vi att båda gör några mycket speciella systemanrop till WaveOut-drivrutinen.

Här är några tekniska detaljer för vad vi har hittat. För det första tror vi inte att tråd- eller processprioritet har något med problemet att göra. Normal ljudapplikation använder en cykel av "waveOut-buffertar" som håller ljudutgången "full" med ljuddata som systemet kan hämta från och spela upp. Applikationer använder standard waveOutWrite-funktioner för att fylla dessa buffertar. Ur Pocket Players synvinkel är dessa buffertar alltid fulla, och att justera prioriteringarna kommer inte att påverka detta. Ett sätt att förbättra ljudhopp (som har påverkat HTC TyTN) var att öka trådprioriteten för WaveOut-drivrutinen genom att redigera ett registervärde under HKLM\Drivers\Builtin\WaveOut. Detta tillvägagångssätt fungerade inte här. Intressant nog uppstår dessa överhoppningsproblem på stationära datorer. Där är problemet relaterat till realtidsdrivrutiner som tar "för lång tid" i sin bearbetning, vilket hindrar ljuddrivrutinen från att bearbeta nästa sats ljud. Detta händer i Vista med vissa MacBook-drivrutiner.

Audio Manager använder en annan utmatningsmekanism än de vanliga waveOut-anropen – den använder DirectShow-ljudrenderingsfiltret, vilket är ett annat sätt att skicka ljud. Om man tittar på insidan av hur det fungerar, använder det en helt annan mekanism. Den använder ett proprietärt waveOutMessage-anrop för att öppna en ny meddelandekö, vilket ljud sedan "strömmas" genom.

Pocket Player (och andra applikationer) skulle möjligen kunna lösa det här problemet genom att använda HTC Audio Renderer istället för sina egna waveOut-rutiner, men då skulle vi förlora korsfading och andra Pocket Player - specifika funktioner. Vi gjorde några inledande tester för att skapa en DirectShow-filtergraf (komplett med deras Audio Renderer) men upplevde fortfarande överhoppningen, så det måste finnas ytterligare steg.

Som ett resultat av detta ser Conduits nu detta som ett enhetsspecifikt problem som tillverkaren är skyldig att fixa. Alternativt, om HTC vill dokumentera sitt speciella "strömningsläge" för sin drivrutin för ljudutgång, kan vi titta på att anpassa oss till den modellen.

Om du extraherar Wavedev.dll från en ROM kommer du att se otaliga felsökningsmeddelanden om "MP3-strömmar" och liknande, vilket indikerar en helt separat ljudväg för musik som kommer från deras programvara. Om det behövs kommer vi att skriva om vår WaveOut-utgångsplugin (våra utgångsrutiner använder en privat plug-in-arkitektur precis som våra andra plugin-typer) som använder DirectShow-utgången.

HTC har avböjt att dokumentera hur de löste problemet och sa att de inte stödde programvara från tredje part.

Naturligtvis är XDA-utvecklare aldrig sådana som låter en sådan här situation ligga. Thx1200 startar en belöning för utvecklare som kan skapa en öppen källkodslösning för detta problem och göra den tillgänglig för communityn. För närvarande är belöningen bara en liten $30, men jag är säker på att vi kan generera många fler donationer för att ta itu med detta irriterande problem för alla som använder en ljudmjukvara från tredje part.

Läs hela tråden på XDA-Developers här, och glöm inte att lägga till ditt löfte också om du känner att detta är en situation som behöver korrigeras.