Value of multi_mix_value::id provied with B_MULTI_SET_MIX is differ from one set in multi_mix_control::id.

[siarzhuk]

The Problem:

Id of control, provided by media server to driver with B_MULTI_SET_MIX call is differ from id assigned by the driver on creating controls list in the handler of B_MULTI_LIST_MIX_CONTROLS call. Such behavior was observed for B_MULTI_MIX_GAIN type of controls with non-zero master (for example right channel of the the stereo gain control). The id of this slave control is equal to incremented id of it's master control instead of this control id.

To illustrate the problem I have added following changes to the null_audio driver:

Index: null_multi.c
===================================================================
--- null_multi.c	(revision 28803)
+++ null_multi.c	(working copy)
@@ -155,8 +155,27 @@
 
 	parent = create_group_control(data->controls +0, 0, 0, 0, "Record");
 	parent = create_group_control(data->controls +1, 1, 0, 0, "Playback");
-	data->control_count = 2;
+
+    data->controls[2].id = MULTI_AUDIO_BASE_ID + 100; // 1124
+    data->controls[2].parent = parent;
+    data->controls[2].flags = B_MULTI_MIX_GAIN;
+    data->controls[2].master = MULTI_AUDIO_MASTER_ID;
+    data->controls[2].string = S_GAIN;
+    data->controls[2].u.gain.min_gain = 0.;
+    data->controls[2].u.gain.max_gain = 100.;
+    data->controls[2].u.gain.granularity = 1.;
+
+    data->controls[3].id = MULTI_AUDIO_BASE_ID + 200; // 1224
+    data->controls[3].parent = parent;
+    data->controls[3].flags = B_MULTI_MIX_GAIN;
+    data->controls[3].master = data->controls[2].id;
+    data->controls[3].string = S_GAIN;
+    data->controls[3].u.gain.min_gain = 0.;
+    data->controls[3].u.gain.max_gain = 100.;
+    data->controls[3].u.gain.granularity = 1.;
 
+	data->control_count = 4;
+
 	return B_OK;
 }
 
@@ -334,8 +353,16 @@
 		case B_MULTI_SET_GLOBAL_FORMAT:			return set_global_format(cookie, arg);
 		case B_MULTI_GET_CHANNEL_FORMATS:		return B_ERROR;
 		case B_MULTI_SET_CHANNEL_FORMATS:		return B_ERROR;
-		case B_MULTI_GET_MIX:					return B_ERROR;
-		case B_MULTI_SET_MIX:					return B_ERROR;
+		case B_MULTI_GET_MIX:					return B_OK;
+		case B_MULTI_SET_MIX:					
+		{
+			multi_mix_value_info *info = (multi_mix_value_info *)arg;
+			int i = 0;
+			for(i=0; i < info->item_count; i++) {
+				dprintf("SET_MIX:item #%d id:%d\n", i, info->values[i].id);
+			}
+			return B_OK;
+		}
 		case B_MULTI_LIST_MIX_CHANNELS:			return list_mix_channels(cookie, arg);
 		case B_MULTI_LIST_MIX_CONTROLS:			return list_mix_controls(cookie, arg);
 		case B_MULTI_LIST_MIX_CONNECTIONS:		return list_mix_connections(cookie, arg); 

I have expected such behavior:

KERN: SET_MIX:item #0 id:1124
KERN: SET_MIX:item #1 id:1224

but real attempt to touch gain control has following result:

KERN: SET_MIX:item #0 id:1124
KERN: SET_MIX:item #1 id:1125

The Question:

Is such behavior intended???

PS: Current implementation of the Haiku multi-audio drivers is not affected by this problem because all they use the same algorithm of creating controls list. This algorithm assign id to controls by increment. I have tried to write more compact code for controls creation in my sis7018 driver and observed this issue.

[siarzhuk]

Patch mentioned in the problem description

[korli]

Could you check with hrev28811 please ?

[siarzhuk]

Crashing MUX control declaration.

[siarzhuk]

Yes the control id is now correctly provided. Thank you!

BTW, after those changes I observe access violation in media_addon_server on first attempt to look on the card mixer pane. Stack crawl is attached. What can be wrong with following MUX control declaration?

+    data->controls[4].id = MULTI_AUDIO_BASE_ID + 300;
38	+    data->controls[4].parent = parent;
39	+    data->controls[4].flags = B_MULTI_MIX_MUX;
40	+    data->controls[4].string = S_GAIN;
41	+
42	+       for(i = 0; i < 3; i++) {
43	+               data->controls[i + 5].id        = data->controls[4].id + i + 10;
44	+               data->controls[i + 5].flags     = B_MULTI_MIX_MUX_VALUE;
45	+               data->controls[i + 5].master    = 0;
46	+               data->controls[i + 5].string    = S_null;
47	+               data->controls[i + 5].parent    = data->controls[4].id;
48	+               strncpy(data->controls[i + 5].name, srcs[i], sizeof(data->controls[i + 5].name));
49	+       }

Adding it to my test driver - forces the media_addon_server to crash in mentioned situation.

PS: How can I debug trace such problem in the media_addon_server? I tried to enable PRINTING define in MultiAudioNode.cpp, but looks like it doesn't help. The media_server "printf" output can be catched in the Terminal but how to restart only media_addon_server without media_server? ;-)

[siarzhuk]

Stack crawl for media_addon_server crash on my "invalid MUX control"

[korli]

Should be a bug in my last commit. Will fix ASAP.

[korli]

Please check in hrev28815.

[siarzhuk]

No more problems observed. Thank you!