From 85fdb3ff7d339097c564e11a8bd671cb2e80e28a Mon Sep 17 00:00:00 2001 From: Eino-Ville Talvala Date: Wed, 10 Jun 2015 14:58:32 -0700 Subject: Camera3: Document behavior of flush() corner cases. Document how HAL should operate when process_capture_request is called while a flush() call is active. Bug: 21506384 Change-Id: Ic1842add68123432e49914e83d8f7d5c13d6650d --- include/hardware/camera3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/include/hardware/camera3.h b/include/hardware/camera3.h index d23bdf2..3ef6d6f 100644 --- a/include/hardware/camera3.h +++ b/include/hardware/camera3.h @@ -2958,6 +2958,14 @@ typedef struct camera3_device_ops { * interruptible hardware blocks should be stopped, and any uninterruptible * blocks should be waited on. * + * flush() may be called concurrently to process_capture_request(), with the expectation that + * process_capture_request will return quickly and the request submitted in that + * process_capture_request call is treated like all other in-flight requests. Due to + * concurrency issues, it is possible that from the HAL's point of view, a + * process_capture_request() call may be started after flush has been invoked but has not + * returned yet. If such a call happens before flush() returns, the HAL should treat the new + * capture request like other in-flight pending requests (see #4 below). + * * More specifically, the HAL must follow below requirements for various cases: * * 1. For captures that are too late for the HAL to cancel/stop, and will be @@ -3002,6 +3010,12 @@ typedef struct camera3_device_ops { * 3.7. For fully-missing metadata, calling CAMERA3_MSG_ERROR_RESULT is sufficient, no * need to call process_capture_result with NULL metadata or equivalent. * + * 4. If a flush() is invoked while a process_capture_request() invocation is active, that + * process call should return as soon as possible. In addition, if a process_capture_request() + * call is made after flush() has been invoked but before flush() has returned, the + * capture request provided by the late process_capture_request call should be treated like + * a pending request in case #2 above. + * * flush() should only return when there are no more outstanding buffers or * requests left in the HAL. The framework may call configure_streams (as * the HAL state is now quiesced) or may issue new requests. -- cgit v1.1 From 5e58a30b6f625d3c28d1c6b15eec3edf5643e227 Mon Sep 17 00:00:00 2001 From: Andy Hung Date: Wed, 10 Jun 2015 15:17:00 -0700 Subject: Update USB channel mask handling 1 and 2 channels will default to mono and stereo n > 2 will default to channel index masks Bug: 16245854 Change-Id: I39f9d43385a93f48e323653fbde2e38a99b6256f --- modules/usbaudio/audio_hal.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/modules/usbaudio/audio_hal.c b/modules/usbaudio/audio_hal.c index 5431476..872fa93 100644 --- a/modules/usbaudio/audio_hal.c +++ b/modules/usbaudio/audio_hal.c @@ -55,6 +55,8 @@ static const unsigned k_force_channels = 0; #define DEFAULT_INPUT_BUFFER_SIZE_MS 20 +// stereo channel count +#define FCC_2 2 // fixed channel count of 8 limitation (for data processing in AudioFlinger) #define FCC_8 8 @@ -528,10 +530,14 @@ static int adev_open_output_stream(struct audio_hw_device *dev, proposed_channel_count = profile_get_default_channel_count(out->profile); } if (proposed_channel_count != 0) { - config->channel_mask = audio_channel_out_mask_from_count(proposed_channel_count); - if (config->channel_mask == AUDIO_CHANNEL_INVALID) + if (proposed_channel_count <= FCC_2) { + // use channel position mask for mono and stereo + config->channel_mask = audio_channel_out_mask_from_count(proposed_channel_count); + } else { + // use channel index mask for multichannel config->channel_mask = audio_channel_mask_for_index_assignment_from_count(proposed_channel_count); + } out->hal_channel_count = proposed_channel_count; } else { out->hal_channel_count = audio_channel_count_from_out_mask(config->channel_mask); -- cgit v1.1