Page 1 of 1

PostPosted: Thu Jan 18, 2001 11:07 pm
by wittchow
is it possible to write an array of chars (holding numbers rather than characters) to a file with the filewrite() or writechars() function, just like it can be done with strings?
for now i am using a loop of many thousands of single writechar() commands which is a painfully slow way to write a wave file.

alternatively some array-of-chars-to-string-function like java's chars = string.toCharArray() / string = new string(chars) would just as helpful.

thank you


PostPosted: Fri Jan 19, 2001 7:08 am
by Justinespinosa
Just open your file in unicode mode, and use filewrite(string, strlen(string*2)) to write 16-bit chars in a file.


OUTS Softwares

PostPosted: Fri Jan 19, 2001 12:49 pm
by wittchow
thank you for the quick reply.

writing strings works fine, yes. but what i want to write is an array which isn't the same as a string in pocket c (allthough a string is some sort of array i guess).

for example i have an array that holds my calculated 0.1 sec wave form:
char wave[4410];
i use chars rather than ints because the wav file to write to is 16-bit.
to write this array to a file the filewrite() and writechars() functions don't work because they expect a string as parameter.

the only way it works yet is a loop:

for (i=0; i!=4410; i++)

PostPosted: Fri Jan 19, 2001 3:46 pm
by wolfgang

here's another idea:
Instead of storing all your wave data in char-values, store four of them in one int. Then you can write the data using writeint, which is roughly four times as fast as using four single writechar's. I know what I am talking about because I had the same problem with writing wav data. The tradeoff is that while file handling gets much faster, the other wave data processing slows down a bit because you always have to extract the single samples from the int's


to retrieve the two 16-bit samples contained in an int:

sample1 = intsamples & 0x0000ffff;
sample2 = (intsamples & 0xffff0000) >> 16;

to write the two samples into the int:

intsamples = (intsamples & 0xffff0000) | sample1;
intsamples = (intsamples & 0x0000ffff) | sample2;


To my experience though, this slowdown is much less than what you gain with the file write.

Another idea could be to use 8-bit samples instead of 16-bit if you can live with the reduced sound quality; that way you have only half the amount of data to transfer. Also, use a lower sampling rate, this again buys you a lot of speed, especially if combined with 8-bit samples. 21ksamples/sec/8bit, storing them in int's instead of char's will improve the time to save it by a factor of 16! (factor 2 for 8 bit vs. 16 bit, factor 4 for writeint vs. 4*writechar, factor 2 for 21 ksamples vs. 42 ksamples); and 22 ksamples is still by far good enough for the tiny low-quality speaker of most handhelds...

A word of caution: I don't know how (in which byte order) PocketC stores int values, MSB first or LSB first, and if this changes for different processor types. You will have to find out with some experiments to make sure the bytes get written in the order you want.

Finally, I would NOT advise to store the data in a string. Processing the gets REALLY slow...


Edited by - wolfgang on 01/20/2001 15:05:44

PostPosted: Sun Jan 21, 2001 3:09 pm
by darwin
I haven't tested it yet, if it is fast enough - but have you ever tried to work with direct file access instead of using variables?
In that case, you would also need less memory because (has it been changed/fixed - tried this last time with 2.x?) char needs as much as the in variable.
If you save 4 values in one int you need bitwise operating, what would need some calculation time, too.
You should decide this yourself, but I think that direct file access is more compfortable (justine thinks not...).


PostPosted: Mon Jan 22, 2001 12:43 am
by wittchow
thank you very much for the suggestions.

strings are fine as long as you don't have to make wave calculations. for example i am now working on a ringing melody editor for mobile phones:
all possible tunes, say one octave, are stored in a 16-bit mono wav and read to an array of strings at startup:

string tone[12];

for(i=0; i!=12; i++)
tone[i]=fileread(fp, 88200);

// each tone is 1 sec at 44 khz, 16 bit = 88200 bytes

the melody data to edit are held in an array int melody[20]. when you click the "calculate" button, a new wav file is assembled from the tone strings, according to the melody data:

for(i=0; i!=20; i++)
filewrite(result, tone[melody [i]], 88200);

wave(result_path, 1);

the result starts playing almost in the same moment, no delay at all.

the active x file controls hopefully will be available in the next version of the device edition - maybe this will solve the problem. i think there is a function within the file package that does just what i have in mind - write an array to a file in almost no time.

anything slower is not acceptable beacause wave calculations themselves yet take almost as long as playback.

and yes, it must be 16 bit stereo - i want to plug the pocket pc to my hifi system :-)