[LAD] Help w/ debian report of mudita24 meters not working?

[Tvrtko Ursulin]

On 17/01/12 18:15, Tvrtko Ursulin wrote:
> On 17/01/12 17:57, Niels Mayer wrote:
>> Re http://code.google.com/p/mudita24/issues/detail?id=6
>>
>> In http://code.google.com/p/mudita24/issues/detail?id=6#c5
>> tvrtko at ursulin wrote:
>>> I had a small peak in your code and it looks you reference this
>>> control by name, not numid, so the bug is probably somewhere else.
>>> I'll grab the current version and give it a spin...
>>> [...]
>>> Right, have 1.1.0 14 runnig now. A more detailed description of the
>>> bug is that meters seem to be sampled once on startup but then they
>>> are otherwise stuck/static. Pressing "Reset Peaks" clears them and
>>> puts in to "(Off)" state.
>>
>> .............
>>
>> Hunch: if the meters work once, the meters work, IMHO. This is a
>> clocking issue. Also, if talking of the level of the "Digital Mixer"
>> meter to the left, you have to make sure that the inputs to the
>> digital mixer are "live." However the mention of "stuck state" means
>> the ICE1712 metering registers are putting out DC at the digital level
>> that they were at when they lost clock.
>>
>> The issue is probably somewhere else. I've seen this sort of thing
>> happen before with the ICE1712 chips when they're "locked up" waiting
>> for clocking, perhaps because the external spdif input in "Hardware
>> Settings"->"Master Clock"->"S/PDIF In" is selected. Even more likely,
>> there's a lockup, because "Multi Track Rate Locking" or "Multi Track
>> Rate Reset" are selected in "Hardware Settings". Deselect, kill any
>> processes using the devices, and start over again.
>>
>> For details, see
>> http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf :-)
>>
>> The lockup will "stick" if the audio device is in use, for example if
>> pulseaudio has grabbed it, or if it's still lingering around in some
>> spinning or zombie jackd. So changing the settings in the ICE1712
>> control panel may not actually take effect until the device is
>> relinquished and can be overridden out of it's locked state via the
>> control panel.
>>
>> Note that this is all said as a hunch. I am not even running an OS
>> that supports the latest GTK changes and I am a Fedora user so there's
>> little chance I'll switch to Ubuntu without getting paid for it. So I
>> guess I'll find out if it's related to later versions of ALSA, GTK, or
>> Linux next time I setup a new machine.... and then I'll stick the
>> Terratec and it's lovely enclosed Yamaha DB50XG clone (NEC XR385) into
>> the new machine, pull down the latest mudita24 from SVN and give it a
>> try again.
>
> I appreciate it was a hunch but I wouldn't have reported that meters are
> not working if I couldn't hear any audio - which would be the case with
> a clocking problem. :)
>
> So no, it is not that and envy24control works fine for example.
>
> Unfortunately I am not a GUI programmer so I wouldn't know how to
> approach any possible GTK issues myself. It was just an observation I
> made in an unrelated thread on LAU which got turned into a bug report.
> It is not terribly important to me I just like the real scale in
> mudita24 as opposed to useless numbers in envy24control.

Here is a fix:

--- envy24control.c	(revision 14)
+++ envy24control.c	(working copy)
@@ -2404,7 +2404,7 @@
  /* NPM for efficiency&power-savings, replaced multiple 40ms&100ms timeouts
     for each of the callbacks contained here, with a single 100ms one which
     calls gtk_timeout_add(100, (GtkFunction)envy24control_poll, ...) */
-void envy24control_poll() {
+gboolean envy24control_poll() {
    level_meters_timeout_callback(NULL);
    master_clock_status_timeout_callback(NULL);
    internal_clock_status_timeout_callback(NULL);
@@ -2412,6 +2412,8 @@
    rate_reset_status_timeout_callback(NULL);
    if (card_has_delta_iec958_input_status)
      iec958_input_status_timeout_callback(NULL); /* NPM */
+
+  return TRUE;
  }