Rockbox

upps.. forgot to add audiohw.h

   audio_api_first_impression_fo... (43.4 KiB)

Looks good, just 2 minor things…

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?

Fine… for the #ifdef stuff, go ups some lines and you will see this:

/* 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.

What do you mean with this?
"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

This patch seems to be out of sync with SVN as a result of revision 13378.

Okay.. here is a new version of the patch. Changes:

* sim is working too
* improved api

   audio_api_v_0.2_only_for_sans... (48.6 KiB)

Okay… as I want to get this big baby into svn I will do it in small ant atomic changes. The first part reworks the way how we configure audio settings. Every audio codec driver must define the values by itself. Please test it on every platform you have access to and tell me about any problems/ideas.

   audioApi_part1_rework_audio_s... (19.5 KiB)

upps.. audiohw.h was missing

   audioApi_part1_rework_audio_s... (21.8 KiB)

doing it in little part is definatly the way to go.

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?

There is no need to convert all drivers in one go, because we will have some mas35xx stuff in sound.c until I or somebody else puts the stuff into an own impl of the audiohw part. Also I want to do it small atomic changes

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).

HW_SAMPR_CAPS and REC_SAMPR_CAPS should not go into drivers as they define other critical information later about which parts of the source are compiled. Audio drivers themselves also do not determine which samplerates are available. This is a complex combination of the audio codec chip, CPU capabilities and crystal frequencies available and is specific to the hardware combination that makes up the device. Another noteable feature is the bitmask approach alleviates the need for a long list of #defines right in the config header - consolidating related capabilities.

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.

This is an updated patch, which includes a mas35xx driver, which is very very very basic.. only audio settings at the moment. I have tested this patch an - hopefully - all targets (only compile).
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 :)

   audioApi_part1_rework_audio_s... (25.7 KiB)

There's another issue that should be taken care of as the way things are now was just for lack of a better place to put rec_set_source. This really should be "audio_set_source" and should have no particular association with recording only. The "audio_set_source" in the target tree is really intended as an abstraction for setting up audio paths in the hardware at the lowest level. "rec_set_source" is intended as a layer that can access app level and power up/down the source devices as needed. I vote for the addition of "audio.c" as app level; the functions implemented there as midlevel audio API, moving "rec_set_source" into that as "audio_set_source" and renaming the "/target/…/audio-xx.c" "audio_set_source" to "hw_audio_set_source" or the like. It could be firmware layer if the upper tuner layer control functions are moved to firmware level and actually that's what would really smooth things out.

MikeS: Thanks for your comment :) I will take it in account, if I am after part 5/6.

Something has broken this patch, and it probably has to do with http://svn.rockbox.org/viewvc.cgi/trunk/firmware/export/sound.h?r1=13463&r2=13464

I get errors when applying the patch in sound.h, and compile errors in sound.c

is this gonna get restarted somehow?

My interest in this topic is back and I have done a small patch to add some functionality to mas35xx.c audio driver. Please
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.

   mas35xx_set_channels_set_ster... (7.9 KiB)

some small typo fixes

   mas35xx_set_channels_set_ster... (8 KiB)

And here is an other patch :)
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.

   audiohw_api_bass_and_treble.p... (8.5 KiB)

Description for patch above:
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

This patch cleans up sound_set_balance and sound_set_volume by introducing CLIPPING_CAP.

   add_clipping_cap_and_move_cod... (5.1 KiB)