Are these multiple servers running under the same user or under different users? If they are running under the same user, then all instances will try to probe the sound card, but since the audio devices can be opened by one process at a time only, the fastest instance wins.

I don't know what you expect to happen - do you think all instances should be able to use the same hardware simultaneously?

(In reply to Tanu Kaskinen from comment #1)
> Are these multiple servers running under the same user or under different
> users? If they are running under the same user, then all instances will try
> to probe the sound card, but since the audio devices can be opened by one
> process at a time only, the fastest instance wins.

They are running under different users.

> I don't know what you expect to happen - do you think all instances should
> be able to use the same hardware simultaneously?

Maybe not, but all devices should be discovered by all daemons, even if daemons can't use them for any reason. It is the case when PulseAudio daemons are started with an already plugged audio card. But not when the same audio card is disconnecting and reconnecting ; device discovery shares the devices between the different PulseAudio daemons.

Thanks for the information. I'll try to reproduce this on Friday (I don't have access to a USB sound card right now).

> 
> Maybe not, but all devices should be discovered by all daemons, even if
> daemons can't use them for any reason. It is the case when PulseAudio
> daemons are started with an already plugged audio card. But not when the
> same audio card is disconnecting and reconnecting ; device discovery shares
> the devices between the different PulseAudio daemons.

device probing/discovery is not share by different pulse daemons

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/module-udev-detect.c?id=d6fb8d10819bebc1cee203de7330cceeafde9fed

Created attachment 117683 [details]
pulseaudio threads for devices discovery

(In reply to Tanu Kaskinen from comment #3)
> Thanks for the information. I'll try to reproduce this on Friday (I don't
> have access to a USB sound card right now).

I made tests again on my side too with the same hardware, same behaviour.
Tow PA daemons, one in 'test' user, another in 'samuel' user, then I plug my USB audio card:
 - 'test' daemon discovers only output 'alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00-CODEC.analog-stereo.monitor'
 - 'samuel' daemon discovers only input 'alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00-CODEC.analog-stereo'

But when I continue to unplug/plug my audio card, sometimes and randomly, 'samuel' daemon discovers the two device, and none for 'test' daemon.

Configuration:
PulseAudio: 5.0
OS: Debian Jessie stable 64bits
Audio Card: USB Dual Pre Project Series

I post a simple screenshot that can illustrate my talks, a graphical tree view of the two daemon processes with device discovered (threads name)

pulseaudio server keep the cards profile in .config/pulse/machine-id-card-database which is maintaned by
http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/module-card-restore.c

The process tree image shows that you're running the test user's pulseaudio instance under sudo. The expected result in that case is that the test user doesn't get access to the hardware, because sudo doesn't create a session in logind, and pulseaudio's multiuser support relies on logind/udev to grant sound card access only to the active session.

The likely reason why the test user has access to the sound card anyway in your case is that Debian adds users to the "audio" group by default, and users in the "audio" group always have access to the sound cards.

If your use case is just the regular "allow two users to be logged in, with only one login session active at a time", then removing the users from the "audio" group should help.

how can logind/udev limit the access of card to specific user ?

desktop have more the one usb ports and user may put usb audio on different usb port

two users may put two usb audio of same model on different usb port

the drawback of limit the access of card to one user is

those 7.1+2 hda codec used by desktop usually have three audio inputs  and three input pins:rear mic, front mic and line in , can these three captures devices assign to different users

some display port support multistreaming and three monitors can connect in dasiy chain which allow different audio stream playing at different monitors at the same time

(In reply to Raymond from comment #9)
> how can logind/udev limit the access of card to specific user ?

logind keeps track of what sessions exist, what "seats" exist, and which session is the active one on each seat, and based on that information, udev gives access to the active user for hardware that has been assigned to the seat that the user is on. All sound cards are assigned to "seat0" by default.

> desktop have more the one usb ports and user may put usb audio on different
> usb port
> 
> two users may put two usb audio of same model on different usb port

If the two users are using the computer at the same time, you're talking about a multiseat system. That requires configuring udev so that it knows which sound cards belong to which seat.

(In reply to Raymond from comment #10)
> the drawback of limit the access of card to one user is
> 
> those 7.1+2 hda codec used by desktop usually have three audio inputs  and
> three input pins:rear mic, front mic and line in , can these three captures
> devices assign to different users

If the three inputs appear as separate devices under /dev/snd, then I think udev could in theory assign them to different users. The mixer device (controlCx) would have to be accessible to all users. Configuring this would require much bigger changes to the udev configuration than just assigning a sound card to a particular seat. PulseAudio would most likely have to be adapted too.

(In reply to Tanu Kaskinen from comment #8)
> The process tree image shows that you're running the test user's pulseaudio
> instance under sudo. The expected result in that case is that the test user
> doesn't get access to the hardware, because sudo doesn't create a session in
> logind, and pulseaudio's multiuser support relies on logind/udev to grant
> sound card access only to the active session.
> 
> The likely reason why the test user has access to the sound card anyway in
> your case is that Debian adds users to the "audio" group by default, and
> users in the "audio" group always have access to the sound cards.
> 
> If your use case is just the regular "allow two users to be logged in, with
> only one login session active at a time", then removing the users from the
> "audio" group should help.

In my use case the two PA daemons should have access to sound.

One is a regular user and should have access to the embedded audio card for playing sound and other stuff.
Another is a system daemon that acquires sound via the external USB sound cards and via PulseAudio. This daemon is launched with restrained permissions and with its proper user/group. You're right, I had to add my daemon to 'audio' group for having access to audio with PA.

To summarize, a user session should access to the internal sound card, my system daemon to the external sound card. But the previously described behavior prevent my daemon to have access to the USB sound card when disconnecting / reconnecting.
If I have well understood, a possible workaround may be to configure udev permissions to only give access at the sound card to my system daemon group ?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/232.