CMdaAudioOutputStream::WriteL()

[stenlik]

Hi,

I have a question related to the CMdaAudioOutputStream::WriteL().

When the CMdaAudioOutputStream::WriteL() method is called more than once in row (means not waiting for the MaoscBufferCopied() callback), then according to the SDK documentation the client can call WriteL() again before MaoscBufferCopied notification takes place because the buffers are maintained in a client-side queue until they have been sent. The parameter of the WriteL() method is const TDesC8 &aData.

My question is: Should the client keep in the FIFO list of passed parameters and pop them on regularly base in each MaoscBufferCopied() callback method? So far it looks that if I create the stack based TPtr8 variable and pass it as a WriteL() method parameter the client panics with USER 19 (member function of an 8 bit variant descriptor if the descriptor is invalid) error.

The code which does not work:

TPtr8 buf( iBufferLoad + iBufferPlayPos, BUFFER_PLAY_SIZE, BUFFER_PLAY_SIZE );
iStreamOutput->WriteL( buf );

There is also FAQ-1004:
http://library.forum.nokia.com/index...QIndexCPP.html, which says The application may not replace or delete the aData buffer ahead until it has been received by the client application in the following callback, but the description is probably related to the buffer with data itself, not to the TPtr8/TPtrC8 descriptor passed as the WriteL() method parameter.

BR
STeN

[stenlik]

Hi,

I am not sure why the CMdaAudioOutputStream is implemented in a way that the caller should keep the TPtr8/TPtrC8 passed to WriteL(), but after implementing a simple FIFO to hold those variables class works perfectly.

BR
STeN

[wizard_hu_]

The passed variable has to remain accessible because the queue stores addresses. Remember that you get back exactly the same TDesC8 variable in MaoscBufferCopied.

[stenlik]

Thanks for reply!

Regards,
STeN