Hey there,
I have a rather complicated design that uses, among other things, a comparison of LOG functions on L and R input audio, that is turned into a value used to scale the output audio on both channels.
The trouble is, when the two signals coming in are approaching a peak in the audio in the same direction at the same time, the numbers start to get smaller, and because the log approximation is only good to..I think it's 0.0125? increments, one of those values changes in quite a digital manner before the other, instead of a smooth increasing transition that would come if the log had more resolution.
The sum total of this is that the audio output that is being moderated by these numbers jumps up and down in 0.3dB increments in places where it should just be a smooth transition - this happens on the upper/lower ~10% for most if not all peaks, for anywhere between 1 and ~15 samples at 48Khz, and is then quite audibly present in the output audio as a pop/crackle distortion in the center of the stereo.
I considered using the reciprocal instead of log to create a divide function to achieve a similar result, but the reciprocal only works for values b/w 0.1 and 1, and seems to be quite useless for audio as a result.
I've verified that it's the low-precision logarithm that is responsible for my problem - I'm just wondering if anyone knows how to increase the resolution or create a more precise log function for the TAS3204.
I'm not an expert in DSP by a very far cry, but this is a strange one to me.
Cheers
David.
David,
I don't know the details about how your comparison works, but it is true that the precision of log() alog() in TAS3x is not in a great precision. The way I used to do before is to scale the input to log() to certain range so it would work at it's optimum. I know it's not easy to do norminalization in TAS3x, but it's doable.
Also regarding the reciprocal component, you also need to scale the input to be in the range to make it useful.
Susan
Hi Susan,
I can't normalise because I need to preserve the integrity of the original signal when I'm deriving the calculation I need.
And the reciprocal, same reason - the point of using logs was to reduce the input signal to a well-confined range, making it easier to compare regardless of the difference in relative amplitude - but still maintain the same relationship between the inputs.
Is there any way to manually perform a higher-precision log? Like I said, I don't know a great deal about the nuts and bolts of DSP.
I don't mind if it uses a few more cycles.
Sudden thought - does the log algorithm on the tas3204 do normalisation anyway, pre-calc?
No, it doesn't do normalization before hand when doing log. I understand that you need to preserve the original signal, the only way I can think of and I did before is shifting the signal and also preserve the shift factor and/or, also shift the other signal you want to compare with to the desired range, only for comparison purpose. I don't know the details of your operation, if you give me more details what you want to do, I can see whether I could be a little more helpful.
I am a little hesitant to reveal the exact nature of it, it's a company design, I'm not sure how detailed I can get.
Actually if you can think of a way to normalize in real time, that might work for what I'm trying to do.
Hey Susan,
Normalisation would be ok we've decided, just not sure how to go about it on the TAS3204 - do you have any suggestions / algorithms or components I can use to achieve this?
~David.
The other option is, what is a good way to way to relatively scale the audio to between 0.1 and 1 so that I can use the reciprocal function accurately.
Cheers once more
`David
I am sorry we don't any compoent that's doing this. I did something like that for a customer a while ago, when knowing the range of the input value, so we would know how many iterations of shift and compare would need. If you're talking about scaling one sample, then yes, we could do that with some cycle expanse, but to scale for a block of samples, it's really hard to do, though I wouldn't say impossible.
I was doing something like this:
when at the point of comparison, BR hold the value you want to scale, for example, you want to calculate, 1/val1, then val1 is in BR, and 1 would be val2, when you shift val1 to the range of 0.1~1, then val2 is shifted accordingly and you need to save it in every step, then use reciprocal function to calculate the ans = 1/val1_scaled, then multiply val2_scaled to get the result 1/val1 = val2_scaled * (1/val1_scaled).
First of all, we need to decide whether the signal is too big or too small, then decide to shift down or shift up, also, you could decide how many bits to shift in 1 iteration, 1 bit being the most precise of course, some in some situation, you could shift upto 4 bits at a time. depends on what you want to scale, how wide the number range is.
I've attached a sample code, I need to modify the code to fit your senario, so not sure it would compile, and also it's only part of the situation, need to add when signal is small as well
Hope this helps.