Re: [Ekiga-list] PTLIB alsa plugin status

[Alec Leamas <leamas alec gmail com>]

Derek Smithies wrote:
> Hi,

Hi :-)

Have you checked the bugzilla bug? There's  some more meat on the bones 
(or however you prefer to say it down there ;-)
> On Tue, 24 Feb 2009, Alec Leamas wrote:
> > - Playback and record thread are synchronized in a way that forces 
> > the two streams to wait for each others I/O operations.
> Yes - can someone test that ptlib alsa plugin works ok with this mutex 
> removed??
It's not just a question of testing. This kind of problem must be 
handled by careful reading of code, to test all conditions possible when 
there are concurrent threads is not that simple. I think what should be 
done is to separate the recording and playback threads into separate 
objects, thus letting the compiler check  that there are no critical 
zones. I also think the whole idea of a single "channel" must be 
interpreted as a facade for two more or less independent streams . They 
should not really share any data. But of  course they share  a lot of 
behaviour.
> > - There is no rebuffering support. This means data underruns sounds 
> > worse than necessary.
> What is required to do rebuffering? Any code suggestions?
Well, the basic thing is a separate thread feeding alsa started when 
alsa is started. The write routine just drops it's buffer to the thread 
through some kind of thread-safe mechanism, being blocked if there is no 
space in (a small)  buffer. The thread is just waiting for alsa 
(snd:_pcm_wait). When started it  normally transfers data from upstream 
(write), rebuffering as necessary  if there is nothing else to send.
> > In my opinion, it's not really worth to put much work on using the 
> > current alsa plugin. As long as it works, don't touch it... until it 
> > get's fixed in a proper way, possibly by using a pulse plugin instead.
> It is worth it. Alsa will be around for a long time. This is an 
> opportunity for Ekiga people to contribute back to ptlib&opal 
> (libraries that are crucial to this project)
OK, unless you provoke you don't get an answer... I actually share your 
opinion :-)
> > As for the latency discussion about alsa vs pulse: This review shows 
> > that anything will be much better than current alsa code...
> The current alsa code works mostly.. it is close.. If there was some 
> usable docs at alsa to explain what is not good, that would help.
> Anyone able to work out what is actually wrong in the alsa plugin?
But we have 100 ms of hw buffer,  roughly twice the size of other VOIP 
applications. There are  open issues about the overall design, threads, 
objects etc.  There are no quality metrics, we have no idea about things 
like bytes transferred, hard errors, soft errors, buffer usage etc. And 
Andreas'  logs shows that the driver does not deliver data as expected.  
I don't want to blame anyone or so, but I think we must face the fact 
that there *are*  problems, some of them requiring more than a point fix.

As I said, take a look at the bug, there are some more details, despite 
the horrible formatting. And bear in mind that I'm  certainly wrong from 
time to time.  And that English isn't my native language, the nuances 
are a bit bit, well, rough now and then :-)
> Derek.
--alec