From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6POK-0001Jx-Au for qemu-devel@nongnu.org; Wed, 21 Sep 2011 12:11:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6POE-0004kk-Ge for qemu-devel@nongnu.org; Wed, 21 Sep 2011 12:11:20 -0400 Received: from mail-ew0-f53.google.com ([209.85.215.53]:62892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6POE-0004kJ-AW for qemu-devel@nongnu.org; Wed, 21 Sep 2011 12:11:14 -0400 Received: by ewy25 with SMTP id 25so381765ewy.12 for ; Wed, 21 Sep 2011 09:11:12 -0700 (PDT) From: "=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?=" Date: Wed, 21 Sep 2011 18:10:57 +0200 Message-Id: <1316621468-32171-1-git-send-email-marcandre.lureau@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] [PATCH 00/11] RFC: apply volume on client stream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Hi, The qemu volume control experience could be improved. Without mixemu, the volume control has no effect. A volume applet will just feel broken (except in some cases where software volume is applied on guest side, with HDA/Windows7 for example). And a few other problems: - the guest should have a full-range hw volume control over actual audio device. See https://bugzilla.redhat.com/show_bug.cgi?id=482089 - one volume should rule them all (no need to control guest, stream and client volumes separately) - the client volume should be set to match the guest on connection, ex: volume and mute should be restored - backend should hopefully be better at applying volume effect (PulseAudio rely on HW as much as possible, and then optimized routines) - ideally, we would sync both ways guest <-> client, that would probably require guest agent helper to be notified on update The flat-volume logic of PulseAudio (and Windows) ensures a stream get a full-range volume control. Thus, the "guest volume" can rely on its "client stream volume" to have control over the full volume range. I propose an audio backend claiming VOICE_VOLUME_CAP should handle VOICE_VOLUME messages and apply the volume/mute received. In this case mixeng_clear / mixeng_volume aren't applied. I modified the PA backend as a proof of concept (I had to drop the pa_simple API, as I can't see how to modify a stream volume otherwise). Spice and spice-gtk client have already been supporting volume control for a while, but qemu part is the missing bit. Marc-André Lureau (11): audio: add VOICE_VOLUME ctl audio: don't apply volume effect if backend has VOICE_VOLUME_CAP audio: use a nominal volume of 1^32-1 hw/ac97: remove USE_MIXER code hw/ac97: the volume mask was not always 0x1f hw/ac97: new support for volume control audio/spice: add support for volume control RFC: use full PulseAudio API, largely adapted from pa_simple* RFC: configure: pa_simple is not needed anymore RFC: allow controlling volume with PulseAudio backend RFC: make mixemu mandatory audio/audio.c | 25 +++- audio/audio_int.h | 6 + audio/audio_template.h | 2 + audio/mixeng.c | 6 - audio/paaudio.c | 452 +++++++++++++++++++++++++++++++++++++++++++----- audio/spiceaudio.c | 43 +++++ configure | 14 +-- hw/ac97.c | 141 ++++++---------- hw/hda-audio.c | 4 - 9 files changed, 533 insertions(+), 160 deletions(-) -- 1.7.6.2