adduser(8) - adduser.conf quotations
Hopefully one day adduser(8), will have "use warnings;" added to it.
However, when that glorious does come, any existing adduser.conf files
created by adduser(8) will generate warnings because the template
adduser(8) uses to create adduser.conf has some unquoted strings.
This diff allows any future adduser.conf files to NOT create warnings,
if/when "use warnings;" is added.
ok?
-mark
Index: adduser.perl
===
RCS file: /cvs/src/usr.sbin/adduser/adduser.perl,v
retrieving revision 1.55
diff -u -p -r1.55 adduser.perl
--- adduser.perl12 May 2011 05:13:42 - 1.55
+++ adduser.perl12 May 2011 05:20:08 -
@@ -1580,6 +1580,7 @@ sub config_write {
# Note: adduser reads *and* writes this file.
# You may change values, but don't add new things before the
# line ``$do_not_delete''
+# Also, unquoted strings may cause warnings.
#
# verbose = [0-2]
@@ -1587,7 +1588,7 @@ verbose = $verbose
# Get new password for new users
# defaultpasswd = yes | no
-defaultpasswd = $defaultpasswd
+defaultpasswd = "$defaultpasswd"
# Default encryption method for user passwords
# Methods are all those listed in login.conf(5)
@@ -1623,14 +1624,14 @@ shellpref = ($shpref)
defaultshell = "$defaultshell"
# defaultgroup ('USER' for same as username or any other valid group)
-defaultgroup = $defaultgroup
+defaultgroup = "$defaultgroup"
# new users get this uid
uid_start = $uid_start
uid_end = $uid_end
# default login.conf(5) login class
-defaultclass = $defaultclass
+defaultclass = "$defaultclass"
# login classes available from login.conf(5)
# login_classes = ('default', 'daemon', 'staff')
[patch] stop changing files on rebuild
The files below change with every build because they include the `date`
they were generated (and etcsum changes because it references some of the
files that keep changing).
/etc/mail/localhost.cf
/etc/mail/sendmail.cf
/etc/mail/submit.cf
/usr/share/info/dir
/var/db/sysmerge/etcsum
The patch below removes the `date` so all of the above will stay constant
after a rebuild unless there are real changes.
Index: gnu/usr.bin/texinfo/util/gen-dir-node
===
RCS file: /usr/cvs/src/gnu/usr.bin/texinfo/util/gen-dir-node,v
retrieving revision 1.5
diff -u -r1.5 gen-dir-node
--- gnu/usr.bin/texinfo/util/gen-dir-node 17 Jul 2006 16:12:36 -
1.5
+++ gnu/usr.bin/texinfo/util/gen-dir-node 12 May 2011 02:09:26 -
@@ -47,7 +47,6 @@
### output the dir header
echo "-*- Text -*-"
echo "This file was generated automatically by $0."
-echo "This version was generated on `date`"
echo "by `whoami`@`hostname` for `(cd ${INFODIR}; pwd)`"
cat << moobler
Index: gnu/usr.sbin/sendmail/cf/sh/makeinfo.sh
===
RCS file: /usr/cvs/src/gnu/usr.sbin/sendmail/cf/sh/makeinfo.sh,v
retrieving revision 1.2
diff -u -r1.2 makeinfo.sh
--- gnu/usr.sbin/sendmail/cf/sh/makeinfo.sh 15 Jan 2001 21:08:59 -
1.2
+++ gnu/usr.sbin/sendmail/cf/sh/makeinfo.sh 12 May 2011 02:41:33 -
@@ -52,7 +52,7 @@
else
host=`uname -n`
fi
-echo '#' built by $user@$host on `date`
+echo '#' built by $user@$host
echo '#' in `pwd` | sed 's/\/tmp_mnt//'
echo '#' using $1 as configuration include directory | sed 's/\/tmp_mnt//'
echo "define(\`__HOST__', $host)dnl"
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Thu, May 12, 2011 at 12:37:15AM +0300, Sviatoslav Chagaev wrote: > > My impression is that the opposite is true on tech@: if you don't have > a diff -- it's just empty, useless talk and you shouldn't post if you > don't have a diff. > Besides, looking from an ordinary Joe User viewpoint, I don't think > there is anything that could convince me that aucat is presently > appropriatly handling the task of being a system sound server. > (Alexandre already gave me enough information about why things are > the way they are; I don't see any problem in making everyone > happy, the Joe Users who want the sound system to "just work" and > advanced audio-philes who require advanced features and precision > control) > > I have to disagree, there are not very many Joe Users using OpenBSD. I am thrilled about the new sound system. It does "Just Work", as long as you bother to read the Man pages, FAQ's and even ask questions. When I started using OpenBSD, I found even getting sound to play on certain DVD's a real challenge. Now, no problem. When I found I had special problems with a crappy Soundblaster card, I asked questions and found out about experimental work, which I used to fix my sound problem. -v is now standard. Have good ideas? Great. But don't tell me to be a Joe User. I hate Joe Users. They can go away. Chris Bennett
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 09:40:16 +0200 Alexandre Ratchov wrote: > On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote: > > I'm sitting at work, listening to music, debugging a web-application > > with JavaScript alert()s. Each time an alert window pops up, the > > browser plays a sound. For a brief moment, the volume drops twicefold > > then goes back to normal. This is annoying and doesn't make sense. > > I agree, this is annoying. > > > In real life, if you are surrounded by multiple sound sources, their > > sound volumes will not be divided by the total amount of sound sources. > > Their sounds will add up until they blur and you can't distinguish > > anything anymore. Other operating systems, such as Macrohard Doors, do > > mixing by modeling this real world behaviour. > > my physics lessons say that pressure is additive, so the resulting > pressure of two sources close to each other is the sum of their > respective pressures. And there's no clipping in nature, so no need to > test against any MIN and MAX value. > > A simple addition is what our ears expect. True, with a note that I test for MIN MAX because without it, the variable overfills, resulting in terrible distortions as soons as two files are playing simultaneously and are loud enough. > > On the other hand DACs operate on a limited dynamic range, so there's > a MIN and a MAX value. This is not how physics laws are, there's not > MIN and MAX values for pressure. > > So keeping full dynamic range of the DAC and doing the physics > correctly at the same time is simply mathematically impossible. Yes, the computer is limited and can only model real world to some degree. > > What options do we have? > > (1) prescale streams => loose few dBs of dynamic range > (2) clipping => is not natural except if there's no clipping > (3) using (x + y - x * y) => distortion, similar to (2) > (4) do (1) but with DACs with larger dynamic range => ok > (5) ... > Hm, perhaps some sort of a hybrid approach could be employed (for the -l, aka system sound server functionality). > The choice behind aucat is to never add distortion, clipping or > whatever. So (1) and (4) are the only options afaics > > > In this sense, aucat violates the principle of least surprise. > > I'm used to how sound interacts in real world and then aucat steps in > > and introduces it's own laws of physics. > > > > To remedy this, aucat has an option -v, which lets you pre-divide the > > volume of inputs. This results in loss of dynamic range (quiet sounds > > might disappear and the maximum volume that you can set decreases). And > > also, if during usage the count of inputs raises above of what I > > predicted, the volume starts to jump up and down again. > > If you have N streams, the relative jump is, N / (N + 1) so there's > almost no step if N is large enough (it tends to 1). My experience is > that for N > 3, I hear no step, except if I pay special attention > and/or I use particular recordings. > > > > > Experimentally, I've found that if you do a saturating addition between > > inputs, it sounds very much how it might have sounded in real world > > I don't agree. Sound doesn't saturate in real world. When two persons > are speaking around me at the same time, I don't hear any > clipping/distortion. > That is true. > Human ears might saturate at very elevated sound levels but at such > level they are being damaged. > > > and > > how Macrohard Doors, among others, sounds like when playing > > multiple sounds. > > > > I bet it prescales, but nobody noticed it because it prescales all the > time. I bet that if "-v 100" was the aucat default, we wouldn't have > this discussion. We would be discussing about aucat defaults being > unpractical for conversions, or about the volume being too low when a > single stream is playing. > Now that I think about it, it might be using a hybrid aproach. Prescaling a bit and then adding with saturation (or something like that). I'll try to do some experiments. > > > > So, why is what I'm proposing better than what currently exists: > > > > * Resembles how sound behaves in real world more closely; > > * Doesn't violate the principle of least surprise; > > * No more annoying volume jumps up and down; > > * No need to use the -v option anymore / less stuff to remember / "it > > just works"; > > * No more choosing between being annoyed by volume jumps or loosing > > dynamic range. > > > > I guess this works well with your recordings by accident, as it would > with mines. I bet they are pre-divided, so you almost never hit the > ADATA_MIN and ADATA_MAX bundary, and there's almost no clipping, is > it? > Before posting, I tested by playing, I don't remember exactly, either 2 either 3 files simultaneously. And honestly, I didn't notice any distortions. This is probably because of the fact that like you said, it's rare that all the waves have +/-ADATA_UNIT value at a given moment. After reading your replies, I
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 19:58:56 + Jacob Meuser wrote: > On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote: > > On Wed, 11 May 2011 03:35:56 + > > Jacob Meuser wrote: > > > > > clipping is better than normalizing? really? > > > > Clipping might describe something like value&0xff, so no, not > > clipping, saturating addition. > > > > > + if (sum < ADATA_MIN) > > > > + sum = ADATA_MIN; > > > > + else if (sum > ADATA_MAX) > > > > + sum = ADATA_MAX; > > http://en.wikipedia.org/wiki/Clipping_(audio) Alright. > > > Try it and see for yourself. > > it is like jackd, which I find annoying. I agree, changing volume of > an active stream is annoying, but there is a reason for it. > > > > > > > what about the case where aucat is used for offline mixing? > > > > > > > What about it? > > it's a very different use case than the one you're trying to "fix". > I'm asking you how your "fix" is going to affect that use case. With the (already obsolete, so it doesn't matter anymore) diff that I posted, people who require this "normalization" would have to use the -v option. > > > > like the mixerctl change, you are taking away things that exist > > > for good reason, because it makes *your* situation better in *your* > > > opinion, when you can (mostly) have what you want with the current > > > code (if you just try a little). > > > > > > > I'm not taking anything away, > > you most certainly are. whether or not you believe the code to be > correct/useful is irrelevant, you are removing something. Whether it is a good thing or a bad thing is another question. > > > I'm setting things right. > > lemme offer a suggestion. the next time you run into something > that doesn't make any sense to you, check if someone else has already > questioned it and if any reason has already been given. or at least > ask why instead of asserting that it is wrong. that will get you > more sympathy, from me anyway. My impression is that the opposite is true on tech@: if you don't have a diff -- it's just empty, useless talk and you shouldn't post if you don't have a diff. Besides, looking from an ordinary Joe User viewpoint, I don't think there is anything that could convince me that aucat is presently appropriatly handling the task of being a system sound server. (Alexandre already gave me enough information about why things are the way they are; I don't see any problem in making everyone happy, the Joe Users who want the sound system to "just work" and advanced audio-philes who require advanced features and precision control) > > -- > jake...@sdf.lonestar.org > SDF Public Access UNIX System - http://sdf.lonestar.org
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 13:25:47 +0200 Alexandre Ratchov wrote: > On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote: > > On Wed, 11 May 2011 03:35:56 + > > Jacob Meuser wrote: > > > > > clipping is better than normalizing? really? > > > > Clipping might describe something like value&0xff, so no, not > > clipping, saturating addition. > > Try it and see for yourself. > > truncating higher bits or clipping alter the stream non-linearly and > imo both are evil. But I think the lowering of dynamic range also degrades the quality. You had 100 different values and then you suddenly have, say 20, some information has been lost... > > > > > > > > > what about the case where aucat is used for offline mixing? > > > > > > > What about it? > > > > I'd like "aucat -n -o result.wav -i file1.wav -i file2.wav" to not > saturate. > As far as I've read undeadly.org, you're a musician. I do understand that you require very precise control of audio and various processing operations. But I think most users probably aren't that sophisticated and are more interested in the sound system "just working", so that mp3s play, videos can be watched and aucat doesn't surprise them by having it's own will and changing the volume when it feels like it. > > > like the mixerctl change, you are taking away things that exist > > > for good reason, because it makes *your* situation better in *your* > > > opinion, when you can (mostly) have what you want with the current > > > code (if you just try a little). > > > > > > > I'm not taking anything away, I'm setting things right. > > Like I already said, the -v option stays fully functional. > > Everything can be boiled down to opinion. Please don't answer > > in the style "you're wrong because I said so". > > It's more complicated that "i'm right so you're wrong". > > Mixing (as other processing in aucat) is best effort. It's a > compromise between quality loss by distortion and by dynamic range > reduction. > > > I've already given enough insight and evidence as to per why the > > way it's done currently is wrong. > > > > Come on, both approches are physcally wrong, it's a matter of taste, > and the way you claim it's wrong tends to be irritating. Espectially > since this is 3+ years old code, and you guess this was discussed > plenty of times. Yes, you are right. We can model what happens with sound in real world only to some degree. > > > Explain why it's not important to adhere to the least surprise > > principle. > > least surprise priciple for me is: streams do not suffer non-linear > distortion when played through aucat. > I see. For me, a regular Joe User, the least surprising thing would be for aucat to do mixing in a similar manner to what I have previously experienced, i.e. similar to how it happens in real world and in other OS. > > Explain why is it better to force the users to choose between > > two evils when they could be offered one good. > > Because diffent users may have different needs. That is true, but I believe it is possible to do things in such a way, so that ordinary users who are not interested in super-advanced functionality can be freed from the burdens. > > > Explain why aucat should not model real world sound physics. > > > > because DACs have limited dynamic range; if you use "-v 100", > your closer to sound physics than with clipping. > We are talking about a system which directly interfaces to human sensory inputs. I think we can't rely only on logic in this case, subjective feelings have even higher priority. Consider MP3 for example -- it doesn't even try to be as precise as possible, rather, it makes it so that it would seem to humans that it sounds ok, but in reality the sound gets distorted. > [...] > > And note that two approaches are not exclusive. If you don't like the > way dynamic range is shared, roll a nice diff to disable this > feature. If people like it, and it hurts nobody, they will take it. > I agree, I think a hybrid approach could be used. > -- Alexandre
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 13:07:12 +0200
Alexandre Ratchov wrote:
> On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote:
> >
>
> below are few comments about the diff itself
>
> > Index: aparams.h
> > ===
> > RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
> > retrieving revision 1.11
> > diff -u -r1.11 aparams.h
> > --- aparams.h 5 Nov 2010 16:42:17 - 1.11
> > +++ aparams.h 10 May 2011 22:58:18 -
> > @@ -19,6 +19,8 @@
> >
> > #include
> >
> > +#include
> > +
> > #define NCHAN_MAX 16 /* max channel in a stream */
> > #define RATE_MIN 4000/* min sample rate */
> > #define RATE_MAX 192000 /* max sample rate */
> > @@ -64,6 +66,9 @@
> >
> > typedef short adata_t;
> >
> > +#define ADATA_MIN SHRT_MIN
> > +#define ADATA_MAX SHRT_MAX
> > +
>
> these don't hurt but there's a ADATA_UNIT macro that could do the job,
> I'd prefer having only one macro.
>
> > @@ -119,6 +127,28 @@
> > #else
> > #error "only 16-bit and 24-bit precisions are supported"
> > #endif
> > +
> > +/* saturating addition */
> > +static inline adata_t
> > +adata_sadd(register adata_t x, register adata_t y)
> > +{
> > +#if ADATA_BITS <= 16
> > + register int sum;
> > +#else
> > + register long long sum;
> > +#endif
> > +
> > + sum = x;
> > + sum += y;
> > +
> > + if (sum < ADATA_MIN)
> > + sum = ADATA_MIN;
> > + else if (sum > ADATA_MAX)
> > + sum = ADATA_MAX;
> > +
> > + return (adata_t) sum;
> > +}
> > +#define ADATA_SADD(x,y)adata_sadd(x,y)
> >
>
> you could inline this in mix_badd(), since it's the only place where
> clipping can occur
>
> > Index: aproc.c
> > ===
> > RCS file: /OpenBSD/src/usr.bin/aucat/aproc.c,v
> > retrieving revision 1.64
> > diff -u -r1.64 aproc.c
> > --- aproc.c 28 Apr 2011 07:20:03 - 1.64
> > +++ aproc.c 10 May 2011 22:58:19 -
> > @@ -617,6 +617,7 @@
> > unsigned i, j, cc, istart, inext, onext, ostart;
> > unsigned scount, icount, ocount;
> > int vol;
> > + adata_t sample;
>
> this should be 'int', adata_t is used for storage only.
>
> >
> > @@ -914,8 +916,6 @@
> > struct abuf *i, *obuf = LIST_FIRST(&p->outs);
> > unsigned odone;
> >
> > - mix_setmaster(p);
> > -
>
> this shouldn't be removed because this is the only way to avoid
> clipping and keeping the full dynamic range. Perhaps make it a
> device-specific option (see how "-a" option is implemented).
>
> > Index: dev.c
> > ===
> > RCS file: /OpenBSD/src/usr.bin/aucat/dev.c,v
> > retrieving revision 1.64
> > diff -u -r1.64 dev.c
> > --- dev.c 21 Oct 2010 18:57:42 - 1.64
> > +++ dev.c 10 May 2011 22:58:19 -
> > @@ -998,8 +998,7 @@
> > }
> > aproc_setin(d->mix, ibuf);
> > ibuf->r.mix.xrun = xrun;
> > - ibuf->r.mix.maxweight = vol;
> > - mix_setmaster(d->mix);
> > + ibuf->r.mix.weight = vol;
>
> maxweight should stay there, this is the maximum volume of the
> sub-device socket. It's used to cap volumes of clients of a particular
> sub-device.
>
Thanks, I'll keep these in mind when making the next diff.
> [...]
>
> I don't have a clear opinion. On the one hand, clipping is not
> acceptable for me. On the other hand it is statistically rare and a
> lot of people here would be more annoyed by the volume step, than by
> occasional clipping.
>
> You could try fixing above issues, and let people use the diff for
> long enough and see if quality is acceptable.
>
> Perhaps disable the mix_badd() change in the beginning, since it tends
> to make clipping less audible; this way we can see how often clipping
> occurs.
>
You've given me enough insight to come up with another, hopefully,
better idea. When the diff is ready I'll start a new thread.
Thanks.
> -- Alexandre
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote: > On Wed, 11 May 2011 03:35:56 + > Jacob Meuser wrote: > > > clipping is better than normalizing? really? > > Clipping might describe something like value&0xff, so no, not > clipping, saturating addition. > > > + if (sum < ADATA_MIN) > > > + sum = ADATA_MIN; > > > + else if (sum > ADATA_MAX) > > > + sum = ADATA_MAX; http://en.wikipedia.org/wiki/Clipping_(audio) > Try it and see for yourself. it is like jackd, which I find annoying. I agree, changing volume of an active stream is annoying, but there is a reason for it. > > > > what about the case where aucat is used for offline mixing? > > > > What about it? it's a very different use case than the one you're trying to "fix". I'm asking you how your "fix" is going to affect that use case. > > like the mixerctl change, you are taking away things that exist > > for good reason, because it makes *your* situation better in *your* > > opinion, when you can (mostly) have what you want with the current > > code (if you just try a little). > > > > I'm not taking anything away, you most certainly are. whether or not you believe the code to be correct/useful is irrelevant, you are removing something. > I'm setting things right. lemme offer a suggestion. the next time you run into something that doesn't make any sense to you, check if someone else has already questioned it and if any reason has already been given. or at least ask why instead of asserting that it is wrong. that will get you more sympathy, from me anyway. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: vmmap replacement, please test
On Wed, May 11, 2011 at 03:44:45AM +0200, Ariane van der Steldt wrote:
> On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
> > The newest version of vmmap (as of now) is vmmap_sys.diff.26
> > Since the diff is scheduled to go in may 20 and has a lot of changes and
> > fixes, please test this diff and report any failures and successes.
>
> I use this separate e-mail to publish the userspace part of the diff.
I missed a change in the userspace part of the diff, causing libkvm not
to compile. The below diff contains the fixed code.
--
Ariane
Index: lib/libkvm/kvm_proc.c
===
RCS file: /cvs/src/lib/libkvm/kvm_proc.c,v
retrieving revision 1.42
diff -u -d -p -r1.42 kvm_proc.c
--- lib/libkvm/kvm_proc.c 12 Mar 2011 04:54:28 - 1.42
+++ lib/libkvm/kvm_proc.c 11 May 2011 12:09:20 -
@@ -131,7 +131,7 @@ static void ps_str_e(struct ps_strings *
static char *
_kvm_ureadm(kvm_t *kd, const struct miniproc *p, u_long va, u_long *cnt)
{
- u_long addr, head, offset, slot;
+ u_long addr, offset, slot;
struct vm_anon *anonp, anon;
struct vm_map_entry vme;
struct vm_amap amap;
@@ -140,27 +140,28 @@ _kvm_ureadm(kvm_t *kd, const struct mini
if (kd->swapspc == 0) {
kd->swapspc = _kvm_malloc(kd, kd->nbpg);
if (kd->swapspc == 0)
- return (0);
+ return (NULL);
}
/*
* Look through the address map for the memory object
* that corresponds to the given virtual address.
-* The header just has the entire valid range.
*/
- head = (u_long)&p->p_vmspace->vm_map.header;
- addr = head;
+ addr = (u_long)RB_ROOT(&p->p_vmspace->vm_map.addr);
while (1) {
+ if (addr == 0)
+ return (NULL);
if (KREAD(kd, addr, &vme))
- return (0);
+ return (NULL);
- if (va >= vme.start && va < vme.end &&
- vme.aref.ar_amap != NULL)
+ if (va < vme.start)
+ addr = (u_long)RB_LEFT(&vme, daddrs.addr_entry);
+ else if (va >= vme.end + vme.fspace)
+ addr = (u_long)RB_RIGHT(&vme, daddrs.addr_entry);
+ else if (va >= vme.end)
+ return (NULL);
+ else
break;
-
- addr = (u_long)vme.next;
- if (addr == head)
- return (0);
}
/*
Index: usr.sbin/procmap/procmap.c
===
RCS file: /cvs/src/usr.sbin/procmap/procmap.c,v
retrieving revision 1.38
diff -u -d -p -r1.38 procmap.c
--- usr.sbin/procmap/procmap.c 23 Apr 2011 01:01:34 - 1.38
+++ usr.sbin/procmap/procmap.c 11 May 2011 12:09:24 -
@@ -169,10 +169,13 @@ struct nlist nl[] = {
void load_symbols(kvm_t *);
void process_map(kvm_t *, pid_t, struct kinfo_proc *, struct sum *);
-size_t dump_vm_map_entry(kvm_t *, struct kbit *, struct kbit *, int,
+struct vm_map_entry *load_vm_map_entries(kvm_t *, struct vm_map_entry *,
+struct vm_map_entry *);
+void unload_vm_map_entries(struct vm_map_entry *);
+size_t dump_vm_map_entry(kvm_t *, struct kbit *, struct vm_map_entry *,
struct sum *);
-char *findname(kvm_t *, struct kbit *, struct kbit *, struct kbit *,
- struct kbit *, struct kbit *);
+char *findname(kvm_t *, struct kbit *, struct vm_map_entry *, struct kbit *,
+struct kbit *, struct kbit *);
int search_cache(kvm_t *, struct kbit *, char **, char *, size_t);
#if 0
void load_name_cache(kvm_t *);
@@ -182,6 +185,19 @@ static void __dead usage(void);
static pid_t strtopid(const char *);
void print_sum(struct sum *, struct sum *);
+/*
+ * uvm_map address tree implementation.
+ */
+static int no_impl(void *, void *);
+static int
+no_impl(void *p, void *q)
+{
+ errx(1, "uvm_map address comparison not implemented");
+ return 0;
+}
+
+RB_GENERATE(uvm_map_addr, vm_map_entry, daddrs.addr_entry, no_impl);
+
int
main(int argc, char *argv[])
{
@@ -347,12 +363,12 @@ print_sum(struct sum *sum, struct sum *t
void
process_map(kvm_t *kd, pid_t pid, struct kinfo_proc *proc, struct sum *sum)
{
- struct kbit kbit[4], *vmspace, *vm_map, *header, *vm_map_entry;
- struct vm_map_entry *last;
- u_long addr, next;
+ struct kbit kbit[3], *vmspace, *vm_map;
+ struct vm_map_entry *vm_map_entry;
size_t total = 0;
char *thing;
uid_t uid;
+ int vmmap_flags;
if ((uid = getuid())) {
if (pid == 0) {
@@ -367,13 +383,9 @@ process_map(kvm_t *kd, pid_t pid, struct
vmspace = &kbit[0];
vm_map = &kbit[1];
- header = &kbit[2];
- vm_map_entry = &kbit[3];
A(vmspace) = 0;
A(vm_map) = 0;
Re: ksh completion
On Tue, May 10, 2011 at 15:23:52 +0400, Alexander Polakov wrote: > * LEVAI Daniel [110510 14:33]: > > On Tue, May 10, 2011 at 12:28:06 +0200, LEVAI Daniel wrote: > > > On Tue, May 10, 2011 at 08:41:48 +0200, LEVAI Daniel wrote: > > > > On Mon, May 09, 2011 at 23:48:46 +0400, Alexander Polakov wrote: > > > > > * Alexander Polakov [110502 18:19]: > > > > > > Do you mean something like this or I got it all wrong again and we > > > > > > have to wait another 15 years for someone to dig into this? > > > > > > > > > > That diff was wrong, this one is likely less wrong. > > > > This is working fine for me. > > > > > > I've just found a usecase where it fails to complete a filename: > > > > > > $ touch 'aaa: bbb ccc' > > > $ touch 'aaa: bbc ddd' > > > $ ls -la a > > > $ ls -la aaa:\ bb > > > aaa: bbb ccc aaa: bbc ddd > > > $ ls -la aaa:\ bbc > > > ^^^ nothing happens > > Apperantly, adding ':' to ESCAPEDCHARS solves the problem. Do you think > > there is any sideeffect to this? > > No, I don't think so. Let's just add it and find out in practice. So far so good. I really like this patch. Thanks for it :) Is it acceptable in the tree? Daniel -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On 05/11/11 02:29, Marco Peereboom wrote: > I think this is great. I find our current code odd and I agree this is > what one expects. +1
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote: > On Wed, 11 May 2011 03:35:56 + > Jacob Meuser wrote: > > > clipping is better than normalizing? really? > > Clipping might describe something like value&0xff, so no, not > clipping, saturating addition. > Try it and see for yourself. truncating higher bits or clipping alter the stream non-linearly and imo both are evil. > > > > > what about the case where aucat is used for offline mixing? > > > > What about it? > I'd like "aucat -n -o result.wav -i file1.wav -i file2.wav" to not saturate. > > like the mixerctl change, you are taking away things that exist > > for good reason, because it makes *your* situation better in *your* > > opinion, when you can (mostly) have what you want with the current > > code (if you just try a little). > > > > I'm not taking anything away, I'm setting things right. > Like I already said, the -v option stays fully functional. > Everything can be boiled down to opinion. Please don't answer > in the style "you're wrong because I said so". It's more complicated that "i'm right so you're wrong". Mixing (as other processing in aucat) is best effort. It's a compromise between quality loss by distortion and by dynamic range reduction. > I've already given enough insight and evidence as to per why the > way it's done currently is wrong. > Come on, both approches are physcally wrong, it's a matter of taste, and the way you claim it's wrong tends to be irritating. Espectially since this is 3+ years old code, and you guess this was discussed plenty of times. > Explain why it's not important to adhere to the least surprise > principle. least surprise priciple for me is: streams do not suffer non-linear distortion when played through aucat. > Explain why is it better to force the users to choose between > two evils when they could be offered one good. Because diffent users may have different needs. > Explain why aucat should not model real world sound physics. > because DACs have limited dynamic range; if you use "-v 100", your closer to sound physics than with clipping. [...] And note that two approaches are not exclusive. If you don't like the way dynamic range is shared, roll a nice diff to disable this feature. If people like it, and it hurts nobody, they will take it. -- Alexandre
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote:
>
below are few comments about the diff itself
> Index: aparams.h
> ===
> RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
> retrieving revision 1.11
> diff -u -r1.11 aparams.h
> --- aparams.h 5 Nov 2010 16:42:17 - 1.11
> +++ aparams.h 10 May 2011 22:58:18 -
> @@ -19,6 +19,8 @@
>
> #include
>
> +#include
> +
> #define NCHAN_MAX16 /* max channel in a stream */
> #define RATE_MIN 4000/* min sample rate */
> #define RATE_MAX 192000 /* max sample rate */
> @@ -64,6 +66,9 @@
>
> typedef short adata_t;
>
> +#define ADATA_MINSHRT_MIN
> +#define ADATA_MAXSHRT_MAX
> +
these don't hurt but there's a ADATA_UNIT macro that could do the job,
I'd prefer having only one macro.
> @@ -119,6 +127,28 @@
> #else
> #error "only 16-bit and 24-bit precisions are supported"
> #endif
> +
> +/* saturating addition */
> +static inline adata_t
> +adata_sadd(register adata_t x, register adata_t y)
> +{
> +#if ADATA_BITS <= 16
> + register int sum;
> +#else
> + register long long sum;
> +#endif
> +
> + sum = x;
> + sum += y;
> +
> + if (sum < ADATA_MIN)
> + sum = ADATA_MIN;
> + else if (sum > ADATA_MAX)
> + sum = ADATA_MAX;
> +
> + return (adata_t) sum;
> +}
> +#define ADATA_SADD(x,y) adata_sadd(x,y)
>
you could inline this in mix_badd(), since it's the only place where
clipping can occur
> Index: aproc.c
> ===
> RCS file: /OpenBSD/src/usr.bin/aucat/aproc.c,v
> retrieving revision 1.64
> diff -u -r1.64 aproc.c
> --- aproc.c 28 Apr 2011 07:20:03 - 1.64
> +++ aproc.c 10 May 2011 22:58:19 -
> @@ -617,6 +617,7 @@
> unsigned i, j, cc, istart, inext, onext, ostart;
> unsigned scount, icount, ocount;
> int vol;
> + adata_t sample;
this should be 'int', adata_t is used for storage only.
>
> @@ -914,8 +916,6 @@
> struct abuf *i, *obuf = LIST_FIRST(&p->outs);
> unsigned odone;
>
> - mix_setmaster(p);
> -
this shouldn't be removed because this is the only way to avoid
clipping and keeping the full dynamic range. Perhaps make it a
device-specific option (see how "-a" option is implemented).
> Index: dev.c
> ===
> RCS file: /OpenBSD/src/usr.bin/aucat/dev.c,v
> retrieving revision 1.64
> diff -u -r1.64 dev.c
> --- dev.c 21 Oct 2010 18:57:42 - 1.64
> +++ dev.c 10 May 2011 22:58:19 -
> @@ -998,8 +998,7 @@
> }
> aproc_setin(d->mix, ibuf);
> ibuf->r.mix.xrun = xrun;
> - ibuf->r.mix.maxweight = vol;
> - mix_setmaster(d->mix);
> + ibuf->r.mix.weight = vol;
maxweight should stay there, this is the maximum volume of the
sub-device socket. It's used to cap volumes of clients of a particular
sub-device.
[...]
I don't have a clear opinion. On the one hand, clipping is not
acceptable for me. On the other hand it is statistically rare and a
lot of people here would be more annoyed by the volume step, than by
occasional clipping.
You could try fixing above issues, and let people use the diff for
long enough and see if quality is acceptable.
Perhaps disable the mix_badd() change in the beginning, since it tends
to make clipping less audible; this way we can see how often clipping
occurs.
-- Alexandre
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed May 11 2011 06:10:03 AM EDT, Brad wrote: oops. looks like my phone sent the empty reply when I put it back in my pocket after reading this. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Tue May 10 2011 11:35:56 PM EDT, Jacob Meuser
wrote:
> clipping is better than normalizing?B really?
>
> what about the case where aucat is used for offline mixing?
>
> like the mixerctl change, you are taking away things that exist
> for good reason, because it makes *your* situation better in *your*
> opinion, when you can (mostly) have what you want with the current
> code (if you just try a little).
>
> On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote:
> > I'm sitting at work, listening to music, debugging a web-application
> > with JavaScript alert()s. Each time an alert window pops up, the
> > browser plays a sound. For a brief moment, the volume drops twicefold
> > then goes back to normal. This is annoying and doesn't make sense.
> >
> > In real life, if you are surrounded by multiple sound sources, their
> > sound volumes will not be divided by the total amount of sound sources.
> > Their sounds will add up until they blur and you can't distinguish
> > anything anymore. Other operating systems, such as Macrohard Doors, do
> > mixing by modeling this real world behaviour.
> >
> > In this sense, aucat violates the principle of least surprise.
> > I'm used to how sound interacts in real world and then aucat steps in
> > and introduces it's own laws of physics.
> >
> > To remedy this, aucat has an option -v, which lets you pre-divide the
> > volume of inputs. This results in loss of dynamic range (quiet sounds
> > might disappear and the maximum volume that you can set decreases). And
> > also, if during usage the count of inputs raises above of what I
> > predicted, the volume starts to jump up and down again.
> >
> > Experimentally, I've found that if you do a saturating addition between
> > inputs, it sounds very much how it might have sounded in real world and
> > how Macrohard Doors, among others, sounds like when playing
> > multiple sounds.
> >
> >
> > So, why is what I'm proposing better than what currently exists:
> >
> > * Resembles how sound behaves in real world more closely;
> > * Doesn't violate the principle of least surprise;
> > * No more annoying volume jumps up and down;
> > * No need to use the -v option anymore / less stuff to remember / "it
> > just works";
> > * No more choosing between being annoyed by volume jumps or loosing
> > dynamic range.
> >
> > (This doesn't affect the -v option, it remains fully functional.)
> >
> > Tested on i386 and amd64 with 16 bits and 24 bits.
> >
> >
> > Index: abuf.h
> > ===
> > RCS file: /OpenBSD/src/usr.bin/aucat/abuf.h,v
> > retrieving revision 1.23
> > diff -u -r1.23 abuf.h
> > --- abuf.hB B B 21 Oct 2010 18:57:42 -B B B 1.23
> > +++ abuf.hB B B 10 May 2011 22:58:18 -
> > @@ -46,7 +46,6 @@
> > B B B union {
> > B B B B B B struct {
> > B B B B B B B B B int weight;B B B /* dynamic range */B B B
> > -B B B B B B B B B int maxweight;B B B /* max dynamic range allowed */
> > B B B B B B B B B unsigned vol;B B B /* volume within the dynamic range
> > */
> > B B B B B B B B B unsigned done;B B B /* frames ready */
> > B B B B B B B B B unsigned xrun;B B B /* underrun policy */
> > Index: aparams.h
> > ===
> > RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
> > retrieving revision 1.11
> > diff -u -r1.11 aparams.h
> > --- aparams.hB B B 5 Nov 2010 16:42:17 -B B B 1.11
> > +++ aparams.hB B B 10 May 2011 22:58:18 -
> > @@ -19,6 +19,8 @@
> >
> > #include
> >
> > +#include
> > +
> > #define NCHAN_MAXB B B 16B B B B B B /* max channel in a stream */
> > #define RATE_MINB B B 4000B B B B B B /* min sample rate */
> > #define RATE_MAXB B B 192000B B B B B B /* max sample rate */
> > @@ -64,6 +66,9 @@
> >
> > typedef short adata_t;
> >
> > +#define ADATA_MINB B B B B B SHRT_MIN
> > +#define ADATA_MAXB B B B B B SHRT_MAX
> > +
> > #define ADATA_MUL(x,y)B B B B B B (((int)(x) * (int)(y)) >> (ADATA_BITS -
> > 1))
> > #define ADATA_MULDIV(x,y,z)B B B ((int)(x) * (int)(y) / (int)(z))
> >
> > @@ -71,6 +76,9 @@
> >
> > typedef int adata_t;
> >
> > +#define ADATA_MINB B B B B B (-0xff / 2)
> > +#define ADATA_MAXB B B B B B (0xff / 2)
> > +
> > #if defined(__i386__) && defined(__GNUC__)
> >
> > static inline int
> > @@ -119,6 +127,28 @@
> > #else
> > #error "only 16-bit and 24-bit precisions are supported"
> > #endif
> > +
> > +/* saturating addition */
> > +static inline adata_t
> > +adata_sadd(register adata_t x, register adata_t y)
> > +{
> > +#if ADATA_BITS <= 16
> > +B B B register int sum;
> > +#else
> > +B B B register long long sum;
> > +#endif
> > +
> > +B B B sum = x;
> > +B B B sum += y;
> > +
> > +B B B if (sum < ADATA_MIN)
> > +B B B B B B sum = ADATA_MIN;
> > +B B B else if (sum > ADATA_MAX)
> > +B B B B B B sum = ADATA_MAX;
> > +
> > +B B B return (adata_t) sum;
> > +}
> > +#define ADATA
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote:
> I'm sitting at work, listening to music, debugging a web-application
> with JavaScript alert()s. Each time an alert window pops up, the
> browser plays a sound. For a brief moment, the volume drops twicefold
> then goes back to normal. This is annoying and doesn't make sense.
I agree, this is annoying.
> In real life, if you are surrounded by multiple sound sources, their
> sound volumes will not be divided by the total amount of sound sources.
> Their sounds will add up until they blur and you can't distinguish
> anything anymore. Other operating systems, such as Macrohard Doors, do
> mixing by modeling this real world behaviour.
my physics lessons say that pressure is additive, so the resulting
pressure of two sources close to each other is the sum of their
respective pressures. And there's no clipping in nature, so no need to
test against any MIN and MAX value.
A simple addition is what our ears expect.
On the other hand DACs operate on a limited dynamic range, so there's
a MIN and a MAX value. This is not how physics laws are, there's not
MIN and MAX values for pressure.
So keeping full dynamic range of the DAC and doing the physics
correctly at the same time is simply mathematically impossible.
What options do we have?
(1) prescale streams => loose few dBs of dynamic range
(2) clipping => is not natural except if there's no clipping
(3) using (x + y - x * y) => distortion, similar to (2)
(4) do (1) but with DACs with larger dynamic range => ok
(5) ...
The choice behind aucat is to never add distortion, clipping or
whatever. So (1) and (4) are the only options afaics
> In this sense, aucat violates the principle of least surprise.
> I'm used to how sound interacts in real world and then aucat steps in
> and introduces it's own laws of physics.
>
> To remedy this, aucat has an option -v, which lets you pre-divide the
> volume of inputs. This results in loss of dynamic range (quiet sounds
> might disappear and the maximum volume that you can set decreases). And
> also, if during usage the count of inputs raises above of what I
> predicted, the volume starts to jump up and down again.
If you have N streams, the relative jump is, N / (N + 1) so there's
almost no step if N is large enough (it tends to 1). My experience is
that for N > 3, I hear no step, except if I pay special attention
and/or I use particular recordings.
>
> Experimentally, I've found that if you do a saturating addition between
> inputs, it sounds very much how it might have sounded in real world
I don't agree. Sound doesn't saturate in real world. When two persons
are speaking around me at the same time, I don't hear any
clipping/distortion.
Human ears might saturate at very elevated sound levels but at such
level they are being damaged.
> and
> how Macrohard Doors, among others, sounds like when playing
> multiple sounds.
>
I bet it prescales, but nobody noticed it because it prescales all the
time. I bet that if "-v 100" was the aucat default, we wouldn't have
this discussion. We would be discussing about aucat defaults being
unpractical for conversions, or about the volume being too low when a
single stream is playing.
>
> So, why is what I'm proposing better than what currently exists:
>
> * Resembles how sound behaves in real world more closely;
> * Doesn't violate the principle of least surprise;
> * No more annoying volume jumps up and down;
> * No need to use the -v option anymore / less stuff to remember / "it
> just works";
> * No more choosing between being annoyed by volume jumps or loosing
> dynamic range.
>
I guess this works well with your recordings by accident, as it would
with mines. I bet they are pre-divided, so you almost never hit the
ADATA_MIN and ADATA_MAX bundary, and there's almost no clipping, is
it?
If so, for such streams you could do:
int
adata_sadd(int x, int y)
{
return x + y;
}
and the result would be almost the same.
-- Alexandre
