Auditeur: A Mobile-Cloud Service Platform for Acoustic Event Detection on Smartphones 

Auditeur is a developer platform which provides set of APIs for detection of acoustic events. It extends the features of the existing acoustic classifiers and does so focusing on energy-efficient design.

Auditeur consists of an in-phone and cloud-assisted sound recogniser. “In-cloud”  processing include generation of energy-aware acoustic event detection plan. This plan is formulated based on the results from dynamically constructed training set and then forming a reduced feature set with required classifiers and corresponding parameters. 

This plan facilitates instantiation and wiring of only the required components based on the current context. As a result of this two-tier implementation (in-cloud and in-phone), auditeur provides more accurate and energy efficient classification results than rest of the classifiers.

Auditeur can be used by developers even with basic understanding of object oriented programming. A basic event detection functionality can implemented with just 20 lines of code. Furthermore, unlike existing platforms, acoustic processing pipeline is generated automatically. 

Even end users can use auditeur based applications with few initialisation steps. First, they need to record sample sounds clips and tag them accordingly. Next, they need to select the type of acoustic events for which they needs notifications.

Strengths

1. The paper presents great deal of implementation details for extending the existing acoustic event detection capabilities and produce plans for getting high level of maximum possible accuracy.
2. Major problem in designing continuos monitoring based platforms is its energy efficiency. Two tier design (In-phone and in-cloud) in auditeur addressing this problems and provides experimental data to prove its energy efficiency. 
3. APIs provided by auditeur can be used by novice developers without invoking any complex functionality and advanced developers which intend to customize the classification plans.
4. Paper provides detailed explanation for dynamic pipeline generation as well as the rewiring of the components based on the plans.
5. Paper provides a fitting approach for building comprehensive database for further research.
6. Paper approaches problem of building its own soundlet dataset by cloud sourcing mechanism.

Weaknesses

1. Paper does not discuss methodology used for dimensionality reduction of the features and it’s effect on classification accuracy.
2. As the number of application instances increase, the infrastructure resources needs to be scaled accordingly. Paper does not discuss in detail about the infrastructure components for two tier implementation.
3. The initial dataset in constructed based on the tags provided by the user. However, if these tags are not present in the soundlets, accuracy can take a hit. Paper does not discuss such a scenario.
4. There is a constraint of 3 to 30 sec on the size of the recordings uploaded by the end-user. Paper does not discuss the reason for such a constraint or ways of overriding them.
5. Auditeur implementation needs users to tag the recordings. However, tags for same recording can have different tags based on the context. If incorrect tags are included in the public soundlets, that can effect the accuracy of all the auditeur applications. This problem is not addressed in the paper.
6. Data processed by auditeur can be highly sensitive. Paper does not discuss the steps taken at cloud infrastructure level to deter any malicious elements from accessing this data.

Discussion points

1. Can we integrate code offloading frameworks with auditeur to get maximum possible accuracy ?
2. Can the scope of such a platform extend to services like disaster management, health care, emergency services ?
3. Integration of auditeur with voice assisted applications for getting more contextual information to increase accuracy?
4. Sharing of information between nearby auditeur application for further synthesise preprocessed data ?