Re: 96kHz 24bit WAV playback

John Stirling wrote:
> Greg Wright wrote:
>> John Stirling wrote:
>>> Hi Greg,
>>>
>>> Full log attached.
>>>
>>> The line -
>>> audrend.cpp:WriteToAudioServices OK t=5720
>>>
>>
>> First, it would be helpful if the logs has timestamps
>> at the beginning of each line (HX_TICKCOUNT()). This helps
>> us track time between calls, which can point to certain
>> problems. Next, from part of the log:
> ok i'll try to add that to any future logs
> 
>>
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1483776
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1483776
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1497600
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1497600
>> wvffplin.cpp:GetPacket
>> wvffplin.cpp:RIFFReadDone s=11520 st=5 286 df=(nil)
>> wvffplin.cpp:RIFFReadDone ->PacketReady t=5700
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1497600
>> audrend.cpp:OnPacket to=0 t=5700 s=11520
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1497600
>> audlinux_oss.cpp:_SyncUpTimeStamps c=0
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1382400
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1382400
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1382400
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1396224
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1396224
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1396224
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1396224
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1400832
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1400832
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1400832
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1400832
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1400832
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1400832
>> audlinux_oss.cpp:_GetBytesActualyPlayed c=1400832
>>
>>
>>
>>
>> Why would GetBytesActualyPlayed() go backwards? 1497600-->1382400?
>>
>>
>> Is any rebuffering going on, any pausing? In normal continuous
>> playback, that should just be increasing. It is how we generate
>> the timeline. I would certainly printout the values from
>> getcurrenttime() and make sure it looks good, my guess is that
>> it does not.
> There's no rebuffering or pausing. GetTickTime() looks ok.

You want to test _Imp_GetCurrentTime(). The tick count is
generally always correct. _Imp_GetCurrentTime() uses the
bytes played to compute a time to pass into the media engine.
You need to look at those numbers and make sure they are
always increasing and don't 'jump' around. If BytesActuallyPlayed
is ever decreasing then there is a problem in the audio device
code. I would look and see why. I am guess it has to do with the
sample width being 24 and not 16 or 8. Take a look for any hardcoded
values along those lines.

--greg.



> 
> I think maybe WriteBytes is not getting called regularly enough or the 
> amount of data in that call is not correct.
> WriteBytes gets called
> GetBytesActuallyPlayed gets called a few times
> WriteBytes gets called again, but SyncUpTimestamps intervenes to reduce 
> the BytesActuallyPlayed count.
> 
> Does that sound like a renderer problem ? Or fileformat ? (or neither)
> 
>>
>> Is there some bad math, due to 24 bits/sample, or perhaps some
>> wrap around (INT overflow) happening in the OSS code? It should
>> be easy to check.
>>
>> --greg.
>>
> 
>