FS#7138 - New AudioAPI
Attached to Project:
Rockbox
Opened by Christian Gmeiner (ChristianGmeiner) - Wednesday, 09 May 2007, 18:01 GMT
Last edited by Thomas Martitz (kugel.) - Sunday, 05 June 2011, 11:31 GMT
Opened by Christian Gmeiner (ChristianGmeiner) - Wednesday, 09 May 2007, 18:01 GMT
Last edited by Thomas Martitz (kugel.) - Sunday, 05 June 2011, 11:31 GMT
|
DetailsFor more details have a look at http://www.rockbox.org/twiki/bin/view/Main/AudioHardwareAPIProposal
|
This task depends upon
Closed by Thomas Martitz (kugel.)
Sunday, 05 June 2011, 11:31 GMT
Reason for closing: Out of Date
Additional comments about closing: There doesn't seem to be interest in this anymore. Open a new task if this is wrong.
Sunday, 05 June 2011, 11:31 GMT
Reason for closing: Out of Date
Additional comments about closing: There doesn't seem to be interest in this anymore. Open a new task if this is wrong.
It might be an idea to add REC_SOURCE_COUNT to the end of RecSource enum for later...
and shuoldnt the functions with comments like /* #define AUDIOHW_HAVE_BASS */ in audiohw.h be #ifdef'ed?
/* All usable functions exported by a audio codec driver. Most of
* the function in sound settings are only called, when in audio codecs
* .h file suitable defines are added.
*/
extern void audiohw_init(void);
...
On recording and fixing simulator I will work today.
"It might be an idea to add REC_SOURCE_COUNT to the end of RecSource enum for later..."
Got simulator working with new api... also recording part should be ready.
Now I only need to get
a) ifdef hacks ready to use the old stuff on pure hardware devices
or
b) write an audio driver - like as3517 - for pure hardware devices
* sim is working too
* improved api
after this first bit is in, does all the audio drivers need to be converted in one hit? or can they be done one at a time?
Roadmap:
* part1: put audio_settings into audio driver
* part2: implement bass, treble into api and drivers
* part3: rework volume, balance and mute
* part4: rework channel and stereo_width
* part5: put HW_SAMPR_CAPS and REC_SAMPR_CAPS directly into drivers
* part6: make init, shutdown and post_init unique
At this point we should have - mas35xx driver ready - a very cleaned up sound.c
At this point I will look into recroding api part or in support for output destionations (headphones, lineout, spdif).
EDIT: You'll also break all the recording and samplerate switching definitions that are built around it. Seems I beat you to it by adding more cap mask definitions for the inputs. ;) Output could be masked in a similar way. Input need not imply recordable in this scheme just as the samplrate caps for playback don't imply those for recording - the UDA1380 based devices being an example of that.
Please review it.. I want to commit it today or tomorrow.
@MikeS: I will not include HW_SAMPR_CAPS and REC_SAMPR_CAPS to the driver, but i like the bitmask idea :)
I get errors when applying the patch in sound.h, and compile errors in sound.c
give me feedback and I hope some can this test on real hardware too, even this patch should not break anything.
If there are no problems with it, I will commit this first part soon.
This time with focus on bass and treble... this means that mas35xx gets functions to control bass and treble
and AUDIOHW_CAPS are introduced to make life easier.
the patch introduces AUDIOHW_CAPS which are used to get known what the audio codec can do in hardware, e.g. set bass. Now audiohw.h converts this CAPS into defines. These defines will be used in sound.c to see if we must use dsp to change e.g bass or if we can do it in hardware. This patch also moves mas35xx specific code for bass und treble into /firmware/drivers/audio/mas35xx.c and it fixes an probelm with
wm8751 that we can use current_xxx * 10 in sound.c for every target