Opened 12 years ago

Last modified 7 months ago

#1876 assigned bug

Media preferences, clicking on some checkboxes switches back to first tab

Reported by: aldeck Owned by: leavengood
Priority: normal Milestone: R1
Component: Add-Ons/Media/Mixer Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


In Media preflet, go to the audio mixer's "Setup" tab, click some (not all shows the behavior) checkbox and the tabview will switch back to the first tab (Gain controls).

haiku hrev24155, vmware, this is not a recent bug.

Change History (14)

comment:1 by korli, 12 years ago

Component: Preferences/MediaAudio & Video
Owner: changed from korli to marcusoverhagen

I think it's because these checkboxes change the display of the audio mixer (a feature)

in reply to:  1 comment:2 by aldeck, 12 years ago

Replying to korli:

I think it's because these checkboxes change the display of the audio mixer (a feature)

Ahh, i see! Not sure if it's nice though, especially when there's no mixer (no supported hardware) :-)

comment:3 by stpere, 12 years ago

Is there a way we could rather notify the user that something changed in the mixer? it felt like a bug to me, having the setup slip under my feets suddenly when clicking a button, without having pressed apply or anything.

comment:4 by agildehaus, 11 years ago

This is an issue I would also like to see addressed. Completely confused me when I first came across it. There's really no reason for the tab switch.

comment:5 by anevilyak, 11 years ago

The problem is with the way that it's done currently, the mixer generates a new parameter web when its settings are changed, since as mentioned previously some of those settings cause more options to appear/disappear. As a consequence when the new parameter web is put in place, the old is in effect destroyed and the new put in place. In other words, the reason you see a tab switch is because the TabView/Settings panel you clicked the checkbox in no longer exists, a freshly created one was put in place which knows nothing about where you were previously. Right now I see no easy way to change that.

comment:6 by axeld, 11 years ago

A BParameterGroup has a name, and the panel could just remember the current one, and try to make it active again after changes.

comment:7 by anevilyak, 11 years ago

I thought I posted an update to this last night, but apparently not: the real problem is that some of the parameter change notifications from the media server aren't being reacted to appropriately. From a quick glance I assume this needs to be happening in BMediaTheme but I may be wrong. The current mechanism of forcing the whole web to be rebuilt is an intentional hack to work around that (cf. src/add-ons/media/media-addons/mixer/AudioMixer.cpp line 1642). Your way would work, certainly, but it still leaves a hack in place that hides the real problem.

comment:8 by axeld, 11 years ago

Oh, good point. When a parameter web is changed, a certain notification is sent, and obviously ignored in the default BMediaTheme. So yes, it would be preferred to fix this the right way.

comment:9 by diver, 8 years ago

Component: Audio & VideoAdd-Ons/Media/Mixer
Version: R1/pre-alpha1R1/Development

comment:10 by vidrep, 4 years ago

I tried this one out and it is still a problem with hrev50450 x86_gcc2.

comment:11 by diver, 14 months ago

Resolution: fixed
Status: newclosed

Can't reproduce anymore. Probably fixed in hrev52782.

comment:12 by waddlesplash, 14 months ago

Resolution: fixed
Status: closedreopened

Turns out there was a serious bug in that commit; hrev52799 fixes it and reintroduces this ticket. It also happens on menu fields now.

comment:13 by leavengood, 8 months ago

Owner: changed from marcusoverhagen to leavengood
Status: reopenedassigned

So we still have this hack, obviously:

I suppose no one knows why? :)

But it must be something in our BMediaTheme at least. I will take over this ticket but will not work on it for a while I think.

comment:14 by leavengood, 7 months ago

Regarding Axel and Rene's comments in 7 and 8 above: I don't see how the default media theme could know what it needs to change when parameters are changed in this way. For example if the channel count changes and we need more sliders, how is the media theme supposed to know that? The channel count seems to be internal knowledge to the mixer.

But maybe the way the parameter web is built could be adjusted for this.

It is still true that the B_MEDIA_PARAMETER_CHANGED message sent from the mixer side is not handled in the default media theme.

So maybe this could be fixed with a combination of adding support for handling that message in the media theme, and adjusting aspects of how the mixer handles settings so that the theme can know how many channels there are for purposes of setting the channel count in the parameter.

I'll keep looking at it and do some testing to try to sort it out. Other aspects of the mixer code are quite strange, like this if statement with "&& 1" at the end, which is used in several places:

I can't really tell from the Git history who wrote that or why because this code was imported this way from SVN and the commit message is just "added balance control to output":

This is very old code, it may be worth doing a more thorough audit and clean up because the mixer is pretty important for audio output...

Note: See TracTickets for help on using tickets.