It seems that when the second remap sink appears, module-stream-restore wants to move the first remap sink on top of the second one, and that fails. Apparently you've at some point moved some stream with media.role=filter to the second remap sink, and that's why module-stream-restore wants to do the move. I'm able to reproduce the crash.

So there are two bugs: it doesn't make sense to use the routing for all filter sinks, so module-stream-restore should somehow be made to ignore the filter sinks' virtual streams, and then there's the crash that can probably be reproduced with a less contrived setup as well.

I'll mark this bug as a release blocker due to the crash, but hopefully I'll find time for fixing the stream-restore problem as well.

As a workaround, you can try deleting ~/.config/pulse/*stream-volumes*. That will make module-stream-restore forget your old stream volume and routing preferences. That should allow you to at least start pulseaudio.

(In reply to Tanu Kaskinen from comment #1)
> it doesn't make sense to use the routing for all filter sinks

I meant to say "to use the *same* routing for all filter sinks".

OK so the workaround allows me to start PulseAudio again, which is great, thank you!

I don't exactly understand how module-stream-restore interacts with the module-remap-sink as my knowledge on PulseAudio is limited. However now that PulseAudio doesn't crash I find the virtual sinks don't work as I expected: 

When I use the remapped sinks they sometimes both use the front-left and front-right channels from the master device and they sometimes both use the rear-left and rear-right channels from master. This seems to depend on whether I first output sound on the "Main" sink or on the "Line" sink. When I open the "Main" sink before the "Line" sink, then both will map to the front-channels, else to the rear-channels. This seems strange...

My Setup:
My setup is a usb multichannel soundcard with 8 analog output channels (4xstereo outs). PulseAudio by default thinks I have a 7.1 surround setup. What I want is to have each of the 4 stereo outputs available as a separate sink.

Do I have a configuration error?

I plugged in my own usb surround sound card and tried your configuration, and I didn't have the trouble you're describing.

When you observe the problem, what does "pactl list sink-inputs" print? Do both of the module-remap-sink streams have the same index in the "Sink:" field (it should be the index of the master sink)?

If the streams are routed correctly, you can check the mixing matrix from the log. In the log you attached earlier, the matrix of the first remap sink looks like this:

D: [pulseaudio] resampler.c: Channel matrix:
D: [pulseaudio] resampler.c:        I00   I01 
D: [pulseaudio] resampler.c:     +------------
D: [pulseaudio] resampler.c: O00 | 1.000 0.000
D: [pulseaudio] resampler.c: O01 | 0.000 1.000
D: [pulseaudio] resampler.c: O02 | 0.000 0.000
D: [pulseaudio] resampler.c: O03 | 0.000 0.000
D: [pulseaudio] resampler.c: O04 | 0.000 0.000
D: [pulseaudio] resampler.c: O05 | 0.000 0.000
D: [pulseaudio] resampler.c: O06 | 0.000 0.000
D: [pulseaudio] resampler.c: O07 | 0.000 0.000

and the second one:

D: [pulseaudio] resampler.c: Channel matrix:
D: [pulseaudio] resampler.c:        I00   I01 
D: [pulseaudio] resampler.c:     +------------
D: [pulseaudio] resampler.c: O00 | 0.000 0.000
D: [pulseaudio] resampler.c: O01 | 0.000 0.000
D: [pulseaudio] resampler.c: O02 | 1.000 0.000
D: [pulseaudio] resampler.c: O03 | 0.000 1.000
D: [pulseaudio] resampler.c: O04 | 0.000 0.000
D: [pulseaudio] resampler.c: O05 | 0.000 0.000
D: [pulseaudio] resampler.c: O06 | 0.000 0.000
D: [pulseaudio] resampler.c: O07 | 0.000 0.000

Those seem to be correct: the two input channels from the first remap sink go to channels 0 and 1 of the master sink, and from the second remap sink they go to channels 2 and 3 of the master sink.

Is this stuck on us requiring more information now?

No, the crash is reproducible. The channel mapping thing is a separate bug.

The crash is already solved with commit 
edc465da77874a1058cec0ab3714922e1ec0cc27
and the moving on top of the first sink
problem was solved with commit
73cc75dd8620d9c4d72fba52e9da2f0df5f83120
I think the bug can be closed.

(In reply to Georg Chini from comment #7)
> I think the bug can be closed.

Yep. I forgot that you already fixed this crash.