Phonon issues with DirectSound9

Hi,

I have two problems with using Phonon on Windows XP with Direct Sound 9 backend.
I'm using Qt version 4.4.1 that I compiled on my own machine using Visual Studio 2005 SP1. The phonon framework compiled alright and has DS9 backend (DirectX SDK: February 2007).

First problem (and most important):

Whenever I play a sound file (PCM or MP3, doesn't matter) using Phonon, the sound is played successfully, but a thread remains open even after the MediaObject is deleted. This happens every single time a sound is played. I want to be able to play multiple sounds at once, so I create a new path (using a new MediaObject) for each sound file I play. Analyzing the application threads (using ProcessExplorer, or the Visual Studio threads window) I get the following after playing 10 times a sound.

RPCRT4.dll!I_RpcBCacheFree+0x5ea
RPCRT4.dll!I_RpcBCacheFree+0x5ea
PhononMixingTest.exe!WinMainCRTStartup
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
quartz.dll!CCallbackThread::ThreadProc() + 0xeb bytes
ADVAPI32.dll!RegDeleteKeyW+0xfd

The first time I play a sound it leaves 2 hanging threads, after that only 1 for each time a sound is played. In CCallbackThread::ThreadProc() it hangs on a call to WaitForMultipleObjects.

Here is the code that plays the sound file:

Code:

---

void PhononMixingTest::PlayClicked()
  {
  	QString soundFilePath = ui.fileLineEdit_->text();	
  	if (soundFilePath.isEmpty())
  	{
  		return;
  	}
 
  	Phonon::AudioOutput* audioOutput = new Phonon::AudioOutput(Phonon::MusicCategory, this);
  	Phonon::MediaObject* mediaObject = new Phonon::MediaObject(this);
  	Phonon::createPath(mediaObject, audioOutput);
  	connect (mediaObject, SIGNAL(finished()), this, SLOT(SoundFinishedPlaying()));
  	mediaObject->setCurrentSource(soundFilePath);
  	mediaObject->play();
  }
 
  void PhononMixingTest::SoundFinishedPlaying()
  {
  	Phonon::MediaObject* mediaObject = qobject_cast<Phonon::MediaObject*>(sender());
  	if (mediaObject)
  	{
  		mediaObject->stop();
  		mediaObject->clearQueue();
  		mediaObject->deleteLater();
  	}
  }

---

I do not know if I'm doing this the right way, because I don't fully understand who is responsible for the ownership of the MediaObject and the AudioOutput. By the way, the threads remain open even after the parent of the MediaObject and AudioOutput is deleted.

Second problem:

Sometimes when playing multiple sounds at once in debug mode, I get the following assert failure:
ASSERT: "!isEmpty()" in file ../../src/corelib/tools/qlist.h, line 230

The call stack is given below:

> QtCored4.dll!qt_message_output(QtMsgType msgType=QtFatalMsg, const char * buf=0x02d1dc40) Line 2035 C++
QtCored4.dll!qFatal(const char * msg=0x67234b2c, ...) Line 2241 + 0xe bytes C++
QtCored4.dll!qt_assert(const char * assertion=0x010b257c, const char * file=0x010b1e78, int line=230) Line 1809 + 0x16 bytes C++
phonon_ds9d4.dll!QList<Phonon::DS9::WorkerThread:: Work>::first() Line 230 + 0x2d bytes C++
phonon_ds9d4.dll!QList<Phonon::DS9::WorkerThread:: Work>::takeFirst() Line 392 + 0x2d bytes C++
phonon_ds9d4.dll!QQueue<Phonon::DS9::WorkerThread: :Work>::dequeue() Line 40 + 0x1c bytes C++
phonon_ds9d4.dll!Phonon::DS9::WorkerThread::dequeu eWork() Line 56 + 0xf bytes C++
phonon_ds9d4.dll!Phonon::DS9::WorkerThread::handle Task() Line 184 + 0xf bytes C++
phonon_ds9d4.dll!Phonon::DS9::WorkerThread::run() Line 79 C++
QtCored4.dll!QThreadPrivate::start(void * arg=0x00b4b5a8) Line 235 C++
msvcr80d.dll!__beginthreadex() + 0x221 bytes
msvcr80d.dll!__beginthreadex() + 0x1c7 bytes
kernel32.dll!_BaseThreadStart@8() + 0x37 bytes

It seems to be some kind of synchronization problem for accessing the phonon work queue.

Maybe I'm using the Phonon framework the wrong way. So if you have any ideea about what I'm doing wrong or what should I try to fix these problems, I would much appreciate your help. Thank you.

I've tried this also with Qt 4.5.0-beta1 together with DirectX SDK November 2008 (latest) and it behaves the same (both for debug and release configurations).
Has anyone tried this? Does it happen to you also?

i have some troubles with phonon, too.

Qt 4.4.3 / MS VC++ 2008 Express Edition / Windows Vista

I've tried using phonon 4.3.0 from kde.org. nothing happes :(

I've got memory leak.

wav file: 4 bit per sample, 22050 Hz, codec IMA ADPCM, bitrate 88 kbps

Code:

---

QString mp = "F:/sounds/" + filename;
_CrtMemState _state, _state2, _s3;
_CrtMemCheckpoint(&_state);
 
_music->setCurrentSource(mp);
 
_CrtMemCheckpoint(&_state2);
 
_CrtMemDifference(&_s3, &_state, &_state2);
_CrtMemDumpStatistics(&_s3);
_CrtMemDumpAllObjectsSince (&_state);
 
_music->play();

---

Memory dump:

Code:

---

0 bytes in 0 Free Blocks.
296 bytes in 7 Normal Blocks.
0 bytes in 0 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 0 bytes.
Total allocations: 4086 bytes.
Dumping objects ->
{218294} normal block at 0x00F34898, 40 bytes long.
Data: <         uM     > 00 00 00 00 04 00 CD CD E8 75 4D 01 00 00 00 00
{218293} normal block at 0x00F34C60, 40 bytes long.
Data: <                > 01 00 00 00 05 00 00 00 01 00 00 00 04 00 00 00
{218292} normal block at 0x033B6A60, 66 bytes long.
Data: <            rj; > 01 00 00 00 17 00 00 00 17 00 00 00 72 6A 3B 03
{218290} normal block at 0x00F34840, 40 bytes long.
Data: <         MM     > 01 00 00 00 03 00 CD CD A8 4D 4D 01 00 00 00 00
{218287} normal block at 0x00EE4D30, 12 bytes long.
Data: <P           > 50 A4 F3 00 B8 B0 F3 00 B8 B0 F3 00
{218274} normal block at 0x00F346E0, 40 bytes long.
Data: <         MM     > 02 00 00 00 02 00 CD CD A8 4D 4D 01 00 00 00 00
{218270} normal block at 0x02FD2BD0, 128 bytes long.
Data: <    6        +  > 01 00 00 00 36 00 00 00 18 00 00 00 E2 2B FD 02
{218267} normal block at 0x0341DB38, 30 bytes long.
Data: <            J A > 01 00 00 00 05 00 00 00 05 00 00 00 4A DB 41 03
{218266} normal block at 0x030FD2D0, 28 bytes long.
Data: <                > 01 00 00 00 04 00 00 00 04 00 00 00 E2 D2 0F 03
{218265} normal block at 0x00F41AB0, 88 bytes long.
Data: <          0g  0g> 01 00 00 00 D0 D2 0F 03 20 16 30 67 20 16 30 67
{218217} normal block at 0x0339FF10, 40 bytes long.
Data: <0Z              > 30 5A 04 10 02 00 00 00 00 00 00 00 B0 1A F4 00
Object dump complete.

---

I can do something wrong? Or this is phonon bug?