On Sun, 2015-01-25 at 19:30 +0100, Martin Klein wrote: > 2015-01-23 13:25 GMT+01:00 Tanu Kaskinen <tanu.kaskinen at linux.intel.com>: > > On Thu, 2015-01-22 at 20:37 +0100, Martin Klein wrote: > >> 2015-01-21 12:10 GMT+01:00 Tanu Kaskinen <tanu.kaskinen at linux.intel.com>: > >> > On Sun, 2015-01-18 at 13:54 +0100, Martin Klein wrote: > >> >> Okay, this works as expected, i.e. I hear the noise on the intended > >> >> speaker. Thank you for suggesting this test. Now to summarize: In > >> >> principle surround seems to work with both Alsa and Pulse (i.e. I can > >> >> output sound on only the intended speaker). However, both volume > >> >> controls and module-remap-sink does not work for the surround channels > >> >> with pulseaudio. Any ideas on how to debug this further? > >> > > >> > If we still ignore the volume control problem, the next step is to > >> > investigate what goes wrong with module-remap-sink. You said it doesn't > >> > give any output. Check the volume and mute state of the remap sink and > >> > the sink input between the remap sink and the master sink. If those are > >> > ok, check that the mixing matrix looks ok (the matrix is shown in the > >> > debug log of the server when you load module-remap-sink). > >> > > >> Checking the volume and mute state of the remap sink was the first > >> thing I checked. The channel is unmuted, I toggled the mute state and > >> increased the volume to the max. All to no avail. Thank you for your > >> suggestion regarding the channel matrix. Unfortunately I couldn't find > >> any documentation on how to interpret the channel matrix. I think I > >> found the two matrices corresponding to my to remap sinks: > >> http://pastebin.com/CuDjDaM4 > >> I have no idea on how to interpret this. I'm a little bit confused by > >> the separator line for in the first matrix. Also, the asymmetry of the > >> second matrix looks weird to me (there is an empty row between the 1 > >> of the second columns. > > > > The channel factors (the ones and zeros) seem to be correct, but the > > printing is messed up. It looks like each line is duplicated in the log. > > How did you create that log? > > > I started pulseaudio manually with pulseaudio -vvvvv > --log-target=newfile:pulse.log > This looks like some kind of race condition to me, where two threads > try to write the same output? Each line appears two times but not > always next to each other. Very weird. I couldn't reproduce the problem myself with "pulseaudio -vvvvv --log-target=newfile:/tmp/pulse.log" > > I'll explain how to interpret the matrix. In this example I have loaded > > module-null-sink with six channels, and the channel map is > > front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center. Then I play a stream with channel map front-left,front-right, with remixing disabled. The resulting matrix looks like this: > > > > I00 I01 > > +------------ > > O00 | 1.000 0.000 > > O01 | 0.000 0.000 > > O02 | 0.000 0.000 > > O03 | 0.000 1.000 > > O04 | 0.000 0.000 > > O05 | 0.000 0.000 > > > > I00 and I01 are the input channels, and O00-O05 are the output channels. > > The matrix shows that I00 goes to O00 and I01 goes to O03. Other output > > channels don't have any inputs, so they get silence. > > > Thanks for your explaination. The duplication of the lines threw me off. > > > Now, back to your setup, it remains a mystery why you don't get any > > audio with module-remap-sink. The next step could be to record from both > > the monitor of the alsa sink and from the monitor of the remap sink. Are > > one or both of the recordings silent? > > > Recording for all sinks works, although the sound is quite bad (very > noisy) for each monitor sink. So apparently the sound goes somewhere > missing on the way to the actual hardware outputs? If you record from the monitor source of the remap sink, the recorded audio is what is being fed to the remap sink. If that audio is broken, the problem is not in the remap sink. > To be honest, I've somewhat lost my patience with this and just bought > a cheap external usb soundcard to achieve my goal. This works fine for > me. I'm still happy to provide any information you need, if you are > interested in debugging this further. This is just to let you know, > that I've found a workaround for my solution. Thanks for all your > help. Good that you found a solution! I don't think this is super important bug (not reproducible outside your system), so I'm fine with dropping the investigations at this point. -- Tanu
