<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; </style><span style="font-style: italic;">Also consider to what happens when the stereo signals are summed</span><br style="font-style: italic;"><span style="font-style: italic;">
to mono. If your panner is set slightly off-center, L and R will</span><br style="font-style: italic;"><span style="font-style: italic;">
have nearly the same gain (since they need to be identical for</span><br style="font-style: italic;"><span style="font-style: italic;">
a center source) and a delay between them of a fraction of a</span><br style="font-style: italic;"><span style="font-style: italic;">
millisecond or so. Summing L and R will result in quite strong </span><br style="font-style: italic;"><span style="font-style: italic;">
comb filter effects.</span><br>
<br>
Thanks for starting some thoughts on the time alignment aspects.<br>
Yes, I did make that provision for a mono source, so that the same signal level is added to L and R whether panned or not, but just time shifted in one channel if panned. And full left or full right is a separate 'function' and only has signal in one side. <br>
I will add the traditional pan. <br>
Is mono compatibility really worth worrying about these days?<br>
<br>
<br>
<span style="font-style: italic;">Because I do not just record signals directly from the A/D converters,</span><br style="font-style: italic;"><span style="font-style: italic;">
but also signals that have already had some processing and probably</span><br style="font-style: italic;"><span style="font-style: italic;">
will have some more later. All serious audio processing in Linux (and</span><br style="font-style: italic;"><span style="font-style: italic;">
in almost all environments where audio is processed digitally) is done</span><br style="font-style: italic;"><span style="font-style: italic;">
in floating point format, for good reasons. Why should I convert each</span><br style="font-style: italic;"><span style="font-style: italic;">
time I read or write a file ? That would only add errors.</span><br>
<br>
Okay, makes sense. <br>
<br>
<span style="font-style: italic;">You could probably eliminate a lot of code by using something like</span><br style="font-style: italic;"><span style="font-style: italic;">
libsndfile. And you would at least be able to read floating point</span><br style="font-style: italic;"><span style="font-style: italic;">
files. </span><br>
<br>
I can see also adding options for things like LADSPA or LV2. But, I'd also like the code to run if these things are not present in the system. <br>
<br>
<br>
<span style="font-style: italic;">If all filtering, effects, etc. is done in FP format, it's plain</span><br style="font-style: italic;"><span style="font-style: italic;">
silly to convert to integer just to add some values. And adding</span><br style="font-style: italic;"><span style="font-style: italic;">
also happens even when you don't see it explicitly. Any linear</span><br style="font-style: italic;"><span style="font-style: italic;">
filter is defined by its impulse response. Depending on the type</span><br style="font-style: italic;"><span style="font-style: italic;">
of filter that could be hundreds or even thousands of samples long.</span><br style="font-style: italic;"><span style="font-style: italic;">
So every output sample is a weighted sum of hundreds or thousands</span><br style="font-style: italic;"><span style="font-style: italic;">
of input samples even if not computed explicitly that way. Are you</span><br style="font-style: italic;"><span style="font-style: italic;">
really claiming that doing that in FP is OK while adding a few</span><br style="font-style: italic;"><span style="font-style: italic;">
signals on a mix bus isn't ?</span><br style="font-style: italic;">
<br>
There are a couple of outstanding (commercial) fixed point filters out there, by the way. To answer your question, no I basically agree with you. But realize the initial challenge of this project was to make an absolutely pure signal path. And that path is still there if you choose to not use effects. When you do use effects it's 64 bit float because I am wary of 32 bit float. <br style="font-style: italic;"><br>
<span style="font-style: italic;">Quote from the Quick Start Guide:</span><br style="font-style: italic;">
<br style="font-style: italic;"><span style="font-style: italic;">
There are 3 text files that control Mixer4 and they must be kept</span><br style="font-style: italic;"><span style="font-style: italic;">
in the same directory, at least for now, as the Mixer4 executable.</span><br>
<br>
Okay, I thought that's where the confusion was. 'For now' is referring to walking the user through the set up process, not the state of the code. I did not want to get into different directories for the newbie user. I wanted to make initial setup as straight forward as possible. <br>
<br>
Grekim<br>
<br>
<br>
<span style="font-weight: bold;">On Fri 23/11/12 4:34 AM , Fons Adriaensen fons@linuxaudio.org sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">On Thu, Nov 22, 2012 at 10:26:10PM -0500, Grekim wrote:<br>
<br>
<span style="color: rgb(102, 102, 102);">> /Maybe neat on headphones, but definitely the wrong thing for</span><br>
<span style="color: rgb(102, 102, 102);">> reproduction on speakers. Also bad for mono compatibility.</span><br>
<span style="color: rgb(102, 102, 102);">> And since it's closed source it's not possible to change</span><br>
<span style="color: rgb(102, 102, 102);">> this to normal panning, which would be a trivial exercise</span><br>
<span style="color: rgb(102, 102, 102);">> otherwise./</span><br>
<span style="color: rgb(102, 102, 102);">> </span><br>
<span style="color: rgb(102, 102, 102);">> I'd like to learn more about why it's so wrong.</span><br>
<br>
There's no one-line answer to that. To understand why it's wrong<br>
you have to work out how the signals from the two speakers combine<br>
at the ears and compare the result to what happens for a real<br>
sound source.<br>
<br>
For low frequencies the analysis is very simple, you can do it<br>
in two minutes just using pencil and paper. Just do it and you'll<br>
see. For mid an high frequencies it gets considerably more complex<br>
and a lot of psycho-acoustics is involved. The results go against<br>
simple intuition, which is why many people have some difficulty<br>
accepting them.<br>
<br>
Also consider to what happens when the stereo signals are summed<br>
to mono. If your panner is set slightly off-center, L and R will<br>
have nearly the same gain (since they need to be identical for<br>
a center source) and a delay between them of a fraction of a<br>
millisecond or so. Summing L and R will result in quite strong <br>
comb filter effects.<br>
<br>
<span style="color: rgb(102, 102, 102);">> /I've got ~3TB of floating point files here, and I'm not going</span><br>
<span style="color: rgb(102, 102, 102);">> to convert them just to be able to use a particular - any - SW./</span><br>
<span style="color: rgb(102, 102, 102);">> </span><br>
<span style="color: rgb(102, 102, 102);">> Why did you record in floating point format if your A/D converters are not?</span><br>
<br>
Because I do not just record signals directly from the A/D converters,<br>
but also signals that have already had some processing and probably<br>
will have some more later. All serious audio processing in Linux (and<br>
in almost all environments where audio is processed digitally) is done<br>
in floating point format, for good reasons. Why should I convert each<br>
time I read or write a file ? That would only add errors.<br>
<br>
A/D and D/A converters are probably the only components in the chain<br>
that 'naturally' use an integer format. But even that isn't really<br>
true any more. Most high quality converters are not just the bare<br>
converter and an analog filter. They have some digital processing<br>
going on between the SW interface and the actual converters, e.g.<br>
most of the anti-alias filtering will be done digitally in an<br>
oversampling converter. And that processing could very well be done<br>
in FP format these days. Some high end sound cards (e.g. RME) have<br>
native floating point interfaces.<br>
<br>
There is nothing magic about the 2^16 or 2^24 analog levels that<br>
correspond exactly to integer sample values. Change your gain by<br>
0.1 dB and they will be an entirely different set, as good or as<br>
bad as any.<br>
<br>
<span style="color: rgb(102, 102, 102);">> /</span><br>
<span style="color: rgb(102, 102, 102);">> The summing being exact is quite irrelevant if the rest isn't,</span><br>
<span style="color: rgb(102, 102, 102);">> and doesn't need to be anyway./</span><br>
<span style="color: rgb(102, 102, 102);">> </span><br>
<span style="color: rgb(102, 102, 102);">> Sorry it's not relevant to you. Aside for the latest version which</span><br>
<span style="color: rgb(102, 102, 102);">> does use ALSA, I have about 4 C header files. So there's no libsend</span><br>
<span style="color: rgb(102, 102, 102);">> file or anything like that. </span><br>
<br>
You could probably eliminate a lot of code by using something like<br>
libsndfile. And you would at least be able to read floating point<br>
files. <br>
<br>
If all filtering, effects, etc. is done in FP format, it's plain<br>
silly to convert to integer just to add some values. And adding<br>
also happens even when you don't see it explicitly. Any linear<br>
filter is defined by its impulse response. Depending on the type<br>
of filter that could be hundreds or even thousands of samples long.<br>
So every output sample is a weighted sum of hundreds or thousands<br>
of input samples even if not computed explicitly that way. Are you<br>
really claiming that doing that in FP is OK while adding a few<br>
signals on a mix bus isn't ?<br>
<br>
Regarding the latter, it may also help to analyse the situation a<br>
bit more rigorously before jumping to easy conclusions. It involves<br>
a bit of maths, but nothing esoterical. <br>
<br>
<span style="color: rgb(102, 102, 102);">> /OK, then the info on your site is out of date.../</span><br>
<span style="color: rgb(102, 102, 102);">> </span><br>
<span style="color: rgb(102, 102, 102);">> Don't think so. </span><br>
<br>
Quote from the Quick Start Guide:<br>
<br>
There are 3 text files that control Mixer4 and they must be kept<br>
in the same directory, at least for now, as the Mixer4 executable.<br>
<br>
<br>
Ciao,<br>
<br>
-- <br>
FA<br>
<br>
A world of exhaustive, reliable metadata would be an utopia.<br>
It's also a pipe-dream, founded on self-delusion, nerd hubris<br>
and hysterically inflated market opportunities. (Cory Doctorow)<br>
<br>
<br>
</blockquote></HTML>