Ehnahcements to the Audio API
Simpler to understand
- The interfaces are currently bloated, this makes knowing who the consumers of a particular function or variable are very difficult.
- The names of functions need to clearly identify not only what they do, but also what context they are to be called in
- The Codec and Audio thread should share zero state-modifying code. Any state modifying function that one calls should never be called on the other. -- Known problem areas:
- In the off chance that there is some data that must be modified by both threads, it must not be performance sensitive, and may be protected by a mutex
- Existing use of mutex's to protect functions can be eliminated to improve performance once the above is done.
The following apply only to performance sensitive sections of code.
- Functions should have specific behavior, rather than conditional branches.
- Some sacrifices to readability for performance is acceptable in these areas
- Keep register usage to a minimum (check in the asm how many registers the compiler is using)
Steps that I've so far taken are in CVS
- now behaves more like a typical buffer where consumers are told how much space is left if they reach the end
- now uses linked lists instead of circular buffer for the buffer descriptors
- performance sensitive code optimized by reading compiled code
- trimmed down the API exposed to consumers
- Reduced usage of pcm_ function calls outside of pcmbuf.c (this probably wants more doing)
- Reduce latency by only holding the currently playing chunk in PCM.c not the next one too
Not much done yet
Copyright © by the contributing authors.