Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 03:35:56 +
Jacob Meuser jake...@sdf.lonestar.org wrote:
clipping is better than normalizing? really?
Clipping might describe something like value0xff, so no, not
clipping, saturating addition.
Try it and see for yourself.
what about the case where aucat is used for offline mixing?
What about 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.
I've already given enough insight and evidence as to per why the
way it's done currently is wrong.
Explain why it's not important to adhere to the least surprise
principle.
Explain why is it better to force the users to choose between
two evils when they could be offered one good.
Explain why aucat should not model real world sound physics.
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.h 21 Oct 2010 18:57:42 - 1.23
+++ abuf.h 10 May 2011 22:58:18 -
@@ -46,7 +46,6 @@
union {
struct {
int weight; /* dynamic range */
- int maxweight; /* max dynamic range allowed */
unsigned vol; /* volume within the dynamic range */
unsigned done; /* frames ready */
unsigned xrun; /* 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.h 5 Nov 2010 16:42:17 - 1.11
+++ aparams.h 10 May 2011 22:58:18 -
@@ -19,6 +19,8 @@
#include sys/param.h
+#include limits.h
+
#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
+
#define ADATA_MUL(x,y) (((int)(x) * (int)(y)) (ADATA_BITS -
1))
#define ADATA_MULDIV(x,y,z)((int)(x) * (int)(y) / (int)(z))
@@ -71,6 +76,9 @@
typedef int adata_t;
+#define ADATA_MIN (-0xff / 2)
+#define ADATA_MAX (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
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
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 jake...@sdf.lonestar.org
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 sys/param.h
+#include limits.h
+
#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_SADD(x,y)B B B B B B adata_sadd(x,y)
#define MIDI_MAXCTLB B B B B B 127
#define MIDI_TO_ADATA(m)B B B (aparams_ctltovol[m] (ADATA_BITS - 16))
Index: aproc.c
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 b...@comstyle.com 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 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 sys/param.h
+#include limits.h
+
#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: ksh completion
On Tue, May 10, 2011 at 15:23:52 +0400, Alexander Polakov wrote: * LEVAI Daniel l...@ecentrum.hu [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 polac...@gmail.com [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 aTAB $ ls -la aaa:\ bbTAB aaa: bbb ccc aaa: bbc ddd $ ls -la aaa:\ bbcTAB ^^^ 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: 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;
- A(header) = 0;
-
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 jake...@sdf.lonestar.org wrote: clipping is better than normalizing? really? Clipping might describe something like value0xff, 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: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 13:07:12 +0200
Alexandre Ratchov a...@caoua.org 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 sys/param.h
+#include limits.h
+
#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, 11 May 2011 13:25:47 +0200 Alexandre Ratchov a...@caoua.org wrote: On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote: On Wed, 11 May 2011 03:35:56 + Jacob Meuser jake...@sdf.lonestar.org wrote: clipping is better than normalizing? really? Clipping might describe something like value0xff, 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 19:58:56 + Jacob Meuser jake...@sdf.org wrote: On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote: On Wed, 11 May 2011 03:35:56 + Jacob Meuser jake...@sdf.lonestar.org wrote: clipping is better than normalizing? really? Clipping might describe something like value0xff, 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 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
[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
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')
