jack audio dev produces no sound

[José Pekkarinen]

Hi,

I'm testing the new jack audiodev backend in my
laptop. The host system is gentoo, using the
ebuild for qemu 5.1.0-r2, and I'm using jack
use flag globally in the system so any ebuild
that have support for jack should be build with
it. The jack setup reportedly works as I use it
with firefox, and mumble with no trouble. When
I launch the following script, I see the vm
connects to jack:

/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 -vga virtio -display gtk,gl=on \
        -cpu host -smp 2,cores=2,threads=1 \
        -m 4G -L /usr/share/qemu \
        -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \
        -drive file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
        -drive file=debian_VARS.fd,if=pflash,format=raw,unit=1 \
        -audiodev id=jack,driver=jack -device ich9-intel-hda -device hda-duplex,audiodev=jack \
        -device virtio-serial-pci \
        -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \
        -chardev spicevmc,id=spicechannel0,name=vdagent \
        -device nec-usb-xhci,id=usb \
        -device usb-host,vendorid=0x04ca,productid=0x708e \
        -device usb-host,vendorid=0x1050,productid=0x0407 \
        -chardev spicevmc,name=usbredir,id=usbredirchardev1 \
        -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 \
        -chardev spicevmc,name=usbredir,id=usbredirchardev2 \
        -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 \
        -chardev spicevmc,name=usbredir,id=usbredirchardev3 \
        -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 \
        -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \
        -drive file=debian.qcow2,cache=none,aio=io_uring,if=virtio

Output of vm initialization:

jack: JACK output configured for 48000Hz (1024 samples)
jack: JACK input configured for 48000Hz (1024 samples)
gl_version 46 - core profile enabled
GLSL feature level 430

Though executing any application that uses sound,
for instance, any youtube video through browser,
I listen nothing. By executing pkill jackd, and
launching the same script replacing the audiodev
line for the following:

        -audiodev id=alsa,driver=alsa -device ich9-intel-hda -device hda-duplex,audiodev=alsa \

The audio works, and I can listen to music, or
any other kind of application, though I cannot
listen anything else in the host.

The guest is a simple debian testing(bullseye)
system with plasma desktop, using pulseaudio,
nothing fancy.

Thanks!

José

[Christian Schoenebeck (schoenebeck)]

Does this patch make a difference for you?
https://github.com/qemu/qemu/commit/a6e037390dd91276f4a631d41188c87e8a60bb3f

If not, what's the precise JACK version you are using.

[José Pekkarinen (koalinux)]

I'm afraid it didn't. Jack version is:

* media-sound/jack2
      Latest version available: 1.9.16
      Latest version installed: 1.9.16
      Size of files: 952 KiB
      Homepage: https://jackaudio.org/
      Description: Jackdmp jack implemention for multi-processor machine
      License: GPL-2

qemu config used in build:

../configure --prefix=/usr --sysconfdir=/etc --bindir=/usr/bin --libdir=/usr/lib64 --datadir=/usr/share --docdir=/usr/share/doc/qemu-5.1.0-r2/html --mandir=/usr/share/man --with-confsuffix=/qemu --localstatedir=/var --disable-bsd-user --disable-containers --disable-guest-agent --disable-strip --disable-tcg-interpreter --disable-werror --disable-gcrypt --python=/usr/bin/python3.8 --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --host-cc=x86_64-pc-linux-gnu-gcc --disable-debug-info --disable-debug-tcg --disable-docs --disable-plugins --enable-attr --disable-brlapi --enable-linux-aio --enable-bzip2 --disable-capstone --enable-cap-ng --enable-curl --enable-fdt --disable-glusterfs --disable-gnutls --disable-nettle --enable-gtk --disable-rdma --disable-libiscsi --enable-linux-io-uring --disable-jemalloc --enable-vnc-jpeg --enable-kvm --disable-lzo --disable-mpath --enable-curses --disable-libnfs --disable-numa --enable-opengl --enable-vnc-png --disable-rbd --disable-vnc-sasl --enable-sdl --disable-sdl-image --enable-seccomp --enable-slirp=system --disable-smartcard --disable-snappy --enable-spice --disable-libssh --enable-libusb --enable-usb-redir --disable-vde --enable-vhost-net --disable-vhost-user-fs --enable-virglrenderer --disable-virtfs --enable-vnc --disable-vte --disable-xen --disable-xen-pci-passthrough --disable-xfsctl --enable-xkbcommon --disable-zstd --enable-libxml2 --audio-drv-list=jack,sdl,alsa,oss, --disable-linux-user --enable-system --disable-tools --target-list=aarch64-softmmu,arm-softmmu,riscv32-softmmu,riscv64-softmmu,x86_64-softmmu --enable-pie

thanks!

José.

[José Pekkarinen (koalinux)]

I unmasked qemu-5.2.0-r1, well, actually any newer qemu coming
from gentoo, and rebuild the software. The situation is still
reproducible, which confirms what I tested yesterday with the
patch. I also cleaned up the launch script to remove several
spice related unneeded since I use the gtk display, here is
how it looks like right now:

/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 -vga virtio -display gtk,gl=on \
        -cpu host -smp 4,cores=4,threads=1 \
        -m 2G -L /usr/share/qemu \
        -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \
        -drive file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
        -drive file=debian_VARS.fd,if=pflash,format=raw,unit=1 \
        -audiodev id=jack,driver=jack -device ich9-intel-hda -device hda-duplex,audiodev=jack \
        -device nec-usb-xhci,id=usb \
        -device usb-host,vendorid=0x04ca,productid=0x708e \
        -device usb-host,vendorid=0x1050,productid=0x0407 \
        -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \
        -drive file=debian.qcow2,cache=none,aio=io_uring,if=virtio

Thanks!

José.

[José Pekkarinen (koalinux)]

Hi,

I spend some time debugging this during the morning, I found that there is a check
while connecting the ports that always exits the function without connecting the
jack ports, simplifying it as in the following diff lets me build and use the
audio outputs correctly in the vm:

diff --git a/audio/jackaudio.c b/audio/jackaudio.c
index 3b7c18443d..f417e4db8a 100644
--- a/audio/jackaudio.c
+++ b/audio/jackaudio.c
@@ -369,7 +369,7 @@ static size_t qjack_read(HWVoiceIn *hw, void *buf, size_t len)

 static void qjack_client_connect_ports(QJackClient *c)
 {
- if (!c->connect_ports || !c->opt->connect_ports) {
+ if (!c->connect_ports) {
         return;
     }

So, I wonder, what is this c->opt->connect_ports all about, is it needed, or just
wrongly initialized so that it caps the port connection?

Thanks!

Jose.

[José Pekkarinen (koalinux)]

just for completeness, this is how the output of the vm launch
looks like after the change:

jack: connect out-(null):output 0 -> system:playback_1
jack: connect out-(null):output 1 -> system:playback_2
jack: JACK output configured for 48000Hz (1024 samples)
jack: connect system:capture_1 -> in-(null):input 0
jack: connect system:capture_2 -> in-(null):input 1
jack: JACK input configured for 48000Hz (1024 samples)
gl_version 46 - core profile enabled
GLSL feature level 430

And both input and output works as expected.

Best regards.

Jose.

[Christian Schoenebeck (schoenebeck)]

c->opt->connect_ports is an optional user supplied configuration argument which allows the user to specify a regular expression pattern which is used by QEMU's JACK audio driver to automatically connect its JACK ports to. From qapi/audio.json:

##
# @AudiodevJackPerDirectionOptions:
#
# Options of the JACK backend that are used for both playback and
# recording.
#
# @server-name: select from among several possible concurrent server instances
# (default: environment variable $JACK_DEFAULT_SERVER if set, else "default")
#
# @client-name: the client name to use. The server will modify this name to
# create a unique variant, if needed unless @exact-name is true (default: the
# guest's name)
#
# @connect-ports: if set, a regular expression of JACK client port name(s) to
# monitor for and automatically connect to
#
# @start-server: start a jack server process if one is not already present
# (default: false)
#
# @exact-name: use the exact name requested otherwise JACK automatically
# generates a unique one, if needed (default: false)
#
# Since: 5.1
##
{ 'struct': 'AudiodevJackPerDirectionOptions',
  'base': 'AudiodevPerDirectionOptions',
  'data': {
    '*server-name': 'str',
    '*client-name': 'str',
    '*connect-ports': 'str',
    '*start-server': 'bool',
    '*exact-name': 'bool' } }

I agree with you that it would be more user friendly to auto connect QEMU's output ports to system:playback_1, system:playback_2 and QEMU's input ports to system:capture_1, system:capture_2 respectively if the user did not specify any argument for "connect-ports".

However I think your patch is a bit too simple, i.e. it is more or less luck that the system ports end up as the first two members in the lookup array "ports". It is working right now, but there is no guarantee about the order of the ports returned by jack_get_ports():

https://jackaudio.org/api/group__PortSearching.html

So I would suggest changing your patch a bit by passing a lookup pattern like "system:playback_.*" to jack_get_ports() for QEMU output ports and a pattern like "system:capture_.*" for QEMU input ports, if c->opt->connect_ports is empty that is.

Would you try to send a patch like this? And if yes, would you mind sending your patch directly to the qemu-devel mailing list? That would allow us to merge your patch more efficiently & quickly.

https://wiki.qemu.org/Contribute/SubmitAPatch

[José Pekkarinen (koalinux)]

Yes, I agree, the patch itself is a quick fix, indeed, if I look to
the graphs in QJackCtl, I would expect to see new bubbles from qemu
connected to the system ports, as it happens when I connect Firefox
or Falkon through alsa -> jack plugin, as per the output you can
see it's using some sort of null sink already populated.

About the patch, yes no problem I'll modify it and submit.

Thanks!

Jose.

[Thomas Huth (th-huth)]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

    https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.

[Christian Schoenebeck (schoenebeck)]

Just for the records: the proposed patch was discussed on the QEMU mailing list, but there was no final consensus (yet) to accept the patch. Full discussion:

https://<email address hidden>/msg785555.html

It's probably Ok to let this report expire for now. If there are more users complaining about the current design of expecting the user to connect QEMU's JACK ports, then we can still go ahead with the patch.

[Thomas Huth (th-huth)]

Ticket has been moved here (thanks, José!):
https://gitlab.com/qemu-project/qemu/-/issues/278
... thus closing this on Launchpad now.