2

I'm working on audio processing app for android and created a class for reversing WAV files. Everything works great on Java SE on my PC. However, the code is very slow on android "due to continuous reading of small amount of data and writing it, about 2 bytes usually".

The process is taking almost forever to deliver that I actually believe uploading the files to a server to handle may be a very much more effective way. I've tried using channels, file maps and buffered I/O. All ended in very poor performance.

The logic I'm using now:

  1. read first 44 bytes and write them to a new file "reverse file".
  2. calculate the block size to be moved "number of bytes per sample * number of channels"
  3. read that amount of data from the end of the first file and write it to the reverse file "also I tried writing to a buffer and when it is full write to reverse file" .

Any ideas how to improve the performance? Should I give up on my current approach?

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Mr.Me
  • 9,192
  • 5
  • 39
  • 51
  • 1
    You're only reading 4 bytes at a time for a 16-bit stereo PCM file? Maybe you could increase that a bit (to say, a few kB). And perhaps add some sort of double-buffering so you can have another thread processing one buffer while the other thread read more data into another buffer. – Michael Jul 16 '12 at 22:05
  • if I increase this value the output will not be a mirror of the input file "any audio analysis tool can easily show that". The idea of double buffers maybe useful though , I will try it – Mr.Me Jul 16 '12 at 22:08
  • Maybe you should fall back to C? –  Jul 16 '12 at 22:10
  • I'd vote against C, as we are targeting android and the problem sounds like it can be solved in Java efficiently (when avoiding object orientation with its overhead).Source code of relevant parts, maybe? – amon Jul 16 '12 at 22:15
  • 3
    Why would it not still be a mirror of the input if you increase the buffer size? You can reverse N+1 samples just as easy as you could N samples. – Michael Jul 16 '12 at 22:18
  • The buffer approach should be as fast as it can get, because you handle the operation in memory. The real bottleneck is usually file I/O. You can limit that by loading larger chunks from the file at a time, which I guess you already did. Could you please give some figures to illustrate your problem? Like file sizes and the time it takes for reversing, and also the device you are testing on. Posting your current algorithm would also help. – tiguchi Jul 16 '12 at 22:50
  • I noticed you said you're reading the first 44 bytes. Beware that not all .wav files metadata data end at index = 43. Some can end later, especially if you have "LIST" instead of "data" starting at index = 36. Have a look at GetDataStartIndex() in https://github.com/DavidKlempfner/WaveFileManipulator/blob/master/WaveFileManipulator/Metadata.cs – David Klempfner Apr 19 '20 at 01:45

0 Answers0