diff options
Diffstat (limited to 'results/classifier/118/none/1908832')
| -rw-r--r-- | results/classifier/118/none/1908832 | 284 |
1 files changed, 284 insertions, 0 deletions
diff --git a/results/classifier/118/none/1908832 b/results/classifier/118/none/1908832 new file mode 100644 index 000000000..412b1d1e0 --- /dev/null +++ b/results/classifier/118/none/1908832 @@ -0,0 +1,284 @@ +permissions: 0.567 +user-level: 0.562 +register: 0.533 +virtual: 0.531 +hypervisor: 0.520 +PID: 0.494 +KVM: 0.490 +TCG: 0.463 +semantic: 0.442 +ppc: 0.431 +assembly: 0.427 +risc-v: 0.422 +vnc: 0.409 +debug: 0.402 +device: 0.396 +peripherals: 0.386 +architecture: 0.370 +mistranslation: 0.366 +x86: 0.359 +graphic: 0.358 +network: 0.323 +performance: 0.321 +files: 0.293 +boot: 0.293 +kernel: 0.292 +arm: 0.288 +VMM: 0.284 +i386: 0.243 +socket: 0.184 + +jack audio dev produces no sound + +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é + +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. + +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é. + +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é. + +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. + +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. + +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 + +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. + +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. + + +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. + +Ticket has been moved here (thanks, José!): +https://gitlab.com/qemu-project/qemu/-/issues/278 +... thus closing this on Launchpad now. + |