[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Implementing sound support for non-standard ha

From: Simon Morlat
Subject: Re: [Linphone-developers] Implementing sound support for non-standard hardware
Date: Tue, 21 Dec 2004 18:24:02 +0100
User-agent: KMail/1.7.1

> Very good! So I can continue my work using linphone 0.12.2 until you
> publish the new release on your web page.
Yes !
> Let me summarize our e-mail conversation on that problem here:
> - The sound card does not have a "granularity".
> - It only has a certain latency that can be requested using the call
>   sndcard.c::snd_card_probe(). But when the oss read filter is
>   initialized, it does not probe the sound card's latency.
yes, snd_card_probe() is used to test the availability of the sound card (can 
it be opened now?) and its minimum latency, that is used to configure the rtp 
jitter interval.
> - Instead the filter uses r->gran=(512*r->freq)/8000;
>   to calculate the granularity (in msossread.c::ms_oss_read_start()).
Yes, I don't like much this way, maybe I'm going to change that as I've added 
a new ms_fifo_update_wr_ptr() function to tell the fifo precisely what have 
been written/
> - snd_card_read() must fill the user supplied buffer entirely. That's
>   the condition for the whole thing to work.
Yes it is, but I may change this.
> > 
> I am still pondering how this filter-fifo-queueing works, when every
> 20ms there is an input of 256 samples (512 bytes from the soundcard),
> but only 160 samples are output through the RTP packet.
No: you miss that 256 samples are outputed only when snd_card_has_data() 
returns true, so that normally we never exceed 8000 samples per seconds on 

What I don't like in the current implementation is that snd_card_has_data() 
can return true but you don't know how much bytes are really available 
without blocking.
Maybe I would prefer snd_card_read() to never block and return as much bytes 
as possible, and remove snd_card_has_data() . But the problem is that some 
oss drivers don't like non blocking mode at all...
Complex things.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]