pulseaudio module causes asserts on 32 bit machines (max_latency <= (10*((pa_usec_t))

Question

I am compiling module-virtual-sink.c that comes with pulseaudio 1.1 on Ubuntu 32 and 64 bit platforms running pulseaudio-1.1. When I load the module on 32 bit machines I get the following assertion:

Dec 15 07:57:53 ubuntu pulseaudio[12541]: [alsa-sink] sink.c: Assertion 'max_latency <= (10*((pa_usec_t) 1000000ULL))' failed at pulsecore/sink.c:2971, function pa_sink_set_latency_range_within_thread(). Aborting.

In module-virtual-sink.c:

pa_sink_set_latency_range_within_thread(u->sink, i->sink->thread_info.min_latency, i->sink->thread_info.max_latency);

Is passing over wrong values. i->sink->thread_info.min_latency, i->sink->thread_info.max_latency are passing over 0 and 500 instead of 500 and 100000.

There are 32 bits missing in the thread_info struct which my gcc is generating compared to the struct created by pulseaudio in pa_sink_new right before soft_volume

thread_info.soft_volume

causing wrong values being read and passed on to pa_sink_set_latency_range_within_thread.

struct {
    pa_sink_state_t state;
    pa_hashmap *inputs;
    pa_rtpoll *rtpoll;
    pa_cvolume soft_volume;
    pa_bool_t soft_muted:1;

typedef struct pa_cvolume {
  uint8_t channels;                     /**< Number of channels */
  pa_volume_t values[PA_CHANNELS_MAX];  /**< Per-channel volume */
} pa_cvolume;

(gdb) x /100xb &(u->sink->thread_info)
0x8b6c634:  0x00    0x00    0x00    0x00    0xfe    0xff    0xff    0xff
0x8b6c63c:  0x08    0xd0    0xb6    0x08    0x00    0x00    0x00    0x00
0x8b6c644:  0x02    0x00    0x00    0x00    0x00    0x00    0x01    0x00

(gdb) print (u->sink->thread_info)
$5 = {state = PA_SINK_RUNNING, inputs = 0xfffffffe, rtpoll = 0x8b6d008, soft_volume = {channels = 0 '\000', values = {2,65536, 65536,

thread_info.soft_volume.channels is 0 instead of 2. The compiled code is looking at the wrong position - address 0x8b6c640 instead of 0x8b6c644

I suspect a compiler configuration problem or source mismatch. Needless to say that this was tested using GCC after creating the config.h file using ../configure

Any ideas what might cause this behavior?