I am running two users at the same time because some games don't like compositing window managers, and you can't turn off compositing in Unity, my favored desktop. I don't want to run two TTYs of the same user because they interact with each other in unfortunate ways. I'm running Ubuntu 16.04.

One user, jonathan, is in a unity session in TTY7, the other, steamdude, is in an XFCE session in TTY2. Everything works as I want it to, except for audio. Once I added both users to the audio group and relogged, I could hear audio from one TTY while in the other TTY. However, when one user is using the sound card, the other user can't play audio at all.

The closest to a solution that I have (and I don't know why it works), is using paprefs to enable an RTP device to loopback in the Unity session. steamdude don't need to connect to the RTP device; the loopback doesn't interfere with TTY2's sound for some reason. The problem is that there's a longstanding bug in module-loopback that causes it to have latency as long as a second. Manually looping with

pacat -r --latency-msec=1 -d rtp.monitor | pacat --latency-msec=1 -d alsa_output.pci-0000_00_1b.0.analog-stereo

fixes the latency issue but doesn't solve the problem; the sound card lockout issue comes back.

Potential solutions, most ideal first, include:

1) Piping audio directly from one user to the other

The first, obvious thing I tried that did not work was

pacat -r --latency-msec=1 -d rtp.monitor | sudo -u steamdude pacat --latency-msec=1 -d alsa_output.pci-0000_00_1b.0.analog-stereo

This failed with the following output:

Home directory not accessible: Permission denied
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
write() failed: Broken pipe

Note that both users are in each other's groups, which I granted full control over their home directories via chmod and setfacl.

2) Piping audio through RTP Multicast from one user to another

I don't know how to do this, because pulse doesn't show me streaming devices from the same computer.

3) Sending audio from one TTY to a lightweight virtual machine (or a specially designed chroot?) in the other TTY via RTP.

This ought to work, but it is the least elegant of all possible solutions and takes up significant system resources.

I'm willing to do any of these things, but I'd rather know how to do it in the most efficient way possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.