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

Reply via email to