Bug 2149919

Gerd - could you provide any thoughts on this bug?  Is this something missing we can/should add to a downstream RHEL/CentOS qemu-kvm build?

> Expected results:
> 
> the qemu-kvm jack audio backend should be supported because pipewire, the
> default audio server on rhel 9, supports and relies on it. 

pipewire supports both jack and pulseaudio protocols.

pulseaudio support is enabled in qemu-kvm builds and it has the
advantage that it works with both pulseaudio and pipewire audio
servers.

Any specific reasons why you want use jack instead?

(In reply to Gerd Hoffmann from comment #2)
> > Expected results:
> > 
> > the qemu-kvm jack audio backend should be supported because pipewire, the
> > default audio server on rhel 9, supports and relies on it. 
> 
> pipewire supports both jack and pulseaudio protocols.
> 
> pulseaudio support is enabled in qemu-kvm builds and it has the
> advantage that it works with both pulseaudio and pipewire audio
> servers.
> 
> Any specific reasons why you want use jack instead?

I want to use pipewire with the jack protocol.

The following configuration:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  [...]
  <devices>
    <audio id="1" type="jack">
      <input clientName="Windows10VM" connectPorts="HDA Intel PCH" />
      <output clientName="Windows10VM" connectPorts="HDA Intel PCH" />
    </audio>
    <sound model="ich9">
      <alias name="sound0"/>
    </sound>
  </devices>
  <qemu:commandline>
    <qemu:env name="PIPEWIRE_RUNTIME_DIR" value="/srv/windows10vm" />
    <qemu:env name="PIPEWIRE_LATENCY" value="512/48000" />
  </qemu:commandline>
</domain>

Results in:
audio: Unknown audio driver `jack' 

If qemu-kvm is compiled without jack support, users can't use the jack protocol with pipewire.

The VM is used for audio production, therefore Jack is (or used to be) the correct API for the job, as opposed to pa.

> > Any specific reasons why you want use jack instead?

> The VM is used for audio production, therefore Jack is (or used to be) the
> correct API for the job, as opposed to pa.

If you are doing audio production inside the guest it doesn't matter much how
the host handles audio.

If both guest and host are involved you probably get better results when
you let jack inside the guest and jack on the host talk directly to each
other over the network instead of sending your audio data though the qemu
sound emulation.  For starters you are not limited to the sample rates
and audio formats supported by the qemu hda emulation then.

(In reply to Gerd Hoffmann from comment #4)
> If both guest and host are involved you probably get better results when
> you let jack inside the guest and jack on the host talk directly to each
> other over the network instead of sending your audio data though the qemu
> sound emulation.

That is not a feasible solution when the guest does not have the ability to run jack as audio server, such is the case with win10 guests.

Utilizing network streams I believe introduces latency and lossy compression, which is not ideal.

Currently the only workaround I have found is to pass-through the audio device. This however cuts off the host audio, and the same device cannot be passed to multiple guests concurrently.

Allowing multiple guests to send audio data through qemu would be the solution.

> Utilizing network streams I believe introduces latency and lossy
> compression, which is not ideal.

Sound emulation introduces latency too.  It also runs with 16bit samples,
not sure this is what you want have for audio production purposes.

> Currently the only workaround I have found is to pass-through the audio
> device.

That surely is the best option when it comes to quality and latency ...

> This however cuts off the host audio, and the same device cannot be
> passed to multiple guests concurrently.

... but yes, there are drawbacks too.

Currently there is no plan to fix it. Hence closing this as WONTFIX.