Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Optimisation of my audio player application (Mac)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
No replies to this topic

#1 aregee   Members   -  Reputation: 1037

Like
0Likes
Like

Posted 03 April 2014 - 09:12 PM

I am working on an audio player application for Mac, and have made a play routine for both wav and flac files from scratch, and will soon start working on a mp3 decoder too.  While this is working great, I am trying to squeeze as much fast response and performance as I can out of the application.

 

My goal is to make a super responsive audio player that later will be part of an (semi) automated audio transcription tool.

 

Now I am looking to optimise my audio player before I move on to add more functionality.

 

My first optimisation was a qualified guess:

 

I have a bit file reader that I have made, that I just threw together to be able to read a file on a number of bit basis.  This actually would just read one and one byte from the file and shift the data into the integer type I wanted, bit by bit.

 

The optimisation I did, was to create a double buffer and pre-read an amount of data to that buffer instead of requesting one and one byte from the file like I did in the version I just threw together.  The reason I made the buffer "double buffering" is that I thought that I would always have one buffer ready, and that I could increase responsiveness by reading data into the used buffer from another thread.  I am not sure if this really is a good idea, but I will test this later.  Now I just have prepared so it will be trivial to add this functionality.

 

This initial optimisation made the CPU usage drop from about 30% down to about 6%.  I'd say that is a good improvement.

 

Now I want to try to reduce the CPU Energy Impact to land in the "low" area instead of constantly "high".  I am wondering if this is at all possible in an application like this, where there are constant reads from disk and Audio Queues constantly requesting more data to play, and also graphics that is updated on regular basis.  (Probably not more than 4 times per second, but still...)

 

I also notice something called 'wakes' per second.  This number varies between 4 and 11, but is mostly residing at 4.  I don't really know what kind of an impact this has on my application, and I am not even sure I can avoid it to happen.  I am thinking that maybe I can reduce the wakes to happen in "bulk" somehow, but I need to learn more about this topic.  It is hard to find any good information on this.

 

I also wonder how you might go about trying to reduce the energy impact in such an application where you constantly stream audio from file to an audio device.

 

Lastly, a weird bug that I am not even sure what is caused by.  Sometimes I have a drop-out in the audio.  It is not a long dropout, and the progress bar is moving and it seems that the song is playing, but there is no sound for the short duration of the dropout.  The stream is not reporting any errors, and I have the same problem wether I play wav or flac.  Both play routines are written independently of each other and from scratch, and with TONS of sanity and error checking, and buffer overflow protection, that I would see if the play routines did something weird.  I am suspecting latency in the system, but I have no idea how to pursue that.  I was hoping that buffering the bit file reader would solve the problem, and sort of it did - the short drop-outs are a bit shorter now...  When the audio comes back, it indeed did play with no sound, since the song does not resume from where it stopped.  To combat this, I have tried to increase buffer sizes.  The dropouts are still of the same length.  It really seems to be relating to some issue with how the system either manages sleep on the hard drive OR how the system accumulates threading by delaying threads a little bit to reduce the energy impact.  Yes, OS X does this to some extent, but I don't know how to even start to debug this problem.

 

I have one idea I am planning to try, though...  To try to time different sections of the code to see if there is any major deviations when this happens.

 

I am happy for any feedback or suggestions.  Thank you! smile.png

 

 

EDIT 2014 06 10:

 

Instead of waking this old thread, I will just make an edit: 

 

I found a likely reason for why I am getting audio drop-outs.  It is called App Nap on OS X Mavericks.  It is not supposed to affect apps that is playing audio, but I see that it is an issue with Mavericks:

 

http://smallthingsfloat.com/2013/11/09/airfoil-cutting-out-on-os-x-mavericks/

 

I also see similar behaviour in other apps that I never had problems with before Mavericks.


Edited by aregee, 10 June 2014 - 04:19 PM.


Sponsor:



Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS