[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-developers] Implementing sound support for non-standard ha
Re: [Linphone-developers] Implementing sound support for non-standard hardware
Tue, 21 Dec 2004 18:24:02 +0100
> Very good! So I can continue my work using linphone 0.12.2 until you
> publish the new release on your web page.
> 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
> - 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
> - 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
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...
Re: [Linphone-developers] Implementing sound support for non-standard hardware, Daniel Kabs [ML], 2004/12/15