xwax-devel

[xwax-devel] Add timecode gain to command line options

[Olivier G. <ol...@os...>]

Hi everyone,

I wanted to complete this patch for me since a long time. I basically
changed constants ZERO_THRESHOLD and REF_PEAKS_AVG to variables inside
timecoder. I then made a dumb switch case to map values to a single
arbitrary gain value. For now my patch can map values 0 (no
amplification) to 6 (max amplification) following this translation
table. (if anyone sees a better math way of expressing my switch case,
please comment)

timecode_gain zero_threshold ref_peaks_avg
0 	128 	48
1	112	48
2	96	40
3	80	32
4	64	24
5	48	16
6	32	8

I tested it, and my American Audio Versaport sound card worked better
with max amplification, gain 6. Similar to what I tested before.

Three questions for Mark (or anyone that knows better).
First does ref_peaks_avg needs to be a multiple of 8 ? Does it needs to
follow zero_threshold like I coded here? And lastly is 128 the minimum
or one could safely attenuate hot signal by using values >128? (said it
doesn't clip the ADC of my sound card).

My sound card using signal played from the original rane timecode wav
file in a pioneer cddj is just too hot. I had to burn the wav using -6db
of digital attenuation. I'd like to be able to use a stock
serato/trackto hardware, so I could just drop by, plug and mix on
regular dj setups. This patch brings lots of flexibility for sound
cards/sources.


Screen shot of one deck using no hardware preamp, and second deck using
hardware preamp. I used another full on riaa eq phono patch I made last
year for quite a long time. I reinstalled my computer and wanted to try
mark's advice to only play with those constants, it seems to work
equally well.

Feedback is welcome, source code is 1.3 + modifications hosted on
github. You can simply download a zip file and compile to test on your side.

https://github.com/oligau/xwax-oligau/tree/1.3-timecoder_gain


Have a nice one,

Olivier

Re: [xwax-devel] Add timecode gain to command line options

[Mark H. <ma...@xw...>]

On Wed, 13 Mar 2013, Olivier Gauthier wrote:

> Hi everyone,
> 
> I wanted to complete this patch for me since a long time. I basically
> changed constants ZERO_THRESHOLD and REF_PEAKS_AVG to variables inside
> timecoder. I then made a dumb switch case to map values to a single
> arbitrary gain value. For now my patch can map values 0 (no
> amplification) to 6 (max amplification) following this translation
> table. (if anyone sees a better math way of expressing my switch case,
> please comment)
> 
> timecode_gain zero_threshold ref_peaks_avg
> 0 	128 	48
> 1	112	48
> 2	96	40
> 3	80	32
> 4	64	24
> 5	48	16
> 6	32	8
> 
> I tested it, and my American Audio Versaport sound card worked better
> with max amplification, gain 6. Similar to what I tested before.
> 
> Three questions for Mark (or anyone that knows better).
> First does ref_peaks_avg needs to be a multiple of 8 ?

No, it doesn't.

> Does it needs to follow zero_threshold like I coded here?

It shouldn't do. And that's what I'm finding unusual about your patching 
-- that you feel the need to change ref_peaks_avg. Did you find you need 
to change ref_peaks_avg for it to work?

If so then it means that maybe you uncovered something quite incorrect in 
the filtering.

> And lastly is 128 the minimum or one could safely attenuate hot signal 
> by using values >128? (said it doesn't clip the ADC of my sound card).

You're not actually attenuating by alterning zero_threshold. All you're 
doing is altering the threshold at which xwax starts to ignore the signal. 
Really, zero_threshold is "noise threshold of soundcard"

When I first wrote xwax I tested a variety of cards and found this to be a 
value common to all.

What you're doing when applying a 'software preamp' is hoping that your 
soundcard is better.

So I can see some merit to controlling the noise threshold; it was good to 
never need to have users control this. Really this should be done in 
conjunction with some kind of way to measure the noise threshold. Hmmm.

> My sound card using signal played from the original rane timecode wav
> file in a pioneer cddj is just too hot. I had to burn the wav using -6db
> of digital attenuation. I'd like to be able to use a stock
> serato/trackto hardware, so I could just drop by, plug and mix on
> regular dj setups. This patch brings lots of flexibility for sound
> cards/sources.

As long as the soundcard doesn't clip the signal, xwax can cope with 
it.

If the signal is clipped and you're having to burn at -6dB to fix it then 
no amount of software DSP will help you here -- the information is lost 
before it gets to the PC. Though you might be able to modify the 
soundcard's mixer to turn down the signal.

> Screen shot of one deck using no hardware preamp, and second deck using
> hardware preamp. I used another full on riaa eq phono patch I made last
> year for quite a long time. I reinstalled my computer and wanted to try
> mark's advice to only play with those constants, it seems to work
> equally well.
> 
> Feedback is welcome, source code is 1.3 + modifications hosted on
> github. You can simply download a zip file and compile to test on your side.
> 
> https://github.com/oligau/xwax-oligau/tree/1.3-timecoder_gain
> 
> 
> Have a nice one,
> 
> Olivier
> 

-- 
Mark

Re: [xwax-devel] Add timecode gain to command line options

[Mark H. <ma...@xw...>]

On Sat, 16 Mar 2013, Mark Hills wrote:

> On Wed, 13 Mar 2013, Olivier Gauthier wrote:
> 
> > Hi everyone,
> > 
> > I wanted to complete this patch for me since a long time. I basically
> > changed constants ZERO_THRESHOLD and REF_PEAKS_AVG to variables inside
> > timecoder. I then made a dumb switch case to map values to a single
> > arbitrary gain value. For now my patch can map values 0 (no
> > amplification) to 6 (max amplification) following this translation
> > table. (if anyone sees a better math way of expressing my switch case,
> > please comment)
> > 
> > timecode_gain zero_threshold ref_peaks_avg
> > 0 	128 	48
> > 1	112	48
> > 2	96	40
> > 3	80	32
> > 4	64	24
> > 5	48	16
> > 6	32	8
> > 
> > I tested it, and my American Audio Versaport sound card worked better
> > with max amplification, gain 6. Similar to what I tested before.
> > 
> > Three questions for Mark (or anyone that knows better).
> > First does ref_peaks_avg needs to be a multiple of 8 ?
> 
> No, it doesn't.
> 
> > Does it needs to follow zero_threshold like I coded here?
> 
> It shouldn't do. And that's what I'm finding unusual about your patching 
> -- that you feel the need to change ref_peaks_avg. Did you find you need 
> to change ref_peaks_avg for it to work?
> 
> If so then it means that maybe you uncovered something quite incorrect in 
> the filtering.

Following up my own post, I think I uncovered something here. Thanks for 
putting me onto this.

The various noise-filtering parts work using integer values for efficiency 
-- tiny accuracy was never that important, until trying to use an 
unamplified signal.

When signal levels which are so low, the integer rounding causes noise 
this is why you find yourself having to fake the ref_peaks_avg -- change 
ref_level and zero to be double instead.

I'll give this a little thought. For efficiency I'd rather not move the 
decoder to floating point, but turning its inner workings from 16-bit to 
24-bit or even 31-bit integer might make sense.

It also looks like using 24-bit audio is going to make sense if you hope 
to use such a low and unamplified signal. This would require a major 
re-work; the internals of xwax's audio handling is currently implemented 
in 16-bit.

-- 
Mark

Re: [xwax-devel] Add timecode gain to command line options

[Olivier G. <ol...@os...>]

On 16/03/13 06:58 PM, Mark Hills wrote:
> On Sat, 16 Mar 2013, Mark Hills wrote:
> 
>> On Wed, 13 Mar 2013, Olivier Gauthier wrote:
>>
>>> Hi everyone,
>>>
>>> I wanted to complete this patch for me since a long time. I basically
>>> changed constants ZERO_THRESHOLD and REF_PEAKS_AVG to variables inside
>>> timecoder. I then made a dumb switch case to map values to a single
>>> arbitrary gain value. For now my patch can map values 0 (no
>>> amplification) to 6 (max amplification) following this translation
>>> table. (if anyone sees a better math way of expressing my switch case,
>>> please comment)
>>>
>>> timecode_gain zero_threshold ref_peaks_avg
>>> 0 	128 	48
>>> 1	112	48
>>> 2	96	40
>>> 3	80	32
>>> 4	64	24
>>> 5	48	16
>>> 6	32	8
>>>
>>> I tested it, and my American Audio Versaport sound card worked better
>>> with max amplification, gain 6. Similar to what I tested before.
>>>
>>> Three questions for Mark (or anyone that knows better).
>>> First does ref_peaks_avg needs to be a multiple of 8 ?
>>
>> No, it doesn't.
>>
>>> Does it needs to follow zero_threshold like I coded here?
>>
>> It shouldn't do. And that's what I'm finding unusual about your patching 
>> -- that you feel the need to change ref_peaks_avg. Did you find you need 
>> to change ref_peaks_avg for it to work?
No, I only based my code on findings that other people shared on the
mailing list about using maya44 sound card without preamp. It happens
that 32/8 does work for my sound card too. I was led to believe that
both variables needed to decrement together.
Thanks for the explanation here

>>
>> If so then it means that maybe you uncovered something quite incorrect in 
>> the filtering.
> 
> Following up my own post, I think I uncovered something here. Thanks for 
> putting me onto this.
> 
> The various noise-filtering parts work using integer values for efficiency 
> -- tiny accuracy was never that important, until trying to use an 
> unamplified signal.
> 
> When signal levels which are so low, the integer rounding causes noise 
> this is why you find yourself having to fake the ref_peaks_avg -- change 
> ref_level and zero to be double instead.
I'll try it out and see if I can feel a difference in the timecode.

> 
> I'll give this a little thought. For efficiency I'd rather not move the 
> decoder to floating point, but turning its inner workings from 16-bit to 
> 24-bit or even 31-bit integer might make sense.
> 
> It also looks like using 24-bit audio is going to make sense if you hope 
> to use such a low and unamplified signal. This would require a major 
> re-work; the internals of xwax's audio handling is currently implemented 
> in 16-bit.
> 

Re: [xwax-devel] Add timecode gain to command line options

[Mark H. <ma...@xw...>]

On Mon, 18 Mar 2013, Olivier Gauthier wrote:

> On 16/03/13 06:58 PM, Mark Hills wrote:
> > On Sat, 16 Mar 2013, Mark Hills wrote:
> > 
> >> On Wed, 13 Mar 2013, Olivier Gauthier wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I wanted to complete this patch for me since a long time. I 
> >>> basically changed constants ZERO_THRESHOLD and REF_PEAKS_AVG to 
> >>> variables inside timecoder. I then made a dumb switch case to map 
> >>> values to a single arbitrary gain value. For now my patch can map 
> >>> values 0 (no amplification) to 6 (max amplification) following this 
> >>> translation table. (if anyone sees a better math way of expressing 
> >>> my switch case, please comment)
> >>>
> >>> timecode_gain zero_threshold ref_peaks_avg
> >>> 0 	128 	48
> >>> 1	112	48
> >>> 2	96	40
> >>> 3	80	32
> >>> 4	64	24
> >>> 5	48	16
> >>> 6	32	8
> >>>
> >>> I tested it, and my American Audio Versaport sound card worked 
> >>> better with max amplification, gain 6. Similar to what I tested 
> >>> before.
> >>>
> >>> Three questions for Mark (or anyone that knows better). First does 
> >>> ref_peaks_avg needs to be a multiple of 8 ?
> >>
> >> No, it doesn't.
> >>
> >>> Does it needs to follow zero_threshold like I coded here?
> >>
> >> It shouldn't do. And that's what I'm finding unusual about your 
> >> patching -- that you feel the need to change ref_peaks_avg. Did you 
> >> find you need to change ref_peaks_avg for it to work?

> No, I only based my code on findings that other people shared on the 
> mailing list about using maya44 sound card without preamp. It happens 
> that 32/8 does work for my sound card too. I was led to believe that 
> both variables needed to decrement together. Thanks for the explanation 
> here
> 
> >>
> >> If so then it means that maybe you uncovered something quite 
> >> incorrect in the filtering.
> > 
> > Following up my own post, I think I uncovered something here. Thanks 
> > for putting me onto this.
> > 
> > The various noise-filtering parts work using integer values for 
> > efficiency -- tiny accuracy was never that important, until trying to 
> > use an unamplified signal.
> > 
> > When signal levels which are so low, the integer rounding causes noise 
> > this is why you find yourself having to fake the ref_peaks_avg -- 
> > change ref_level and zero to be double instead.

> I'll try it out and see if I can feel a difference in the timecode.

Thanks! Maybe I have something more interesting here.

If you check out the latest 'master' branch. I've converted it to use the 
full 32-bit signed range; no need for floating point anymore. Can you give 
it a test that I didn't break anything, and try changing ZERO_THRESHOLD 
too?

> > I'll give this a little thought. For efficiency I'd rather not move the 
> > decoder to floating point, but turning its inner workings from 16-bit to 
> > 24-bit or even 31-bit integer might make sense.
> > 
> > It also looks like using 24-bit audio is going to make sense if you hope 
> > to use such a low and unamplified signal. This would require a major 
> > re-work; the internals of xwax's audio handling is currently implemented 
> > in 16-bit.

Ok, I've been giving the above more thought.

To move to 24-bit audio just to amplify the quiet signals is wasteful in 
the other cases. Providing both 24-bit and 16-bit implementation in xwax 
is an annoyance.

So instead, here's an asoundrc recipe that applies a 'software preamp' on 
input only.

This way, at least for now, it's possible to process the audio before it 
gets read by xwax in 16-bit. And anyone not doing this doesn't get the 
overhead.

Maybe one day I'll put this in xwax so it's less wordy (anything using 
asoundrc is rarely fun), but for now it seems like something worth sharing 
and testing.

I might be going back on my idea to just change ZERO_THRESHOLD; it still 
serves some purpose to scale the values appropriately before the 
algorithm. Hmmm... :)

-- 
Mark


---
#
# asoundrc to apply a "software preamp"
#

pcm.deck0 {
	type asym
	playback.pcm deck0_playback
	capture.pcm deck0_timecode
}

pcm.deck0_timecode {
	type plug
	# Apply 36dB gain, roughly equivalent to line/phono level
	ttable.0.0 63.0
	ttable.1.1 63.0
	slave.pcm "hw:Audio8DJ,0,0"
}

pcm.deck0_playback {
	type plug
 	slave.pcm "hw:Audio8DJ,0,0"
}

Re: [xwax-devel] Add timecode gain to command line options

[Olivier G. <ol...@os...>]

On 18/03/13 07:12 PM, Mark Hills wrote:
> On Mon, 18 Mar 2013, Olivier Gauthier wrote:
> 
>> On 16/03/13 06:58 PM, Mark Hills wrote:
>>> On Sat, 16 Mar 2013, Mark Hills wrote:
>>>
>>>> On Wed, 13 Mar 2013, Olivier Gauthier wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I wanted to complete this patch for me since a long time. I 
>>>>> basically changed constants ZERO_THRESHOLD and REF_PEAKS_AVG to 
>>>>> variables inside timecoder. I then made a dumb switch case to map 
>>>>> values to a single arbitrary gain value. For now my patch can map 
>>>>> values 0 (no amplification) to 6 (max amplification) following this 
>>>>> translation table. (if anyone sees a better math way of expressing 
>>>>> my switch case, please comment)
>>>>>
>>>>> timecode_gain zero_threshold ref_peaks_avg
>>>>> 0 	128 	48
>>>>> 1	112	48
>>>>> 2	96	40
>>>>> 3	80	32
>>>>> 4	64	24
>>>>> 5	48	16
>>>>> 6	32	8
>>>>>
>>>>> I tested it, and my American Audio Versaport sound card worked 
>>>>> better with max amplification, gain 6. Similar to what I tested 
>>>>> before.
>>>>>
>>>>> Three questions for Mark (or anyone that knows better). First does 
>>>>> ref_peaks_avg needs to be a multiple of 8 ?
>>>>
>>>> No, it doesn't.
>>>>
>>>>> Does it needs to follow zero_threshold like I coded here?
>>>>
>>>> It shouldn't do. And that's what I'm finding unusual about your 
>>>> patching -- that you feel the need to change ref_peaks_avg. Did you 
>>>> find you need to change ref_peaks_avg for it to work?
> 
>> No, I only based my code on findings that other people shared on the 
>> mailing list about using maya44 sound card without preamp. It happens 
>> that 32/8 does work for my sound card too. I was led to believe that 
>> both variables needed to decrement together. Thanks for the explanation 
>> here
>>
>>>>
>>>> If so then it means that maybe you uncovered something quite 
>>>> incorrect in the filtering.
>>>
>>> Following up my own post, I think I uncovered something here. Thanks 
>>> for putting me onto this.
>>>
>>> The various noise-filtering parts work using integer values for 
>>> efficiency -- tiny accuracy was never that important, until trying to 
>>> use an unamplified signal.
>>>
>>> When signal levels which are so low, the integer rounding causes noise 
>>> this is why you find yourself having to fake the ref_peaks_avg -- 
>>> change ref_level and zero to be double instead.
> 
>> I'll try it out and see if I can feel a difference in the timecode.
> 
> Thanks! Maybe I have something more interesting here.
> 
> If you check out the latest 'master' branch. I've converted it to use the 
> full 32-bit signed range; no need for floating point anymore. Can you give 
> it a test that I didn't break anything, and try changing ZERO_THRESHOLD 
> too?
> 
>>> I'll give this a little thought. For efficiency I'd rather not move the 
>>> decoder to floating point, but turning its inner workings from 16-bit to 
>>> 24-bit or even 31-bit integer might make sense.
>>>
>>> It also looks like using 24-bit audio is going to make sense if you hope 
>>> to use such a low and unamplified signal. This would require a major 
>>> re-work; the internals of xwax's audio handling is currently implemented 
>>> in 16-bit.
> 
> Ok, I've been giving the above more thought.
> 
> To move to 24-bit audio just to amplify the quiet signals is wasteful in 
> the other cases. Providing both 24-bit and 16-bit implementation in xwax 
> is an annoyance.
> 
> So instead, here's an asoundrc recipe that applies a 'software preamp' on 
> input only.
> 
> This way, at least for now, it's possible to process the audio before it 
> gets read by xwax in 16-bit. And anyone not doing this doesn't get the 
> overhead.
> 
> Maybe one day I'll put this in xwax so it's less wordy (anything using 
> asoundrc is rarely fun), but for now it seems like something worth sharing 
> and testing.

Thanks Mark, from your example I managed to create a version of my
asoundrc that does the software preamp.

>From preliminary tests, I feel that the tracking is more stable than
using ZERO_THRESHOLD. The position number in xwax seems lit a bit more time.

I'll test it a more and update the wiki with my example.

> 
> I might be going back on my idea to just change ZERO_THRESHOLD; it still 
> serves some purpose to scale the values appropriately before the 
> algorithm. Hmmm... :)
>