what is better? Synch, Overlapped or MM I/O? (Win32)
Author
as the title suggests, I don't know wich API to use for reading and writing data to files. I think there are only three ways:
- Synchronous File I/O
- Overlapped (asynchronous) File I/O
- Multimedia File I/O
I have to read and write very large data form and to many files in the less possible time. I must have the better possible performance. What do you think I should do?
Quote:Original post by ZeroMemoryWhat sort of data are you reading? Do you need random access or just sequential? Do you really need to have lots of files? The biggest overhead is likely to be opening the files.
as the title suggests, I don't know wich API to use for reading and writing data to files. I think there are only three ways:
- Synchronous File I/O
- Overlapped (asynchronous) File I/O
- Multimedia File I/O
I have to read and write very large data form and to many files in the less possible time. I must have the better possible performance. What do you think I should do?
Overlapped IO is probably going to be the fastest, but it depends on your exact requirements.
Author
I need random access. I'll open the files first, then I will have to stream data from files, and stream other data to files.
What I have to do is to mix many audio files (uncompressed) and record incoming audio data to other files at the same time (and in real time).
What I have to do is to mix many audio files (uncompressed) and record incoming audio data to other files at the same time (and in real time).
Quote:Original post by ZeroMemoryIf you're streaming data in, that's not random access.
I need random access. I'll open the files first, then I will have to stream data from files, and stream other data to files.
What I have to do is to mix many audio files (uncompressed) and record incoming audio data to other files at the same time (and in real time).
Will you be opening and closing the files frequently? If not, then normal synchronous file I/O in a thread is probably your best option. I'd be in inclined to go for that option and then see if there are any performance problems.
Author
I use random access because I'm not going to read the entire audio chunk of WAV files in one time, but I'm going to read it a bit at a time (say 1MB at a time) when the playng buffer (a circular buffer) is about to reach the end.
I have no problem to use separate threads that use Synchronous I/O (also because this link http://blogs.msdn.com/khen1234/archive/2005/04/25/411852.aspx says that overlapped I/O sometimes can block the calling thread! ...it would be dangerous)
Anyway...I'd have another question: What if I use Multimedia File I/O? the Platform SDK says that it has better performance over standard Win32 APIs like ReadFile() and WriteFile().
Thanks!
I have no problem to use separate threads that use Synchronous I/O (also because this link http://blogs.msdn.com/khen1234/archive/2005/04/25/411852.aspx says that overlapped I/O sometimes can block the calling thread! ...it would be dangerous)
Anyway...I'd have another question: What if I use Multimedia File I/O? the Platform SDK says that it has better performance over standard Win32 APIs like ReadFile() and WriteFile().
Thanks!
You are using sequential access not random.
Uf you have array of chars ABCDEFGHIJ... then "reading" chars from this array sequentially means CDEFGH... But random access means CHJCEIBAJH...
Uf you have array of chars ABCDEFGHIJ... then "reading" chars from this array sequentially means CDEFGH... But random access means CHJCEIBAJH...
Quote:Original post by ZeroMemory
I use random access because I'm not going to read the entire audio chunk of WAV files in one time, but I'm going to read it a bit at a time (say 1MB at a time) when the playng buffer (a circular buffer) is about to reach the end.
That's still not random access. Random access means to be able to access arbitrary places in the file, as opposed to just reading more and more at 'random' points, which is just typical sequential access.
Quote:I have no problem to use separate threads that use Synchronous I/O (also because this link http://blogs.msdn.com/khen1234/archive/2005/04/25/411852.aspx says that overlapped I/O sometimes can block the calling thread! ...it would be dangerous)
One thread per file doesn't scale very far. If this is for a typical sequencer and you have 5 to 20 audio tracks, it might be ok, but I think an event driven model would work better.
Quote:the Platform SDK says that it has better performance over standard Win32 APIs like ReadFile() and WriteFile().
'Performance' is vague - in particular, you need to distinguish between latency and bandwidth. Many high performance apps buy you bandwidth at the cost of latency, and that might not be acceptable if you're doing real-time mixing. If you're just recording to disk, that's fine, but if you're doing playback and echoing the data to the listener, noticeable latency may be a real problem.
Author
Quote:Original post by bubu LV
You are using sequential access not random.
Uf you have array of chars ABCDEFGHIJ... then "reading" chars from this array sequentially means CDEFGH... But random access means CHJCEIBAJH...
sorry...I didn't know that!
Quote:Original post by Kylotan LV
'Performance' is vague - in particular, you need to distinguish between latency and bandwidth. Many high performance apps buy you bandwidth at the cost of latency, and that might not be acceptable if you're doing real-time mixing. If you're just recording to disk, that's fine, but if you're doing playback and echoing the data to the listener, noticeable latency may be a real problem.
yes...I need low latency when accessing files on disk because if it takes too much it can happen that I fill the playng buffer too late and so I get gaps in the audio. ...but what do you mean for bandwidth?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
