Summary:	ASTERISK-13755: [patch] Missing mute facility
Reporter:	nick_lewis (nick_lewis)	Labels:
Date Opened:	2009-03-16 10:18:34	Date Closed:	2009-11-12 17:43:42.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_alsa
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_alsa.c-oneway.patch ( 1) chan_alsa.c-oneway2.patch ( 2) chan_alsa.c-oneway3.patch
Description:	chan_oss.c has a mute facility for the console phone. This facility is missing from chan_alsa.c. Please find attached a patch that adds the facility. The patch permits the initial mute state to be defined in the conf file. This is useful in conjunction with auto-answer for call screening purposes. Also the patch ensures that the console will not attach to a sound capture port if a noaudiocapture parameter is set in the conf file. This permits the console phone to be connected to a public address system which has no return audio path. It also frees up the sound capture port for streaming or live music on hold uses.
Comments:	By: Jason Parker (jparker) 2009-11-06 13:21:47.000-0600 Would you be able to upload a new patch with some coding-guidelines issues fixed?  Mostly just whitespace (typically where you use "if(!noaudiocapture) {"), where you need to indent some blocks. Also one-line if statements need braces, such as (the latter is correct for new code): if (foo) bar vs if (foo) { bar } By: Jason Parker (jparker) 2009-11-06 13:22:36.000-0600 oh, and noticed after I posted that last comment.  Spaces need to be after if. if(!noaudiocapture) vs if (!noaudiocapture)  (the latter is correct) By: nick_lewis (nick_lewis) 2009-11-09 03:27:19.000-0600 I have uploaded another patch which I hope is better formatted By: Jason Parker (jparker) 2009-11-09 12:40:28.000-0600 Patch 3 looks much better, thank you. I could probably commit this as-is, but I wanted to propose an idea first. Do we really need noaudiocapture?  The reason for it seems to be so that the system doesn't keep the capture device open.  I don't think that's really a problem though.  With a sane ALSA configuration, multiple applications can open the same device (as long as you aren't trying to access the hardware directly - using "default" will usually make this "Just Work"). Thoughts?  I'd be happy to upload a version of the patch with those changes, so you could test them (and verify that it works the way I asserted). By: nick_lewis (nick_lewis) 2009-11-10 03:12:50.000-0600 Yes it may work fine in some cases but I have the following concerns (i) On older alsa installations the default did not include dmix and dsnoop so sharing does not work on these systems (ii) Some utilities do not behave well when connecting to a device that is already used. They may hang indefinitely causing wider problems in dependent scripts and applications. (Until a previous fix chan_alsa would hang asterisk in this way.) (iii) The audio capture may be used for an application that is unsuited to being output via the console phone. For example it may be connected to an external radio receiver and used for live music-on-hold. Anyone calling the console phone from their own extension (e.g. to make a public announcement over a PA system) would find it difficult to speak while the music was being played at them. By: Digium Subversion (svnbot) 2009-11-12 17:43:41.000-0600 Repository: asterisk Revision: 229753 U   trunk/channels/chan_alsa.c ------------------------------------------------------------------------ r229753 | qwell | 2009-11-12 17:43:40 -0600 (Thu, 12 Nov 2009) | 11 lines Add mute functionality.  Add config option to not try to open capture device. Adds "console {mute|unmute}" CLI command. Adds mute and noaudiocapture config options (will update sample configs shortly). (closes issue ASTERISK-13755) Reported by: Nick_Lewis Patches:      chan_alsa.c-oneway3.patch uploaded by Nick Lewis (license 657) Tested by: qwell ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=229753