Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/rockbox.org/flyspray/adodb/adodb.inc.php on line 845 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.user.php on line 111 FS#7138 : New AudioAPI

Rockbox

Tasklist

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
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No
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.
Comment by Christian Gmeiner (ChristianGmeiner) - Wednesday, 09 May 2007, 19:14 GMT
upps.. forgot to add audiohw.h
   audio_api_first_impression_fo... (43.4 KiB)
Comment by Jonathan Gordon (jdgordon) - Thursday, 10 May 2007, 01:29 GMT
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?
Comment by Christian Gmeiner (ChristianGmeiner) - Thursday, 10 May 2007, 06:04 GMT
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.
Comment by Christian Gmeiner (ChristianGmeiner) - Thursday, 10 May 2007, 15:57 GMT
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
Comment by David Maliniak (major_works) - Monday, 14 May 2007, 15:06 GMT
This patch seems to be out of sync with SVN as a result of revision 13378.
Comment by Christian Gmeiner (ChristianGmeiner) - Wednesday, 16 May 2007, 17:47 GMT
Okay.. here is a new version of the patch. Changes:

* sim is working too
* improved api
(application/octet-stream)    audio_api_v_0.2_only_for_sans... (48.6 KiB)
Comment by Christian Gmeiner (ChristianGmeiner) - Monday, 21 May 2007, 00:11 GMT
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)
Comment by Christian Gmeiner (ChristianGmeiner) - Monday, 21 May 2007, 00:20 GMT
upps.. audiohw.h was missing
   audioApi_part1_rework_audio_s... (21.8 KiB)
Comment by Jonathan Gordon (jdgordon) - Monday, 21 May 2007, 02:33 GMT
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?
Comment by Christian Gmeiner (ChristianGmeiner) - Monday, 21 May 2007, 07:45 GMT
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).
Comment by Michael Sevakis (MikeS) - Monday, 21 May 2007, 08:05 GMT
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.
Comment by Christian Gmeiner (ChristianGmeiner) - Tuesday, 22 May 2007, 07:12 GMT
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)
Comment by Michael Sevakis (MikeS) - Tuesday, 22 May 2007, 07:39 GMT
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.
Comment by Christian Gmeiner (ChristianGmeiner) - Tuesday, 22 May 2007, 08:20 GMT
MikeS: Thanks for your comment :) I will take it in account, if I am after part 5/6.
Comment by David Maliniak (major_works) - Tuesday, 22 May 2007, 17:54 GMT
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
Comment by Nikkhil (AceNik) - Sunday, 23 December 2007, 20:53 GMT
is this gonna get restarted somehow?
Comment by Christian Gmeiner (ChristianGmeiner) - Tuesday, 22 April 2008, 08:06 GMT
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)
Comment by Christian Gmeiner (ChristianGmeiner) - Tuesday, 22 April 2008, 13:28 GMT
some small typo fixes
   mas35xx_set_channels_set_ster... (8 KiB)
Comment by Christian Gmeiner (ChristianGmeiner) - Sunday, 27 April 2008, 16:07 GMT
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)
Comment by Christian Gmeiner (ChristianGmeiner) - Sunday, 27 April 2008, 16:28 GMT
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
Comment by Christian Gmeiner (ChristianGmeiner) - Thursday, 08 May 2008, 22:19 GMT
This patch cleans up sound_set_balance and sound_set_volume by introducing CLIPPING_CAP.
   add_clipping_cap_and_move_cod... (5.1 KiB)

Loading...