Hi,
I do to, except when they fix broken behaviour. More seriously, do you
have other concerns with the mixemu code?
Sure - it adds overhead.
The point of this patchset is to kill the overhead if possible, i.e. try
to pass down the volume the guest asked for all the way down to the
Am 13.03.2012 11:19, schrieb Gerd Hoffmann:
Hi,
I do to, except when they fix broken behaviour. More seriously, do you
have other concerns with the mixemu code?
Sure - it adds overhead.
The point of this patchset is to kill the overhead if possible, i.e. try
to pass down the volume
On 03/13/12 11:33, Kevin Wolf wrote:
Am 13.03.2012 11:19, schrieb Gerd Hoffmann:
Hi,
I do to, except when they fix broken behaviour. More seriously, do you
have other concerns with the mixemu code?
Sure - it adds overhead.
The point of this patchset is to kill the overhead if possible,
On Tue, Mar 13, 2012 at 11:19 AM, Gerd Hoffmann kra...@redhat.com wrote:
I think we should remove the mixemu configure option. It makes code
bitrot. Patch #4 proves that. If you want to keep it because of the
overhead or other reasons I'd suggest to make it a runtime option.
To be fair, the
On Tue, 13 Mar 2012, Marc-Andr? Lureau wrote:
On Tue, Mar 13, 2012 at 11:19 AM, Gerd Hoffmann kra...@redhat.com wrote:
I think we should remove the mixemu configure option. It makes code
bitrot. Patch #4 proves that. If you want to keep it because of the
overhead or other reasons I'd
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
Hello,
This patch series implements client-side audio volume support. This
reduces confusion of guest users when volume control is not effective
(because mixemu is disabled or because client-side is muted and can't be
unmuted by the guest..)
Hello,
This patch series implements client-side audio volume support. This reduces
confusion of guest users when volume control is not effective (because mixemu
is disabled or because client-side is muted and can't be unmuted by the guest..)
Instead, the backend is responsible for applying
Hi Vassili
Thanks for your review!
On Mon, Mar 12, 2012 at 8:44 PM, malc av1...@comtv.ru wrote:
a. Pulse/Spice have per connection volume
Each playback/recorde stream has it's own volume, and that's what we
control. We get the client full range thanks to flat-volume logic
(implemented by
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
Hi Vassili
Thanks for your review!
On Mon, Mar 12, 2012 at 8:44 PM, malc av1...@comtv.ru wrote:
a. Pulse/Spice have per connection volume
Each playback/recorde stream has it's own volume, and that's what we
control. We get the client full
On Mon, Mar 12, 2012 at 9:51 PM, malc av1...@comtv.ru wrote:
b. Other drivers are not affected
I don't see yet how, but I will review other drivers ctl_{in,out}
implementations
You don't see how they can be affected or you don't see how you can
figure that out?
I don't see how they can
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
On Mon, Mar 12, 2012 at 9:51 PM, malc av1...@comtv.ru wrote:
b. Other drivers are not affected
I don't see yet how, but I will review other drivers ctl_{in,out}
implementations
You don't see how they can be affected or you don't see
Hi,
This patch series was sent back in September, and reviewed by
Gerd Hoffmann, who pointed out a few nitpicks in the build
warnings.
cheers
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
12 matches
Mail list logo
