Re: aucat's volume-sharing algorithm

[Alexandre Ratchov]

On Fri, Apr 24, 2009 at 11:29:02AM -0400, Nick Guenther wrote:
> I'm playing with the new aucat. Or rather, running it, since unlike
> every other soundserver it doesn't require endless tweaking to just
> work. There is one issue I'm having, and I'm not sure if it's on
> purpose or not. Whenever (say) pidgin (or anything else) plays sound
> my music dims in volume. It makes sense the clients have to be turned
> down so two playing at 100% don't blow the speakers, but the trouble
> is the dip in sound is -really obvious-.
> 
> I found
>  -v volume
>  Software volume attenuation of the playback stream.  The value
>  must be between 1 and 127, corresponding to -42dB and -0dB atten-
>  uation.  In server mode, clients inherit this parameter.  Reduc-
>  ing the volume in advance reduces a client's dynamic range, but
>  allows client volume to stay independent from the number of
>  clients as long as their number is small enough.  A good compro-
>  mise is to use -4dB attenuation (12 volume units) for each addi-
>  tional client expected (115 if 2 clients are expected, 103 for 3
>  clients, and so on).
> which I interpret as saying that if I run aucat as "aucat -l -v 50" it
> should predim the volume of any client that connects so that the dip
> doesn't happen. If I'm right about that (which I'm not at all sure
> that I am) then aucat is behaving badly because I even tried giving
> "-v 1" and heard no change at all.
> 

currently the -v options applies to audio streams, ie to
files or sockets, example:

aucat -l -v 91 -s default

if no -s options are used, a default socket is created with
the default parameters (max volume and so on), that should
be change imo.

> 
> -Nick
> 
> p.s. I know the manpage suggests sharing the sound device is a bad
> plan but I just have a simple home system and I'd like to know if
> aucat gives me the freedom to run multiple users against it (I could
> come up with lots of justifications, like letting the daemons we
> summon speak, but really it's just curiousity). It seems like all it
> would take is redirecting libsndio to point at the right socket, but
> because the socket is in /tmp/aucat-$USER_ID/ I don't see how this is
> possible. Can libsndio be told what socket to use?

i've the same problem here, but there's no way to have
shared sockets yet. Mainly because this causes integration
issues. Hopefully that will be fixed one day.

-- Alexandre

aucat's volume-sharing algorithm

[Nick Guenther]

I'm playing with the new aucat. Or rather, running it, since unlike
every other soundserver it doesn't require endless tweaking to just
work. There is one issue I'm having, and I'm not sure if it's on
purpose or not. Whenever (say) pidgin (or anything else) plays sound
my music dims in volume. It makes sense the clients have to be turned
down so two playing at 100% don't blow the speakers, but the trouble
is the dip in sound is -really obvious-.

I found
 -v volume
 Software volume attenuation of the playback stream.  The value
 must be between 1 and 127, corresponding to -42dB and -0dB atten-
 uation.  In server mode, clients inherit this parameter.  Reduc-
 ing the volume in advance reduces a client's dynamic range, but
 allows client volume to stay independent from the number of
 clients as long as their number is small enough.  A good compro-
 mise is to use -4dB attenuation (12 volume units) for each addi-
 tional client expected (115 if 2 clients are expected, 103 for 3
 clients, and so on).
which I interpret as saying that if I run aucat as "aucat -l -v 50" it
should predim the volume of any client that connects so that the dip
doesn't happen. If I'm right about that (which I'm not at all sure
that I am) then aucat is behaving badly because I even tried giving
"-v 1" and heard no change at all.


OpenBSD 4.5-current (GENERIC.MP) #80: Mon Apr 20 12:59:56 MDT 2009
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 CPU U7600 @ 1.20GHz ("GenuineIntel" 686-class) 1.20 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR
real mem  = 1064202240 (1014MB)
avail mem = 1020690432 (973MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/30/07, BIOS32 rev. 0 @
0xfcb25, SMBIOS rev. 2.4 @ 0xec000 (40 entries)
bios0: vendor TOSHIBA version "Version 1.50" date 10/30/2007
bios0: TOSHIBA PORTEGE R500
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP SSDT APIC MCFG HPET TCPA SLIC SSDT SSDT
acpi0: wakeup devices USB1(S3) USB3(S3) USB4(S3) EHCI(S3) GLAN(S4)
WLAN(S4) LID_(S4) PWRB(S4) HS87(S4) HS86(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 CPU U7600 @ 1.20GHz ("GenuineIntel" 686-class) 1.20 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (PCIB)
acpiprt2 at acpi0: bus 1 (PEX1)
acpiprt3 at acpi0: bus 2 (MPEX)
acpitz0 at acpi0: critical temperature 102 degC
acpicpu0 at acpi0
acpicpu1 at acpi0
acpibtn0 at acpi0: LID_
acpibat0 at acpi0: BAT1 model "G71C00086210" serial 000796 type
Li-ION   oem "0"
acpibtn1 at acpi0: PWRB
acpiac0 at acpi0: AC unit offline
acpidock at acpi0 not configured
acpivideo at acpi0 not configured
bios0: ROM list: 0xc/0x1 0xe/0x1!
cpu0: unknown Enhanced SpeedStep CPU, msr 0x060b090e0600090e
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 1200 MHz (924 mV): speeds: 1200, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
extent `pciio' (0x0 - 0x), flags=0
 0xaf10 - 0xaf1f
 0xaf24 - 0xaf2f
 0xaf34 - 0xaf9f
 0xafe0 - 0xbfff
 0xcff8 - 0xcfff
extent `pcimem' (0x0 - 0x), flags=0
 0x0 - 0x9
 0xe - 0x3fff
 0xe000 - 0xefff
 0xfec0 - 0xfec17fff
 0xfec2 - 0xfec27fff
 0xfed0 - 0xfed003ff
 0xfed14000 - 0xfed19fff
 0xfed1c000 - 0xfed8
 0xfeda - 0xfedb
 0xfee0 - 0xfee00fff
 0xff60 - 0xff8f
 0xff98 - 0xffbf
 0xffc3b800 - 0x
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
vga1 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1: apic 1 int 16 (irq 10)
drm0 at inteldrm0
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02:
apic 1 int 22 (irq 11)
azalia0: codecs: Realtek ALC262
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02
pci1 at ppb0 bus 1
extent `ppb0 pciio' (0x0 - 0x), flags=0
 0x0 - 0xafff
 0xbfe0 - 0x
extent `ppb0 pcimem' (0x0 - 0x), flags=0
 0x0 - 0xff7ff

Re: aucat's volume-sharing algorithm

[Thomas Pfaff]

On Fri, 24 Apr 2009 11:29:02 -0400
Nick Guenther  wrote:
> I'm playing with the new aucat. Or rather, running it, since unlike
> every other soundserver it doesn't require endless tweaking to just
> work. There is one issue I'm having, and I'm not sure if it's on
> purpose or not. Whenever (say) pidgin (or anything else) plays sound
> my music dims in volume. It makes sense the clients have to be turned
> down so two playing at 100% don't blow the speakers, but the trouble
> is the dip in sound is -really obvious-.

I also think the current "algorithm" is too aggressive; the output
volume is calculated by dividing the maximum volume by the number of
streams (or clients).  While this does guarantee that there will be
no clipping, it means the change in volume is indeed very audible.

Excerpts from /usr/src/usr.bin/aucat/aproc.c:

  n = 0;
  LIST_FOREACH(buf, &p->ibuflist, ient) {
  n++;
  }
  LIST_FOREACH(buf, &p->ibuflist, ient) {
  weight = ADATA_UNIT / n;
  [...]
  buf->mixeight = weight;
  }

Mixing two (or more) streams is not likely to cause any clipping
(sample value out of range) as most samples are not exactly at
peak values all the time.  I don't have a better solution, but I
think something should be done about the current approach; it
just doesn't sound right to me.

I wonder what the other sound daemons do ...