[Alsa-user] ALSA-only apps sharing hardware with PulseAudio

[Matt G. <mat...@gm...>]

My use-case is as follows: I have a headless PC (a Raspberry Pi) that
I want to use as a generic sound server.  I want to run three audio
applications on this; two of those apps will talk to ALSA directly,
and one needs to use Pulseaudio.  I have only one actual hardware
audio interface, a USB DAC.  So all three apps need to share the same
hardware.  Also, the USB DAC provides hardware-based volume control; I
would like all apps (regardless of being ALSA- or PulseAudio-based) to
also share that control.

My understanding is that there appears to be two different ways to do this:
   (1) Configure the dmix plugin for ALSA, and have all applications,
including PulseAudio, use dmix (rather than any one app directly
taking exclusive control of the hardware device)
   (2) Configure a "pulse" virtual ALSA device that allows ALSA apps
to use the ALSA API as a passthrough to PulseAudio

And maybe there are other ways?

My question is: is one way better than the other?  Or, maybe a better
question, what are the pros and cons of each approach?

It feels like the second option is more typically recommended, but I
find that counter-intuitive, since if the application is written
against the ALSA API, why does PulseAudio need to be involved at all?
The app pushes data to ALSA, which forwards to PulseAudio, which
ultimately pushes it back to ALSA.

A related question: is there any way to maintain "bitperfect" playback
with any of these device-sharing schemes?  That is, if there is only
one application using the device, then the PCM data will be passed
directly to the DAC, without any resampling.  Only if the hardware
does not support the sample rate, or if multiple applications want to
output sound simultaneously, will the PCM data be changed from the
source.

Thanks!
Matt