Hi, Jocelyn:

Would you please send us your changed files? We need test them on our HW
and send back our comments soon.

Thanks

Junhong

>-----Original Message-----
>From: datatype-dev-bounces at helixcommunity.org 
>[mailto:datatype-dev-bounces at helixcommunity.org] On Behalf Of 
>ext Jocelyn RICARD
>Sent: Thursday, November 09, 2006 8:10 AM
>To: 'Greg Wright'
>Cc: datatype-dev at helixcommunity.org
>Subject: RE: [datatype-dev] CR : Helix/MDF audio - 
>Optimisation of calls toDevSound's SamplePlayed
>
>Hi Greg,
>
>As you suggested I added the preference so that the frequency 
>of reading the device time can be changed.
>
>But, before checking in, I would prefer to have feedback of 
>mdf adapation guys.
>
>Br, Jocelyn
>
>
>-----Original Message-----
>From: Greg Wright [mailto:gwright at real.com]
>Sent: Monday, November 06, 2006 8:45 PM
>To: Jocelyn RICARD
>Cc: datatype-dev at helixcommunity.org
>Subject: Re: [datatype-dev] CR : Helix/MDF audio - 
>Optimisation of calls to DevSound's SamplePlayed
>
>
>Jocelyn RICARD wrote:
>> Hi Greg,
>> 
>> Your first point is not covered by the patch proposal: It is 
>possible 
>> to have too successive calls of GetCurrentAudioTime and the 
>second one 
>> returns a value less than the first call. The difference is 
>never more 
>> than 3ms, but it exist. I changed the code to cope with this 
>issue. I 
>> store the last time returned an check if new time is ahead or not. I 
>> also added the support of 32 bits system time counter overflow.
>> 
>> Concerning second point, I made the test you proposed.
>> I patched into GetCurrentAudioTime:
>> I'm waiting for first move of audio device samples played, store 
>> system time and samples played at that point. On further calls to 
>> GetCurrentAudioTime I check the difference between samples played 
>> converted to time and system time.
>> 
>> The result is a negative drift of system time. System time looses 
>> about 25 ms every minute. This makes 42 micro seconds every 100ms. 
>> Anyway, on my device, the playing time computed from samples 
>played is 
>> discreet i.e.: the resolution is about 5 ms.
>
>Ok, 25ms/minute is not too bad if you re-sync with the real 
>audio device every 100ms or so. I think you will find that the 
>number, 25ms/minute, will change quite a bit for different 
>audio devices, some will even go the other direction.
>
>So, I think you change is now good but I would still add a 
>preference that defaults to 100ms to control how often you 
>check the real audio device.
>
>If you are driffting 25ms/minute, I think you could even check 
>a little less often, maybe every 250ms.
>
>--greg.
>
>
>> 
>> I joined the trace I made. You can see the number of calls made to 
>> GetCurrentAudioTime: 22794 in 121880 ms This makes a mean 
>call every 5 
>> ms. Looking more precisely, you can see there are usually 5 calls 
>> gathered in about 4 ms.
>> 
>> Br, Jocelyn
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: Greg Wright [mailto:gwright at real.com]
>> Sent: Friday, November 03, 2006 7:16 PM
>> To: Jocelyn RICARD
>> Cc: datatype-dev at helixcommunity.org
>> Subject: Re: [datatype-dev] CR : Helix/MDF audio - 
>Optimisation of calls to DevSound's SamplePlayed
>> 
>> 
>> Jocelyn RICARD wrote:
>>> Description
>>> This CR was already proposed 3 months ago but did go to the 
>end. This
>>> proposal includes remarks made at that time. It also includes the 
>>> check of the Symbian tick unit.
>>>
>>> The purpose of the change is to lower the calls to the SamplesPlayed
>>> service of DevSound. The reason is this call results in 
>many process 
>>> switches and thus impacts performance an power consumption. The 
>>> proposal is to keep the actual call made on a periodic 
>timer (100ms in 
>>> current mdf adaptation) used to call OnTimeSync, and to replace all 
>>> other calls by a time interpolation since last actual call. 
>The system 
>>> time is obtained using the Symbian service NTickCount. The unit of 
>>> this tick is given through a HAL service with ENanoTickPeriod 
>>> attribute.
>> 
>> Overall this is a sound idea. You need to make sure of a few points
>> however:
>> 
>> o The time reported from GetCurrentAudioTime() must *never* 
>go backwards.
>>    This may happen if your system tick count is running at a 
>different
>>    speed then the audio clock.
>> o You should run a test where you get the time in both 
>fashions at the
>>    same time and see how they may diverge (don't re-sync 
>every 100ms, just
>>    let it run). This is just to give us some idea how both 
>behave in relation
>>    to each other. This data may lead us to change that 100ms 
>sync time to some
>>    other value. Also, we have noticed a big difference in 
>the audio sub-system
>>    from phone to phone, you may want this value to be 
>configurable by 
>> preference.
>> 
>> --greg.
>> 
>> 
>>> Files modified
>>> datatype\mdf\audio\dsp\mdfauddevice.cpp
>>> datatype\mdf\audio\dsp\mdfauddevice.h
>>> datatype\mdf\audio\dsp\Umakefil
>>>
>>> Branches
>>> hxclient_2_1_0_cayenne
>>> HEAD
>>>
>>>
>>>
>>>
>>> 
>---------------------------------------------------------------------
>>> -
>>> --
>>>
>>> _______________________________________________
>>> Datatype-dev mailing list
>>> Datatype-dev at helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>