Re: [Ekiga-list] PTLIB alsa plugin status

[Derek Smithies <derek indranet co nz>]

Hi,
 >>> - 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??
This mutex is important, and should not syncrhonize the play&record threads.

There are two PSoundChannel class instances active during a call.
One for play.
One for record.

These PSoundChannel class instances are seperate, and have seperately 
opened connections to the sound_alsa plugin. Consequently, the mutex you 
refer to is not syncrhonising access to play&record.

The mutex is locking access to play variables (device pointers) + play

A different mutex instance is locking access to write variables (device 
pointers) + write.

==================

Now, if the same PSoundChannel instance is used for play and record - 
(which can be achieved by bad application writing) then you have an 
application coding problem. I assume Ekiga does not have this issue.


=========================================

> 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.
Agreed.

Derek.

On Tue, 24 Feb 2009, Alec Leamas wrote:

> 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
> _______________________________________________
> ekiga-list mailing list
> ekiga-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-list

--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek indranet co nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/