Summary:	ASTERISK-01824: [PATCH] Patch that repairs the alsa-chan complete
Reporter:	antonverburg (antonverburg)	Labels:
Date Opened:	2004-06-15 07:46:31	Date Closed:	2004-09-25 02:26:27
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_alsa.patch ( 1) chan_alsa-unstable.patch
Description:	The alsa channel was old, outdated and not usable. This patch fixes the whole channel. Now you can use the alsa-kernelmodules to make a call using your soundcard. I've cleaned up the code, so that it does what it should do, and nothing more. Now the alsa-channel is less CPU-intensive  than the OSS-channel. We can now use different devices for input and output. We also have real full-duplex support from now. I've fixed a bunch of bugs, and at least rewriten the whole module. These fixes include: - Answering calls - using a filedescriptor to let channel.c know where and what we are - Making the right dialtones/hanguptones etc. at the right moment. Because it was to my opinion not so simple to understand the code soon, I've included some comments, witch should make clear what-when happens. Now it should be easier in future to detect bugs and keep the module uptodate. I've removed the alsa-monitor functions: I didn't know wat they do, what they are good for and why somebody should need them. There is only one thing that should be implemented; silencesuppression is not available for now. Because I do not longer have time to inplement it, sombebody else should try... You should apply this patch by patch channels/chan_alsa.c < chan_alsa.patch. I've tested both on the semi-stable release and latest CVS-release. ****** ADDITIONAL INFORMATION ****** Those new channels are succesfully tested at Fedora Core 1 using alsa 1.0.2 and kernel 2.4.22 and Redhat 6.2 using alsa 1.0.4 and kernel 2.2.22. I suppose that it will work on every Linux system that uses recent alsa-modules. I've tested the semi-stable release with this patch at both FC1 and RH6.2. Latest CVS-release is tested at FC1 only. I've tested all features, in all directions. Now I can say: this module is OK.
Comments:	By: Mark Spencer (markster) 2004-06-15 09:47:25 Can you confirm this code been disclaimed?  Thanks! By: antonverburg (antonverburg) 2004-06-15 10:03:46 After applying those patches, also bugnote 1614 should be closed. This patches fixes the problems of bug  1614. By: antonverburg (antonverburg) 2004-06-15 10:08:44 Hm, do you mean that I should remove the copyright notice? By: Mark Spencer (markster) 2004-06-15 10:13:38 It just means we have to have a disclaimer on file (see http://bugs.digium.com).  A "long version" disclaimer does not prevent you from retaining copyright to the file, it just places no restrictions on Digium for what we can do with your modifications.  The "short version" disclaimer places your code in public domain.   You may select whichever suits your desires better. Thanks! By: antonverburg (antonverburg) 2004-06-15 10:25:33 OK, you mean something like this. Do I have to mail this message too, or is it enough to post it here? ************************************************************************ Anton Verburg hereby disclaims all copyright interest in the changes and enhancements made by Anton Verburg to the program "asterisk" (the "Program"). Anton Verburg affirms that it has no other intellectual property interest that would undermine this release, or the use of the Program, and will do nothing to undermine it in the future. Anton Verburg         14 Juni 2004 _____________________, __________ Authorized Signature   Date Student ______________________________ Title ************************************************************************ By: Mark Spencer (markster) 2004-06-15 10:40:23 If you can, just fax it to +1-256-864-0464 or if you can't, you can e-mail me a scan. By: Mark Spencer (markster) 2004-06-15 11:14:28 I got your disclaimer, but I can't get the patch to apply to CVS head (1 of 41 chunks fails).  Can you please confirm it's against latest CVS? By: antonverburg (antonverburg) 2004-06-16 04:39:13 Hm, I thought that an cvs update was enaugh to upgrade to latest cvs, but it seems that it only upgraded to latest semi-stable release... Now I did an upgrade to latest version, and it seems that channel.c has been changed. Again, channel.c does not recognize the filedescriptor from the Alsa-module. What's the advantage from using own alsa-poll filedescriptors above a simple FD_ISSET? It breaks my fixes... By: antonverburg (antonverburg) 2004-06-16 07:50:32 Here you've got an patch for the unstable release (chan_alsa-unstable.patch). I am sorry that I've to say that it doesn't work. I can receive sound with the latest CVS-release, but during the sending of frames, something seems to go wrong. I don't know what's wrong, and I don't know how to fix it. The filedescriptor still seems to be OK, because the alsa_read function is called many times during a call. But somewhere, the frames are not send further. I do not have time to fix these problems, so somebody else should do it... By: antonverburg (antonverburg) 2004-06-16 08:07:32 Oh, yeah, there is also a bug in channel.c that lets * crash if you're using chan_alsa and does an hangup. In the old channel.c the function ast_queue_frame() needs an interger 'lock'. In the new one, lock is removed, and it's always locking. Now * segfaults using chan_alsa, but when I remove those locking funcions (ast_mutex_lock(&chan->lock); , etc), it does not segfault. Maybe a pointer to the problem? By: Mark Spencer (markster) 2004-06-16 09:39:20 Locking the channel isn't a bug, obviously.  I'll ask Matt to take a look at it. By: Mark Spencer (markster) 2004-06-26 01:35:18 Okay I've fixed the ALSA driver (at least through my testing) in CVS.  If there is still a problem just create a new ALSA tracking bug