After considerable testing and bugfixing, I have finally finished converting from using file pointers to file descriptors. Unfortunately, the change most likely breaks compilation on windows, but parallel I/O is likely not going to work in windows anyway so all I need to do is write another wrapper function.
I've spent the last day or so testing the new code and so far everything seems to work properly. During the conversion I also located several odd edge-case bugs and fixed them. eg: if opening the output wav file succeeds but writing the RIFF headers to it fails, the program will continue trying to encode anyway.
The next commit or two will likely be cleaning up what I've changed a bit, then I will get back to the restructure, which is now ahead of schedule!
Tuesday, February 26, 2013
Wednesday, February 20, 2013
Further I/O issues
As part of changing how file I/O is handled, it turns out I also need to convert from file pointers to file descriptors. Unfortunately, all of the RIFF validation code is dependent on using file pointers. I have successfully converted the rest of the code to use file descriptors, but I wont commit it until i have the basic RIFF things working again. As it stands, the code will compile but segfaults upon trying to read the RIFF data. (I used fdopen to try to get around the issue, but this has been highly unsuccessful.)
Tuesday, February 12, 2013
I/O issues
I've been doing a lot of work learning how boost::thread works and have started changing things around to allow for threading in general. Unfortunately, in order to read data in anything resembling parallel, I need to change how files are opened entirely, which is posing a slight problem. Currently I have separated the parts that can be executed in parallel from the normal encode and decode functions and started the process of changing how all file I/O is handled.
Tuesday, February 5, 2013
And We're Back
After a while of letting the project sit, I have returned to it to thread the program as much as possible. This will speed up the already incredibly fast program, however its full benefit will be felt when the algorithm for better data hiding is fully implemented. In these cases, the run time will be longer due to processing, which threading will assist in reducing.
Subscribe to:
Posts (Atom)