1. It's code in the HAL. The HAL code figures out what the use case is,
constructs the corresponding mixer path string, then uses mixer_paths.xml
to apply the right settings corresponding to that path.
See also audio_policy.conf, but it's not directly related to this.
2. I'm not aware of such a restriction.
3. That's the hardware volume, which is mostly unused currently.
AudioFlinger applies a software attenuation instead.
On Tuesday, January 29, 2013 1:26:40 AM UTC-8, ffxx68 wrote:
>
> I think I'm starting to figuring out what to fix. My ALC5621 kernel driver
> includes these control definitions:
>
> static struct snd_kcontrol_new emxx_codec_controls[] = {
> EMXX_CODEC_INTEGER("DAC Volume", 0, MIXER_VOL_DAC),
> EMXX_CODEC_INTEGER("Headphone Volume", 0, MIXER_VOL_HP),
> EMXX_CODEC_INTEGER("Speaker Volume", 0, MIXER_VOL_SPK),
> EMXX_CODEC_INTEGER("MIC1 Volume", 0, MIXER_VOL_MIC1),
> EMXX_CODEC_INTEGER("MIC2 Volume", 0, MIXER_VOL_MIC2),
> EMXX_CODEC_INTEGER("AUXIN Volume", 0, MIXER_VOL_AUXIN),
> EMXX_CODEC_INTEGER("AUXOUT Volume", 0, MIXER_VOL_AUXOUT),
> EMXX_CODEC_ENUM("Capture Switch", 0, MIXER_SW_CAPTURE),
> EMXX_CODEC_ENUM("Sampling Rate Switch", 0, MIXER_SW_SAMPLING_RATE),
> EMXX_CODEC_ENUM("Playback Switch", 0, MIXER_SW_PLAYBACK),
> EMXX_CODEC_BOOLEAN("CODEC Power Switch", 0, MIXER_SW_CODEC_POWER_BL),
> };
>
> ("snd_kcontrol_new" is a standard structure, used by grouper rt5640 as
> well).
>
> Values are selected from these sets, respectively:
>
> "Playback Switch" -> "OFF", "Speaker_normal", "Speaker_ringtone",
> "Speaker_incall", "Earpiece_ringtone", "Earpiece_incall", "Headset_normal",
> "Headset_ringtone", "Headset_incall"
> "Capture Switch" -> "OFF", "MIC_normal", "MIC_ringtone", "MIC_incall",
> "Headset_normal", "Headset_ringtone", "Headset_incall"
> "Sampling Rate Switch" -> "7.35kHz", "8kHz", "11.025kHz", "12kHz",
> "14.7kHz", "16kHz", "22.05kHz", "24kHz", "29.4kHz", "32kHz", "44.1kHz",
> "48kHz"
> "CODEC Power Switch" -> 0, 1
>
> I'm now going to map these in mixer_paths.xml.
>
> A few question though:
>
> 1) how is a given routing selected, out of those defined in
> mixer_paths.xml?
> 2) Is it true (as I read somewhere) that tinyalsa supports a 44.1KHz
> sampling rate only?
> 3) why in grouper hw_audio.c the volume-setting functions are empty? How's
> volume set?
>
> static int out_set_volume(struct audio_stream_out *stream, float left,
> float right)
> {
> return -ENOSYS;
> }
>
>
>
>
>
>
>
> On Monday, 28 January 2013 17:23:33 UTC+1, ffxx68 wrote:
>>
>> Hi Glenn, thanks a lot for answering.
>>
>> I hope you don't mind if I ask you to guide me through these steps. I
>> have both the kernel driver code, the datasheet and device schematics, so I
>> have all's required to complete this... I think. Except experience :)
>>
>> For example, I've posted the device control names already, from kernel
>> driver.
>> There's no external DSP, as the audio section is relatively simple and
>> designed around a Realtek ALC5621 chip.
>> About control values. I've got the ALC5621 datasheet, but I miss where to
>> define those values in our code. If you could provide how that works for
>> the grouper' example, for just one control, I could try to map to my device
>> and eventually extend to all controls.
>>
>> On Thursday, 8 November 2012 14:42:21 UTC+1, ffxx68 wrote:
>>>
>>> Hi
>>>
>>> I'm trying to port a ICS implementation of ALSA audio to JB, or a tablet
>>> device, under this project:
>>>
>>> Mainly, I have the following to integrate (which I have the patch for
>>> ICS):
>>>
>>> external/alsa-lib
>>> hardware/alsa_sound
>>>
>>> plus some other smaller fix around, but I want to understand first of
>>> all what to do with these two first.
>>>
>>> For example, I have the some files with the same names in both
>>> hardware/alsa_sound and hardware/libhardware_legacy/
>>> audio (from AOSP), but their content is very different in the two
>>> locations.
>>>
>>> If I keep the ones from hardware/alsa_sound, build fails.
>>> If I copy them from hardware/libhardware_legacy/audio to
>>> hardware/alsa_sound, I can build but I get a crash during boot.
>>>
>>> Which one should I keep and compile?
>>> Once compiled, which libraries should I use from alsa_sound or
>>> libhardware_legacy/audio?
>>>
>>> Basically, I don't know the approach to follow, with the ALSA
>>> integration. I couldn't find any guide, or tutorial, so any help in that
>>> sense is welcome too.
>>>
>>> Thanks in advance
>>> Fabio
>>>
>>
--
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-porting+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
