[vlc-devel] [PATCH 14/18] Add KAI audio output module for OS/2

[KO Myung-Hun]

Rémi Denis-Courmont wrote:
> Le vendredi 21 octobre 2011 17:22:22 KO Myung-Hun, vous avez écrit :
>> Rémi Denis-Courmont wrote:
>>> On Thu, 20 Oct 2011 21:30:21 +0900, KO Myung-Hun <komh at chollian.net>
>>>
>>> wrote:
...
>>>> +
>>>> +        /* Get the next audio data buffer */
>>>> +        p_aout_buffer = aout_PacketNext( p_aout, next_date );
>>>
>>> next_date should include the (estimated) latency of the audio hardware
>>> output and buffer. Otherwise lip sync will not work.
>>
>> What is 'lip sync' ?
> 
> http://en.wikipedia.org/wiki/Audio_to_video_synchronization
> 

Thanks for the infos.

BTW, I could not find 'lip sync'(in my term, 'AV sync') fails in my
movies although I don't know I understood it correctly.

>>>> +
>>>> +        if(!p_aout_buffer)
>>>> +        {
>>>> +            // means we are too early to request a new buffer?
>>>> +            mwait( next_date - AOUT_MAX_PTS_ADVANCE/4 );
>>>
>>> This should probably 'continue'.
>>
>> Just 'continue' ? I think, it will cause CPU load to 99.9% unless we
>> give up time slice.
> 
> You're calling mwait(). If you mean to say that using mwait() is a bad idea, I 
> agree, but it's your code not mine.
> 

I meant to use 'continue' instead of mwait(). Do you mean to use it
after mwait() ?

If so, I'll do that.

>>> It should even break out of the loop if
>>> i_len is non-zero, assuming KAI tolerates short reads.
>>
>> Do you mean that i_len shorter than i_buf_size should be return ?
> 
> If it works.
> 
>> KAI recognizes a shorter return value than i_buf_size as a end signature
>> of a stream.
> 
> Then not.
> 
> But then aout_Packet*() is not appropriate.
> 

Why ?

>>>> +            next_date = mdate();
>>>> +            p_aout_buffer = aout_PacketNext( p_aout, next_date );
>>>> +        }
>>>> +
>>>> +        if ( p_aout_buffer != NULL )
>>>> +        {
>>>> +            vlc_memcpy( ( uint8_t * ) p_buffer + i_len,
>>>> +                        p_aout_buffer->p_buffer,
>>>> +                        p_aout_buffer->i_buffer );
>>>
>>> I don't understand how you ensure that
>>> i_len + p_aout_buffer->i_buffer <= i_buf_size
>>
>> I think the following codes ensures this.
>>
>>     aout_PacketInit( p_aout, &p_sys->packet,
>>                      ks_obtained.ulBufferSize / i_bytes_per_frame );
> 
> This ensures that:
> p_aout_buffer->i_buffer == ks_obtained.ulBufferSize / i_bytes_per_frame
> 

p_aout_buffer->i_buffer == ks_obtained.ulBufferSize ?

> Maybe:
> i_buf_size == ks_obtained.ulBufferSize / i_bytes_per_frame
> 

i_buf_size is a multiple of ks_obtained.ulBufferSize.

> Though this is not obvious. But even then, this proves:
> p_aout_buffer->i_buffer <= i_buf_size
> 

p_aout_buffer->i_buffer( == ks.obtained.ulBufferSize ) is a divisor of
i_buf_size.

> So this assumes i_len == 0. Then the loop is not designed correctly.
> 

I don't understand why this assumes i_len == 0.

Anyway, i_len set to 0 at first.

>>> Hmm, this is VLC audio output cargo cult programming. In practice, most
>>> outputs do not need zeroes.
>>
>> Even if we could not get any packets from VLC, there is no need to fill
>> the audio buffers for audio output such as KAI with zeros ?
> 
> That depends on the audio API. Most will just play zeroes implicitly if they 
> underrun, which is OK. Some will instead replay the buffer again, which is 
> bad.
> 

The audio API is of VLC ? Or the one of audio driver of the OS ?

As I said before, KAI expects a call-back function fills a audio buffer
fully.

So when partial underrun occurs, there is need to fills a remaining
buffer with a silence.

But, when full underrun, that is, the situation that KAI cannot get the
audio buffers at all filled by call-back function in a proper time, KAI
play zeroes.


-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.0.14
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr