Re: [Ekiga-list] PTLIB alsa plugin status

Derek Smithies wrote:

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 :-)


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