From pgf at foxharp.boston.ma.us  Fri May 12 15:49:41 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Fri, 12 May 2006 17:49:41 -0400
Subject: [nas] native alsa bottom-end
Message-ID: <32765.1147470581@foxharp.boston.ma.us>

has anyone ever looked into writing a native alsa dda layer
for nasd?  

mostly the oss compatibility stuff in alsa makes this
unnecessary, but currently i'm having a very odd problem where i
can play sounds via nasd just fine, but can't control the volume. 
i swear it used to work -- perhaps it broke in some apt-get that
i did.  i dunno.  (this is on a debian "testing" system.)
if i run aumix (an oss mixer) and alsamixer at the same time,
each affects the other.  but if i run a remote mixer, nasd gets
the messages, and perhaps does something with them, but they
seem to have no effect.

anyway, i find myself wishing that an entire layer of complexity
(i.e., alsa's oss emulation) would sort of go away right about
now.  :-)

given the size of the existing hp/sgi/sun/oss modules, it doesn't
seem like an alsalib-based module should be difficult.  in
a first scan, though, i didn't see any doc that documents the api
at that layer.  does such a doc exist?

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 47.5 degrees)


From pgf at foxharp.boston.ma.us  Fri May 12 17:44:18 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Fri, 12 May 2006 19:44:18 -0400
Subject: [nas] native alsa bottom-end 
In-Reply-To: pgf's message of Fri, 12 May 2006 17:49:41 -0400.
             <32765.1147470581@foxharp.boston.ma.us> 
Message-ID: <19032.1147477458@foxharp.boston.ma.us>

i wrote:
 > ... currently i'm having a very odd problem where i
 > can play sounds via nasd just fine, but can't control the volume. 


okay, i've done some stracing, and it looks a lot like nasd isn't
actually _doing_ anything when it gets the command.  i've put strace
output below.  i had debug set to 9, so the output's a little messy.
but i don't see any ioctl calls that represent the "set device 1 gain 50"
operation i did with auctl.  (note:  i currently have the daemon
set to release the device.  it doesn't work either way.)

anyone else seen this type of thing?

paul

select(128, [0 1], NULL, NULL, NULL)    = 1 (in [0])
gettimeofday({1147477219, 708034}, NULL) = 0
accept(0, 0, NULL)                      = 4
getpeername(4, {sa_family=AF_INET, sin_port=htons(4682), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
fcntl64(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
select(128, [0 1 4], NULL, NULL, NULL)  = 1 (in [4])
read(4, "l\0\2\0\2\0\0\0\0\0\34\10", 4092) = 12
writev(4, [{"\1\0\2\0\2\0K\0\1\0\0\0\0\0@\0\377\377?\0\210\23D\254*"..., 308}], 1) = 308
select(128, [0 1 4], NULL, NULL, NULL)  = 1 (in [4])
read(4, "\3\0\r\0\"\0\0\0\0\0\10\0\1\0\0\0\220\254\217\277\310\244"..., 4096) = 56
writev(4, [{"\1\0\2\0\0\0\0\0\355\255\4\10()\7\10\4\0\0\0\0\0\0\0\300"..., 32}], 1) = 32
select(128, [0 1 4], NULL, NULL, NULL)  = 1 (in [4])
read(4, "!\0\1\0", 4096)                = 4
writev(4, [{"\1\0\3\0\0\0\0\0\0\0\0\0()\7\10\4\0\0\0\1\0\0\0\3001\305"..., 32}], 1) = 32
select(128, [0 1 4], NULL, NULL, NULL)  = 1 (in [4])
read(4, "", 4096)                       = 0
close(4)                                = 0
write(2, "serverReset();\n", 15serverReset();
)        = 15
write(2, "setTimer(rate = 0);\n", 20setTimer(rate = 0);
)   = 20
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
rt_sigaction(SIGALRM, {SIG_IGN}, {0x8056390, [ALRM], SA_RESTART}, 8) = 0
ioctl(-1, SNDCTL_DSP_SYNC, 0)           = -1 EBADF (Bad file descriptor)
write(2, "closeDevice: out\n", 17closeDevice: out
)      = 17
write(2, "closeDevice: output device alrea"..., 42closeDevice: output device already closed
) = 42
write(2, "closeDevice: mixer\n", 19closeDevice: mixer
)    = 19
write(2, "closeDevice: mixerdevice already"..., 40closeDevice: mixerdevice already closed
) = 40
write(2, " done.\n", 7 done.
)                 = 7
stat64("/tmp/.sockets/audiolisten", {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
open("/etc/Xlisten.hosts", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
write(2, "AuInitPhysicalDevices();\n", 25AuInitPhysicalDevices();
) = 25
write(2, "Init: will close device when fin"..., 51Init: will close device when finished with stream.
) = 51
write(2, "Init: Leaving the mixer device o"..., 57Init: Leaving the mixer device options alone at startup.
) = 57
rt_sigaction(SIGALRM, {0x8056390, [ALRM], SA_RESTART}, {SIG_IGN}, 8) = 0
write(2, "setTimer(rate = 0);\n", 20setTimer(rate = 0);
)   = 20
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
write(2, "createServerComponents(...);\n", 29createServerComponents(...);
) = 29
select(128, [0 1], NULL, NULL, NULL

=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 46.8 degrees)


From jon at radscan.com  Fri May 12 18:10:06 2006
From: jon at radscan.com (Jon Trulson)
Date: Fri, 12 May 2006 18:10:06 -0600 (MDT)
Subject: [nas] native alsa bottom-end
In-Reply-To: <32765.1147470581@foxharp.boston.ma.us>
References: <32765.1147470581@foxharp.boston.ma.us>
Message-ID: <Pine.LNX.4.61.0605121802010.14960@m5.radscan.com>

On Fri, 12 May 2006, Paul Fox wrote:

> has anyone ever looked into writing a native alsa dda layer
> for nasd?
>
> mostly the oss compatibility stuff in alsa makes this
> unnecessary, but currently i'm having a very odd problem where i
> can play sounds via nasd just fine, but can't control the volume.
> i swear it used to work -- perhaps it broke in some apt-get that
> i did.  i dunno.  (this is on a debian "testing" system.)
> if i run aumix (an oss mixer) and alsamixer at the same time,
> each affects the other.  but if i run a remote mixer, nasd gets
> the messages, and perhaps does something with them, but they
> seem to have no effect.
>

         I am not sure what you mean by a remote mixer... I use xmms
         alot and the alsamixergui app.  I notice that when I adjust
         the volume in xmms, the PCM volume in alsamixer is adjusted,
         as it should be.

         Though note, some of the alsa drivers appears to be fairly
         crappy.  I used the intel_hda driver on my new box for a few
         days before I could no longer stand it's noisy, crappy output.
         I stuck an old SB 128 in the box, and have not looked back :)
         I am using oss emulation with alsa on this setup.

> anyway, i find myself wishing that an entire layer of complexity
> (i.e., alsa's oss emulation) would sort of go away right about
> now.  :-)
>

         Hehe...

> given the size of the existing hp/sgi/sun/oss modules, it doesn't
> seem like an alsalib-based module should be difficult.  in

         I am not familiar with the alsa interface, but I image a
         'basic' stereo driver would not be too difficult (he says
         after his 3rd beer :).  But if someone wanted to do a full
         alsa driver, that could be more complicated as alsa supports
         multiple output devices, input devices, 5.1 sound, etc.  It
         would be nice to have these features supported as well someday
         too.

         I suspect that would involve somewhat more work :)


> a first scan, though, i didn't see any doc that documents the api
> at that layer.  does such a doc exist?
>

         Alas no... When I worked on the HP driver, I used the others
         as a template.

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
"I am Nomad." -Nomad



From jon at radscan.com  Fri May 12 18:12:10 2006
From: jon at radscan.com (Jon Trulson)
Date: Fri, 12 May 2006 18:12:10 -0600 (MDT)
Subject: [nas] native alsa bottom-end 
In-Reply-To: <19032.1147477458@foxharp.boston.ma.us>
References: <19032.1147477458@foxharp.boston.ma.us>
Message-ID: <Pine.LNX.4.61.0605121810550.14960@m5.radscan.com>

On Fri, 12 May 2006, Paul Fox wrote:

> i wrote:
> > ... currently i'm having a very odd problem where i
> > can play sounds via nasd just fine, but can't control the volume.
>
>
> okay, i've done some stracing, and it looks a lot like nasd isn't
> actually _doing_ anything when it gets the command.  i've put strace
> output below.  i had debug set to 9, so the output's a little messy.
> but i don't see any ioctl calls that represent the "set device 1 gain 50"
> operation i did with auctl.  (note:  i currently have the daemon
> set to release the device.  it doesn't work either way.)
>
> anyone else seen this type of thing?
>
> paul
>
> select(128, [0 1], NULL, NULL, NULL)    = 1 (in [0])
> gettimeofday({1147477219, 708034}, NULL) = 0
> accept(0, 0, NULL)                      = 4
> getpeername(4, {sa_family=AF_INET, sin_port=htons(4682), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
> setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> fcntl64(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
> select(128, [0 1 4], NULL, NULL, NULL)  = 1 (in [4])
> read(4, "l\0\2\0\2\0\0\0\0\0\34\10", 4092) = 12
> writev(4, [{"\1\0\2\0\2\0K\0\1\0\0\0\0\0@\0\377\377?\0\210\23D\254*"..., 308}], 1) = 308
> select(128, [0 1 4], NULL, NULL, NULL)  = 1 (in [4])
> read(4, "\3\0\r\0\"\0\0\0\0\0\10\0\1\0\0\0\220\254\217\277\310\244"..., 4096) = 56
> writev(4, [{"\1\0\2\0\0\0\0\0\355\255\4\10()\7\10\4\0\0\0\0\0\0\0\300"..., 32}], 1) = 32
> select(128, [0 1 4], NULL, NULL, NULL)  = 1 (in [4])
> read(4, "!\0\1\0", 4096)                = 4
> writev(4, [{"\1\0\3\0\0\0\0\0\0\0\0\0()\7\10\4\0\0\0\1\0\0\0\3001\305"..., 32}], 1) = 32
> select(128, [0 1 4], NULL, NULL, NULL)  = 1 (in [4])
> read(4, "", 4096)                       = 0
> close(4)                                = 0

   Looks like it saw the proto and promptly ignored it.  Was there an
   active flow at the time?  I believe that is a requirement before the
   device will be opened, if ReleaseDevice is enabled.


-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
"I am Nomad." -Nomad



From auerswal at unix-ag.uni-kl.de  Fri May 12 22:47:51 2006
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Sat, 13 May 2006 06:47:51 +0200
Subject: [nas] native alsa bottom-end
In-Reply-To: <32765.1147470581@foxharp.boston.ma.us>
References: <32765.1147470581@foxharp.boston.ma.us>
Message-ID: <20060513044751.GA12148@sushi.unix-ag.uni-kl.de>

Hi,

On Fri, May 12, 2006 at 05:49:41PM -0400, Paul Fox wrote:
> has anyone ever looked into writing a native alsa dda layer
> for nasd?  

The other way would be nice, too (a plugin for ALSA to output to NAS).
;-)

> mostly the oss compatibility stuff in alsa makes this
> unnecessary, but currently i'm having a very odd problem where i
> can play sounds via nasd just fine, but can't control the volume. 

With a default configuration nasd changes mixer settings only when
playing (or recording). IIRC you can tell nasd to always control the
output device, therefore stopping other programs from using it. This way
you can control the mixer even when not playing/recording. (Disclaimer:
I did not test this...)

You should make sure that you're playing something via NAS when trying
to change the volume. We had the problem that whenever one user was
playing sounds, aupanel did not "work". The solution was that he was
using ALSA for sound output instead of NAS.

Erik


From pgf at foxharp.boston.ma.us  Sat May 13 09:46:47 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Sat, 13 May 2006 11:46:47 -0400
Subject: [nas] native alsa bottom-end 
In-Reply-To: jon's message of Fri, 12 May 2006 18:10:06 -0600.
             <Pine.LNX.4.61.0605121802010.14960@m5.radscan.com> 
Message-ID: <16985.1147535207@foxharp.boston.ma.us>

jon wrote:
 > On Fri, 12 May 2006, Paul Fox wrote:
 > 
 > > unnecessary, but currently i'm having a very odd problem where i
 > > can play sounds via nasd just fine, but can't control the volume.
 > > i swear it used to work -- perhaps it broke in some apt-get that
 > > i did.  i dunno.  (this is on a debian "testing" system.)
 > > if i run aumix (an oss mixer) and alsamixer at the same time,
 > > each affects the other.  but if i run a remote mixer, nasd gets
 > > the messages, and perhaps does something with them, but they
 > > seem to have no effect.
 > >
 > 
 >          I am not sure what you mean by a remote mixer... I use xmms
 >          alot and the alsamixergui app.  I notice that when I adjust
 >          the volume in xmms, the PCM volume in alsamixer is adjusted,
 >          as it should be.

sorry -- i meant, a mixer working via the nas interface.  specifically,
auctl.  i.e. i have three mixers operating on top of alsa drivers:
    alsamixer        (alsa native)
    aumix            (oss compatibility mode on alsa)
    auctl --> nasd   (oss compatibility mode on alsa)

the first two work, the third one doesn't.

 > 
 > > given the size of the existing hp/sgi/sun/oss modules, it doesn't
 > > seem like an alsalib-based module should be difficult.  in
 > 
 >          I am not familiar with the alsa interface, but I image a
 >          'basic' stereo driver would not be too difficult (he says

agreed.

 > > a first scan, though, i didn't see any doc that documents the api
 > > at that layer.  does such a doc exist?
 > >
 > 
 >          Alas no... When I worked on the HP driver, I used the others
 >          as a template.

okay, thanks.

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 45.5 degrees)


From pgf at foxharp.boston.ma.us  Sat May 13 09:50:36 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Sat, 13 May 2006 11:50:36 -0400
Subject: [nas] native alsa bottom-end 
In-Reply-To: jon's message of Fri, 12 May 2006 18:12:10 -0600.
             <Pine.LNX.4.61.0605121810550.14960@m5.radscan.com> 
Message-ID: <17492.1147535436@foxharp.boston.ma.us>

jon wrote:
 > On Fri, 12 May 2006, Paul Fox wrote:
 > 
 > > i wrote:
 > > > ... currently i'm having a very odd problem where i
 > > > can play sounds via nasd just fine, but can't control the volume.
 > >
 > >
 > > okay, i've done some stracing, and it looks a lot like nasd isn't
 > > actually _doing_ anything when it gets the command.  i've put strace

 ...strace output snipped...

 > 
 >    Looks like it saw the proto and promptly ignored it.  Was there an
 >    active flow at the time?  I believe that is a requirement before the
 >    device will be opened, if ReleaseDevice is enabled.

there was no active flow.

but the mixer interface doesn't work whether or not there's a flow,
nor whether or not i have ReleaseDevice enabled.

i should add that this all works fine with an earlier nasd running
on a 2.4 (vs. my current 2.6) kernel and running on native oss
(rather than my current oss-on-alsa emulation, which is version 1.0.11).

stay tuned.  i clearly have some more research to do.  :-)

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 45.3 degrees)


From pgf at foxharp.boston.ma.us  Sat May 13 09:58:15 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Sat, 13 May 2006 11:58:15 -0400
Subject: [nas] native alsa bottom-end 
In-Reply-To: auerswal's message of Sat, 13 May 2006 06:47:51 +0200.
             <20060513044751.GA12148@sushi.unix-ag.uni-kl.de> 
Message-ID: <18647.1147535895@foxharp.boston.ma.us>

erik wrote:
 > On Fri, May 12, 2006 at 05:49:41PM -0400, Paul Fox wrote:
 > > has anyone ever looked into writing a native alsa dda layer
 > > for nasd?  
 > 
 > The other way would be nice, too (a plugin for ALSA to output to NAS).
 > ;-)

hey!  no thread hijacking!  :-)

 > > mostly the oss compatibility stuff in alsa makes this
 > > unnecessary, but currently i'm having a very odd problem where i
 > > can play sounds via nasd just fine, but can't control the volume. 
 > 
 > With a default configuration nasd changes mixer settings only when
 > playing (or recording). 

i really thought you and jon were wrong about this, but i've only
just realized that on my systems, there's almost always a stream
open to nasd, since my home automation system keeps one open all
the time even when it has nothing to say.  this is probably why
the volume control has always worked in the past, even though i thought
there was nothing "playing".

however, as i said in my last message, that's not my current problem.

 > You should make sure that you're playing something via NAS when trying
 > to change the volume. We had the problem that whenever one user was
 > playing sounds, aupanel did not "work". The solution was that he was
 > using ALSA for sound output instead of NAS.

i've been told on the alsa list that alsa 1.0.9 and above has
support for software mixing of different input sources.  however,
i don't think this works if one of the sources you want to mix is
an OSS source, like nasd.  this would be another excellent reason
to have a native alsa bottom end for nasd -- it might work better
with other native alsa programs.

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 45.5 degrees)


From auerswal at unix-ag.uni-kl.de  Sat May 13 11:11:19 2006
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Sat, 13 May 2006 19:11:19 +0200
Subject: [nas] native alsa bottom-end
In-Reply-To: <17492.1147535436@foxharp.boston.ma.us>
References: <Pine.LNX.4.61.0605121810550.14960@m5.radscan.com> <17492.1147535436@foxharp.boston.ma.us>
Message-ID: <20060513171119.GA1509@sushi.unix-ag.uni-kl.de>

Hi,

On Sat, May 13, 2006 at 11:50:36AM -0400, Paul Fox wrote:
> i should add that this all works fine with an earlier nasd running
> on a 2.4 (vs. my current 2.6) kernel and running on native oss
> (rather than my current oss-on-alsa emulation, which is version 1.0.11).

Well, at the Unix AG we have nas running on a debian/unstable system
with kernel 2.6 using oss-on-alsa, and it works like expected.

Erik


From pgf at foxharp.boston.ma.us  Sat May 13 11:13:33 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Sat, 13 May 2006 13:13:33 -0400
Subject: [nas] native alsa bottom-end 
In-Reply-To: auerswal's message of Sat, 13 May 2006 19:11:19 +0200.
             <20060513171119.GA1509@sushi.unix-ag.uni-kl.de> 
Message-ID: <17424.1147540413@foxharp.boston.ma.us>

erik wrote:
 > On Sat, May 13, 2006 at 11:50:36AM -0400, Paul Fox wrote:
 > > i should add that this all works fine with an earlier nasd running
 > > on a 2.4 (vs. my current 2.6) kernel and running on native oss
 > > (rather than my current oss-on-alsa emulation, which is version 1.0.11).
 > 
 > Well, at the Unix AG we have nas running on a debian/unstable system
 > with kernel 2.6 using oss-on-alsa, and it works like expected.

ah, okay.  thanks.  that's a good data point.  :-)

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 43.7 degrees)


From pgf at foxharp.boston.ma.us  Sat May 13 14:38:59 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Sat, 13 May 2006 16:38:59 -0400
Subject: nasd MixerInit	(was Re: [nas] native alsa bottom-end )
In-Reply-To: pgf's message of Fri, 12 May 2006 17:49:41 -0400.
             <32765.1147470581@foxharp.boston.ma.us> 
Message-ID: <19719.1147552739@foxharp.boston.ma.us>

i wrote:
 > ...currently i'm having a very odd problem where i
 > can play sounds via nasd just fine, but can't control the volume. 

i believe i've figured out the problem.  it's this configuration
setting:
    # init the mixer on startup? Voxware only.
    MixerInit	"no"			

not only does this cause the mixer to not be initialized at
startup time, but it disables all mixer "set" operations.

surely this isn't intentional.  is it?  (see the "leave_mixer" boolean
in auvoxware.c)

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 41.0 degrees)


From steve at einval.com  Sat May 13 17:39:39 2006
From: steve at einval.com (Steve McIntyre)
Date: Sun, 14 May 2006 00:39:39 +0100
Subject: nasd MixerInit	(was Re: [nas] native alsa bottom-end )
In-Reply-To: <19719.1147552739@foxharp.boston.ma.us>
References: <32765.1147470581@foxharp.boston.ma.us> <19719.1147552739@foxharp.boston.ma.us>
Message-ID: <20060513233939.GK32158@einval.com>

On Sat, May 13, 2006 at 04:38:59PM -0400, Paul Fox wrote:
>i wrote:
> > ...currently i'm having a very odd problem where i
> > can play sounds via nasd just fine, but can't control the volume. 
>
>i believe i've figured out the problem.  it's this configuration
>setting:
>    # init the mixer on startup? Voxware only.
>    MixerInit	"no"			
>
>not only does this cause the mixer to not be initialized at
>startup time, but it disables all mixer "set" operations.
>
>surely this isn't intentional.  is it?  (see the "leave_mixer" boolean
>in auvoxware.c)

Hmmm, that does sound like a bug, yes! Looks like the check in
setPhysicalOutputGain() is the culprit.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
Who needs computer imagery when you've got Brian Blessed?



From auerswal at unix-ag.uni-kl.de  Sat May 13 23:43:18 2006
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Sun, 14 May 2006 07:43:18 +0200
Subject: nasd MixerInit (was Re: [nas] native alsa bottom-end )
In-Reply-To: <20060513233939.GK32158@einval.com>
References: <32765.1147470581@foxharp.boston.ma.us> <19719.1147552739@foxharp.boston.ma.us> <20060513233939.GK32158@einval.com>
Message-ID: <20060514054318.GA23427@sushi.unix-ag.uni-kl.de>

Hi,

On Sun, May 14, 2006 at 12:39:39AM +0100, Steve McIntyre wrote:
> On Sat, May 13, 2006 at 04:38:59PM -0400, Paul Fox wrote:
> >i believe i've figured out the problem.  it's this configuration
> >setting:
> >    # init the mixer on startup? Voxware only.
> >    MixerInit	"no"			
> >
> >not only does this cause the mixer to not be initialized at
> >startup time, but it disables all mixer "set" operations.
> >
> >surely this isn't intentional.  is it?  (see the "leave_mixer" boolean
> >in auvoxware.c)
> 
> Hmmm, that does sound like a bug, yes! Looks like the check in
> setPhysicalOutputGain() is the culprit.

I can confirm this, line 966 in server/dda/voxware/auvoxware.c should be
deleted.

Erik
-------------- next part --------------
diff -ur nas-1.7b/server/dda/voxware/auvoxware.c nas-1.7b.new/server/dda/voxware/auvoxware.c
--- nas-1.7b/server/dda/voxware/auvoxware.c	2005-06-04 22:08:54.000000000 +0200
+++ nas-1.7b.new/server/dda/voxware/auvoxware.c	2006-05-14 07:38:39.000000000 +0200
@@ -963,7 +963,6 @@
     Letsplay = g;
     gusvolume = g | (g << 8);
     if (mixerfd != -1)
-        if(!leave_mixer)
 	i = ioctl(mixerfd, MIXER_WRITE(SOUND_MIXER_PCM), &gusvolume);
 }

From pgf at foxharp.boston.ma.us  Sun May 14 08:36:06 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Sun, 14 May 2006 10:36:06 -0400
Subject: nasd MixerInit (was Re: [nas] native alsa bottom-end ) 
In-Reply-To: auerswal's message of Sun, 14 May 2006 07:43:18 +0200.
             <20060514054318.GA23427@sushi.unix-ag.uni-kl.de> 
Message-ID: <8690.1147617366@foxharp.boston.ma.us>

 >      if (mixerfd != -1)
 > -        if(!leave_mixer)
 >  	i = ioctl(mixerfd, MIXER_WRITE(SOUND_MIXER_PCM), &gusvolume);
 >  }

what i don't quite understand is how this check lasted so long. 
it's been there since at least 1.4 (which is the oldest source i
have on hand).  i guess most folks let nasd initialize the mixer,
eh?  :-)

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 43.3 degrees)


From auerswal at unix-ag.uni-kl.de  Sun May 14 10:01:13 2006
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Sun, 14 May 2006 18:01:13 +0200
Subject: nasd MixerInit (was Re: [nas] native alsa bottom-end )
In-Reply-To: <8690.1147617366@foxharp.boston.ma.us>
References: <20060514054318.GA23427@sushi.unix-ag.uni-kl.de> <8690.1147617366@foxharp.boston.ma.us>
Message-ID: <20060514160113.GA2751@sushi.unix-ag.uni-kl.de>

Hi,

On Sun, May 14, 2006 at 10:36:06AM -0400, Paul Fox wrote:
>  >      if (mixerfd != -1)
>  > -        if(!leave_mixer)
>  >  	i = ioctl(mixerfd, MIXER_WRITE(SOUND_MIXER_PCM), &gusvolume);
>  >  }
> 
> what i don't quite understand is how this check lasted so long. 
> it's been there since at least 1.4 (which is the oldest source i
> have on hand).  i guess most folks let nasd initialize the mixer,
> eh?  :-)

It's the default configuration, so probably yes.

Erik


From jon at radscan.com  Mon May 15 16:55:21 2006
From: jon at radscan.com (Jon Trulson)
Date: Mon, 15 May 2006 16:55:21 -0600 (MDT)
Subject: nasd MixerInit (was Re: [nas] native alsa bottom-end )
In-Reply-To: <20060514054318.GA23427@sushi.unix-ag.uni-kl.de>
References: <32765.1147470581@foxharp.boston.ma.us> <19719.1147552739@foxharp.boston.ma.us>
 <20060513233939.GK32158@einval.com> <20060514054318.GA23427@sushi.unix-ag.uni-kl.de>
Message-ID: <Pine.LNX.4.61.0605151654590.4558@m5.radscan.com>

On Sun, 14 May 2006, Erik Auerswald wrote:

> Hi,
>
> On Sun, May 14, 2006 at 12:39:39AM +0100, Steve McIntyre wrote:
>> On Sat, May 13, 2006 at 04:38:59PM -0400, Paul Fox wrote:
>>> i believe i've figured out the problem.  it's this configuration
>>> setting:
>>>    # init the mixer on startup? Voxware only.
>>>    MixerInit	"no"
>>>
>>> not only does this cause the mixer to not be initialized at
>>> startup time, but it disables all mixer "set" operations.
>>>
>>> surely this isn't intentional.  is it?  (see the "leave_mixer" boolean
>>> in auvoxware.c)
>>
>> Hmmm, that does sound like a bug, yes! Looks like the check in
>> setPhysicalOutputGain() is the culprit.
>
> I can confirm this, line 966 in server/dda/voxware/auvoxware.c should be
> deleted.
>

         I will have it killed.  Thanks!

> Erik
>

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
"I am Nomad." -Nomad



From pgf at foxharp.boston.ma.us  Mon May 15 18:33:53 2006
From: pgf at foxharp.boston.ma.us (Paul Fox)
Date: Mon, 15 May 2006 20:33:53 -0400
Subject: nasd MixerInit (was Re: [nas] native alsa bottom-end ) 
In-Reply-To: jon's message of Mon, 15 May 2006 16:55:21 -0600.
             <Pine.LNX.4.61.0605151654590.4558@m5.radscan.com> 
Message-ID: <24321.1147739633@foxharp.boston.ma.us>

jon wrote:
 > > I can confirm this, line 966 in server/dda/voxware/auvoxware.c should be
 > > deleted.
 > >
 > 
 >          I will have it killed.  Thanks!

and thanks once again for your stewardship role, jon.

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 44.8 degrees)


From jon at radscan.com  Mon May 15 18:45:41 2006
From: jon at radscan.com (Jon Trulson)
Date: Mon, 15 May 2006 18:45:41 -0600 (MDT)
Subject: nasd MixerInit (was Re: [nas] native alsa bottom-end ) 
In-Reply-To: <24321.1147739633@foxharp.boston.ma.us>
References: <24321.1147739633@foxharp.boston.ma.us>
Message-ID: <Pine.LNX.4.61.0605151841120.5216@m5.radscan.com>

On Mon, 15 May 2006, Paul Fox wrote:

> jon wrote:
> > > I can confirm this, line 966 in server/dda/voxware/auvoxware.c should be
> > > deleted.
> > >
> >
> >          I will have it killed.  Thanks!
>
> and thanks once again for your stewardship role, jon.
>

         My pleasure. :)

         I will put together a (short lived I hope) 1.7d devel release
         with this fix RSN.

         Since 1.7c downloads exceed 1.7 (stable) downloads by a factor
         of about 6 to 1 now, it's way past time for a new stable
         release, which I'd like to do in about 2 weeks.  So if there
         are any patches out there, just yearning to be included...

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
"I am Nomad." -Nomad



From auerswal at unix-ag.uni-kl.de  Tue May 16 00:55:42 2006
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Tue, 16 May 2006 08:55:42 +0200
Subject: nasd MixerInit (was Re: [nas] native alsa bottom-end )
In-Reply-To: <Pine.LNX.4.61.0605151841120.5216@m5.radscan.com>
References: <24321.1147739633@foxharp.boston.ma.us> <Pine.LNX.4.61.0605151841120.5216@m5.radscan.com>
Message-ID: <20060516065542.GA28142@sushi.unix-ag.uni-kl.de>

Hi Jon,

On Mon, May 15, 2006 at 06:45:41PM -0600, Jon Trulson wrote:
>         I will put together a (short lived I hope) 1.7d devel release
>         with this fix RSN.
> 
>         Since 1.7c downloads exceed 1.7 (stable) downloads by a factor
>         of about 6 to 1 now, it's way past time for a new stable
>         release, which I'd like to do in about 2 weeks.  So if there
>         are any patches out there, just yearning to be included...

Where can I find version 1.7c (and the upcoming 1.7d)? Google and
freshmeat point to http://radscan.com/nas.html resp. the mirror at
http://nas.codebrilliance.com/ where only versions up to 1.7b can be
found.

Erik


From jon at radscan.com  Tue May 16 09:41:17 2006
From: jon at radscan.com (Jon Trulson)
Date: Tue, 16 May 2006 09:41:17 -0600 (MDT)
Subject: nasd MixerInit (was Re: [nas] native alsa bottom-end )
In-Reply-To: <20060516065542.GA28142@sushi.unix-ag.uni-kl.de>
References: <24321.1147739633@foxharp.boston.ma.us>
 <Pine.LNX.4.61.0605151841120.5216@m5.radscan.com> <20060516065542.GA28142@sushi.unix-ag.uni-kl.de>
Message-ID: <Pine.LNX.4.61.0605160940450.9352@m5.radscan.com>

On Tue, 16 May 2006, Erik Auerswald wrote:

> Hi Jon,
>
> On Mon, May 15, 2006 at 06:45:41PM -0600, Jon Trulson wrote:
>>         I will put together a (short lived I hope) 1.7d devel release
>>         with this fix RSN.
>>
>>         Since 1.7c downloads exceed 1.7 (stable) downloads by a factor
>>         of about 6 to 1 now, it's way past time for a new stable
>>         release, which I'd like to do in about 2 weeks.  So if there
>>         are any patches out there, just yearning to be included...
>
> Where can I find version 1.7c (and the upcoming 1.7d)? Google and
> freshmeat point to http://radscan.com/nas.html resp. the mirror at
> http://nas.codebrilliance.com/ where only versions up to 1.7b can be
> found.
>

         Sorry, my mistake.  1.7b is the latest devel version.  So the
         next one will be 1.7c.

> Erik
>

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
"I am Nomad." -Nomad



From jon at radscan.com  Tue May 16 19:21:33 2006
From: jon at radscan.com (Jon Trulson)
Date: Tue, 16 May 2006 19:21:33 -0600 (MDT)
Subject: [nas] NAS 1.7c (devel) is now available
Message-ID: <Pine.LNX.4.61.0605161919040.18036@m5.radscan.com>


         .. at the usual place ( http://radscan.com/nas.html )

         This should probably become a stable 1.8 in a couple weeks
         unless something bad has happened, or more patches come
         through.

         Here's the relevant HISTORY entry:


Version 1.7c (devel) 05/16/2006

          - time for another stable release.

          - Correct problem in auvoxware, where if MixerInit is set to
            false, remote volume (mixer) requests are ignored.
            Reported by Paul Fox, with a fix determined by Steve
            McIntyre and Erik Auerswald.

          - Applied patch from Nicolas Escuder correcting a Cygwin
            issue in auvoxware.c

          - applied patch from Erik Auerswald adding a Mute button and
            functionality to aupanel.

          - applied patch from Nicolas Franois  (via Steve McIntyre)
            correcting some typos in the AuSetBucketAttributes and
            AuSoundCreateFileFromBucket man pages.


-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
"I am Nomad." -Nomad



