[vlc-devel] [PATCH 14/18] Add KAI audio output module for OS/2
KO Myung-Hun
komh78 at gmail.com
Fri Oct 21 18:37:19 CEST 2011
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
More information about the vlc-devel
mailing list