|
Posted by Robert Scott on August 14, 2007, 9:29 am
Please log in for more thread options
I have discovered a disturbing fact in Windows Mobile phones. If you write an
audio input application using waveIn, etc., the buffer timing is not what you
might expect. For example, I am developing a piano tuning application that
listens at 22050 samples per second. I was using a group of buffers with 2048
samples each. When a buffer is filled, I get a MM_WIM_DATA message. When I
used 2048-sample buffers, all went well. I could verify using GetTickCount()
that the MM_WIM_DATA messages were coming about every 92 msec, which is about
right. But then I wanted to switch to 1024-sample buffers to give faster
feedback and smoother animation of my tuning indicator. This worked very well
on a variety of Pocket PCs. But on the Motorola MPx-220 Smartphone, the display
did not appear any smoother when I switched to the smaller buffers. Further
investigation using GetTickCount() revealed that the MM_WIM_DATA messages were
coming at these intervals:
1 92 1 92 1 92 1 92 1 92...
instead of
46 46 46 46 46 ...
which I had expected. It is apparent from this data that the 1024-sample
buffers were not being collected by the OS and delivered to me in a timely
fashion. Instead, it seems that the OS is collecting audio data in buffers with
2048 samples, and then delivering them to me in 1024-sample chunks. After each
2048-sample system buffer I get two 1024-sample buffers in quick succession.
This defeats the purpose of my using smaller buffers for faster user feedback.
Then I tried a Motorola Q Phone and things got even more confusing. It turns
out that on the Q Phone, the native audio buffer size in the OS is around 2758
samples. I do not know the exact number because this was calculated from some
statistics that I gathered using GetTickCount().
This specification - the native audio input buffer size - seems to be an
unpublished specification for the various phones. For an application like mine
it is critical that I know how this specification will affect the latency of the
audio that I receive. Since this specification is unpublished, I have no
alternative but try my software on various phones to discover the native buffer
size. I first ran into this problem on Symbian OS phones (the European
alternative to Windows Mobile) and in those phones the problem is even worse.
The the native buffer size is 250 msec. worth of data - twice as bad as the
Motorola Q Phone. Needless to say, I won't be porting my application to Symbian
Phones until that gets sorted out.
As for the animation of my tuning indicator, I could run that off a separate
timer, but then I would be adding even more latency as the timer and the audio
buffer timing drift in and out of phase. I would much rather continue to
animate my display directly from the timing of the MM_WIM_DATA messages.
Has anyone run into this problem in audio input applications?
Robert Scott
Ypsilanti, Michigan
|
|
Posted by Scott Salley on August 15, 2007, 2:21 pm
Please log in for more thread options
On Aug 14, 6:29 am, ---@--- (Robert Scott) wrote:
> I have discovered a disturbing fact in Windows Mobile phones. If you write an
> audio input application using waveIn, etc., the buffer timing is not what you
> might expect. For example, I am developing a piano tuning application that
[Lots Deleted]
To the best of my knowledge, there are no guarantees about latency,
buffer timings or anything like that -- whatever you're trying to do
may be extremely difficult because the hardware/software for sound is
often the bare minimum to get stuff in and out.
|
|
Posted by Robert Scott on August 16, 2007, 7:43 am
Please log in for more thread options wrote:
>On Aug 14, 6:29 am, ---@--- (Robert Scott) wrote:
>> I have discovered a disturbing fact in Windows Mobile phones. If you write an
>> audio input application using waveIn, etc., the buffer timing is not what you
>> might expect. For example, I am developing a piano tuning application that
>[Lots Deleted]
>
>To the best of my knowledge, there are no guarantees about latency,
>buffer timings or anything like that -- whatever you're trying to do
>may be extremely difficult because the hardware/software for sound is
>often the bare minimum to get stuff in and out.
In the end I decided to break the connection between receiving MM_WIM_DATA
messages and the animation rate. I now use WM_TIMER messages to run the
animation, so at least that is smooth. Of course the audio processing is stilll
tied to the MM_WIM_DATA messages, so I will just to have to put up with whatever
audio buffer latency an particular Smartphone gives me.
Robert Scott
Ypsilanti, Michigan
|
|
Posted by andyraf on August 26, 2007, 12:39 am
Please log in for more thread options On Aug 16, 4:43 am, ---@--- (Robert Scott) wrote:
> wrote:
>
> >On Aug 14, 6:29 am, ---@--- (Robert Scott) wrote:
> >> I have discovered a disturbing fact inWindows Mobilephones. If you write an
> >>audioinput application using waveIn, etc., the buffer timing is not what you
> >> might expect. For example, I am developing a piano tuning application that
> >[Lots Deleted]
>
> >To the best of my knowledge, there are no guarantees about latency,
> >buffer timings or anything like that -- whatever you're trying to do
> >may be extremely difficult because the hardware/software for sound is
> >often the bare minimum to get stuff in and out.
>
> In the end I decided to break the connection between receiving MM_WIM_DATA
> messages and the animation rate. I now use WM_TIMER messages to run the
> animation, so at least that is smooth. Of course theaudioprocessing is stilll
> tied to the MM_WIM_DATA messages, so I will just to have to put up with
whateveraudiobuffer latency an particular Smartphone gives me.
>
> Robert Scott
> Ypsilanti, Michigan
I can probably shed some light on the behavior, although I don't have
a solution. Audio input is routed through a DMA controller which
copies audio data from the audio codec to a set of DMA buffers. The
audio driver wakes up whenever there's a DMA-done interrupt, at which
point it processes any data in the DMA buffer, copying it to the
application's buffer and returning that buffer to the application via
MM_WIM_DATA.
The rate at which you get MM_WIM_DATA messages is determined by the
rate of DMA-done interrupts, which is in turn determined by the size
of the DMA buffer. There's a tradeoff though... while a small DMA
buffer will decrease latency and improve the accuracy of when buffers
are returned, it will also increase the CPU load (by causing more DMA-
done interrupts) and decrease the resilience to other high-priority
threads causing glitches.
I typically suggest that driver writers design their audio driver with
a 10-20 msec interrupt period, which is a pretty fair compromise.
However, ultimately this is up to the driver writer, and some OEMs
(either by error or to counteract a badly-behaved driver elsewhere in
the system) use a larger DMA buffer.
One other thing you might notice is that if the application buffer
sizes don't match the DMA buffer sizes (and there's no way to know the
DMA buffer size), if you look at the times of MM_WIM_DATA messages you
might see a weird "beat" in their return times. That's probaby why you
saw the 92-1-92-1 pattern in the return times on that platform.
There's no real overhead cost for using more application buffers, so
in general it's better to use a bunch of small buffers rather than a
small number of large buffers.
-Andy Raffman
|
|
Posted by Robert Scott on August 28, 2007, 10:31 am
Please log in for more thread options On Sat, 25 Aug 2007 21:39:19 -0700, andyraf@microsoft.com wrote:
>...The
>audio driver wakes up whenever there's a DMA-done interrupt, at which
>point it processes any data in the DMA buffer, copying it to the
>application's buffer and returning that buffer to the application via
>MM_WIM_DATA...
Yes, this is just what I guessed from observing the timing. It is good to hear
it confirmed authoritatively, though.
Robert Scott
Ypsilanti, Michigan
|
| Similar Threads | Posted | | Keep Display from Timing Out on Motorola Q Phone | June 6, 2007, 6:38 am |
| Installation warning | May 23, 2006, 7:27 am |
| How do I make my device run my applications with no warning | September 9, 2007, 4:58 am |
| DirectShow Access to Image Buffer | November 3, 2006, 12:14 pm |
| How can I get bitmap bits(bitmap memory buffer pointer)? | August 6, 2005, 4:20 pm |
| direct show and direct access to image buffer | November 10, 2005, 1:11 am |
| MP3 to PCM audio | September 19, 2008, 2:49 am |
| Using audio out after/during a call | December 29, 2005, 2:25 am |
| How to decode AMR audio | January 17, 2006, 3:48 am |
| Audio rendering | April 18, 2006, 7:06 am |
|
XML Sitemap