CODE
float *samples = (float *)malloc(chunk.samples*chunk.nch*sizeof(float));
double *psample = chunk.data;
for (int i=0;i<chunk.samples*chunk.nch;i++) {
samples[i] = (float)*psample++;
}
free(samples);
thanks for any help..
oddsock
Full Version: doubles/floats and dsps
just started checking out .6 and noticed that apparently I am no longer getting floats in my dsp chunks, but rather 64 bit doubles....so I've tried to simply convert these to what I am expecting, which is an array of floats...but clearly something is wrong with my code....anyone know what's wrong ? (I am basically getting silence in samples - which means that all my samples[] are most likely 0)..
float *samples = (float *)malloc(chunk.samples*chunk.nch*sizeof(float));
double *psample = chunk.data;
for (int i=0;i<chunk.samples*chunk.nch;i++) {
samples[i] = (float)*psample++;
}
free(samples);
thanks for any help..
oddsock
float *samples = (float *)malloc(chunk.samples*chunk.nch*sizeof(float));
double *psample = chunk.data;
for (int i=0;i<chunk.samples*chunk.nch;i++) {
samples[i] = (float)*psample++;
}
free(samples);
thanks for any help..
oddsock
Well, the first thing is that you shouldn't convert them to 32-bit floats. That defeats the entire point of switching to 64-bit. 
But I think the reason that your conversion isn't working is because you're casting the doubles as floats. I would assume that this would involve truncation (though I'm not an expert in this area), and possibly significant data loss. If you want to test to see if this is the case, try a double-cast. Cast to int, and then to float, and see if you're still getting silence in the samples. If so, ignore this entire paragraph.
But I think the reason that your conversion isn't working is because you're casting the doubles as floats. I would assume that this would involve truncation (though I'm not an expert in this area
), and possibly significant data loss. If you want to test to see if this is the case, try a double-cast. Cast to int, and then to float, and see if you're still getting silence in the samples. If so, ignore this entire paragraph.
QUOTE(oddsock @ Apr 27 2003 - 08:01 AM)
CODE
float *samples = (float *)malloc(chunk.samples*chunk.nch*sizeof(float));
double *psample = chunk.data;
for (int i=0;i<chunk.samples*chunk.nch;i++) {
samples[i] = (float)*psample++;
}
free(samples);
Does the pointer increment not run amok with the cast? (I don't think it should, but it won't hurt checking)
hrm...
well after playing around some, I found that the following ends up solving my problem :
float *samples = (float *)malloc(chunk.samples*chunk.nch*sizeof(float));
double *psample = chunk.data;
for (int i=0;i<chunk.samples*chunk.nch;i++) {
double sample = *psample++;
samples[i] = (sample*100);
}
if (samples) {
free(samples);
}
basically, if I multiple the sample by 100, I get the desired value (and sound is fine and clear)...so the question is, what exactly is this doing ? (besides simply multiplying the value).
and the reason why I am doing this (converting from doubles to floats) is that the DSP that I am writing is a streaming encoder, and I am basically sending these samples to both LAME, Vorbis, and Windows Media.. LAME and WMA take in int samples, and vorbis takes in float samples, so I am keeping at least the float granularity, (and in the case of LAME and WMA converting from float to int samples)....I don't know of any encoder (used for streaming) that uses 64 bit samples...so I'm left to convert....which leads to another question I guess..is my assumption that I'm doing the right thing here correct ? All my resampling logic also deals with floats, and any other possible manipulation I do to the raw samples are done in float form, and then when the data is sent to LAME/WMA/Vorbis it is either converted to int samples, or left as float. I'd hate to think I am introducing artifacts into the stream as a result of the way I'm doing these conversions..
thanks for any help..
oddsock
update:
ok, so I'm an idiot, and had the "Attenuator" in the DSP before my DSP, which was making the samples very very quiet, (and seemingly 0) so my original code actually does work when I take the attenuator out of the DSP path...so I guess all is good now...
well after playing around some, I found that the following ends up solving my problem :
CODE
float *samples = (float *)malloc(chunk.samples*chunk.nch*sizeof(float));
double *psample = chunk.data;
for (int i=0;i<chunk.samples*chunk.nch;i++) {
double sample = *psample++;
samples[i] = (sample*100);
}
if (samples) {
free(samples);
}
basically, if I multiple the sample by 100, I get the desired value (and sound is fine and clear)...so the question is, what exactly is this doing ? (besides simply multiplying the value).
and the reason why I am doing this (converting from doubles to floats) is that the DSP that I am writing is a streaming encoder, and I am basically sending these samples to both LAME, Vorbis, and Windows Media.. LAME and WMA take in int samples, and vorbis takes in float samples, so I am keeping at least the float granularity, (and in the case of LAME and WMA converting from float to int samples)....I don't know of any encoder (used for streaming) that uses 64 bit samples...so I'm left to convert....which leads to another question I guess..is my assumption that I'm doing the right thing here correct ? All my resampling logic also deals with floats, and any other possible manipulation I do to the raw samples are done in float form, and then when the data is sent to LAME/WMA/Vorbis it is either converted to int samples, or left as float. I'd hate to think I am introducing artifacts into the stream as a result of the way I'm doing these conversions..
thanks for any help..
oddsock
update:
ok, so I'm an idiot, and had the "Attenuator" in the DSP before my DSP, which was making the samples very very quiet, (and seemingly 0) so my original code actually does work when I take the attenuator out of the DSP path...so I guess all is good now...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.