Forums | Forums |




Hi there,

during the last months our company has been working on writing a custom audio decoder+player for BREW. We are doing playback using IMEDIA PCM and a custom-written ISource.

As it is now, all decoding and other work is done within the ISOURCE_Read() call. (This is how we successfully did for Symbian...) However, it leads to very obvious gaps in playing. We now experimented by decoding a very low-rate audio stream. And then it's obvious that all audio playback temporarily stops while ISOURCE_Read() is called.

From the start, we thought that this was the fault of the phone we were working with. But now we got the chance to try it on a phone from a different company. And the problem is exactly the same: audio playback is instantly blocked at the call to ISOURCE_Read.

My belief is that there is a problem with the buffering in IMEDIA PCM when streaming from custom ISource. If the IMEDIA playback was properly double-buffered, there would be no gaps. Especially not since our decoding is by good margin faster than should be needed to play back the input data in real-time. (10 seconds worth of audio is decoded in 5 seconds)

We also tried to work around this, by doing our decoding outside the ISOURCE_Read() call, only to minimize the time ISOURCE_Read() is being called. This gives by far better results, but there are occasional audio gaps. Also, it's an ugly and in-effective workaround that should not be needed in first place.

What do you think. Is the lack of proper buffering a known issue of IMedia PCM? Is there any hope for a improvement within the near future?

Best regards,